 |
MEET THE MEMBERS - TRANSCRIPT Offshore
Outsourcing: The Pros, The Cons Sponsored
by: Summary - Transcript Baltimore, MD (August 31, 2004) PANELISTS: Keith
Moulsdale - Whiteford, Taylor & Preston, Partner MODERATOR: Larry Fiorino- G1440, CEO
Welcome to today's panel, Understanding Open Source and its Business Implications. I want to begin today by thanking all of our sponsors of the Members Breakfast Series, Heidrick & Struggles, PriceWaterhouseCoopers, Saul Ewing, Stout, Causey & Horning, and University of Maryland College Park. And special thanks to our signature sponsor, Qorvis Communications. And please join me in welcoming Doug Poretz, founding partner of Qorvis. Doug brings more than three decades of broad public relations experience with a concentration in the last 20 years in investor relations and enterprise valuation. He is often asked to speak or report on various public relations topics. So I will now ask him to come up to the podium and speak to you. DOUG PORETZ: Thanks. I'm Doug Poretz, co-founding partner of Qorvis Communications. We're based in D.C., in Tyson's Corner. Over the past four years since our organization began we have become what we believe to be the largest public relations firm based in the mid-Atlantic region. If you take a look you'll see that we provide a wide range of services. Our business model is to use a team of people who primarily have a very significant degree and depth of experience in public relations matters. We're a group of seasoned professionals who get our hands dirty doing work. A client that we have handled in this area for about the past two years that you may know of is SafeNet. We've handled investor relations for them, internal communications during mergers and acquisitions, product launches, general corporate communications, visibility, and so on and so forth. We do that for a number of clients. We have about 70 employees . If you ever have the opportunity to want to hear another voice, another range of services or you know people who may, we'd love to have the opportunity to get to know you better. Thank you. STEVE KOZAK: We'll get started on the panel. I want to thank our Business Growth Committee for helping us get this topic today. This committee is really not a committee per se, but more of a collection of our members. . I would encourage folks as members to get involved in that committee and come out once a month and spend an hour with us. Now, open source. As we said in our copy promoting this panel, open source is not just a buzz word, it is the buzz word. Over the last 30 days alone Wall Street Journal has had eleven different articles on this subject. It is a solid trend that is affecting both business and technical folks rethinking software development and licensing. And I can tell you from our Business Growth Committee meetings it is hotly debated. In fact, several times we had to pull folks off the conversation and talk about the panel and how we're going to create it. Today's panel will address a variety of topics, everything from what open source is and a theory of why it is good to what the various forms of open source licensing are and their costs, the strengths and weaknesses, and answer your questions. These panels are for you. Don't be shy. If we're not addressing a certain area yell 'Larry' real loud and we'll get to your question. I think actually we're going to hold those to the end, but write them down. With that, let me introduce Larry Fiorino, our moderator. Larry is the founder of G1440, a technology consulting company here in Baltimore. Larry started the company in 1988 with little more than a laptop, a cell phone and a Chevy Tahoe. He didn't have any office space. Today he not only has office space, but he has 65 employees. In 2000 Larry sold an interest of G1440 to the Sinclair Broadcast Group. He has over 15 years experience in the IT industry. He's a graduate of Towson with an undergraduate degree in accounting and an MBA with a concentration in management information systems, and is alsoa CPA. He is a member of our board. He runs our Business Growth Committee, and he's a valued member of the GBTC community. So with that, Larry. LARRY FIORINO: Good morning, everybody. I think we have a great panel today. I've met with each one of these folks and spent some time before today, almost every discussion took between an hour and a half to two hours. One of the things that has been fascinating in doing the research for this is that open source is many things to many people. It's amazing. I've talked to people in the community who told me that with open source, everything is free, your rights are unlimited; do whatever you want, all of the way , and those who have said stay away from that stuff; you don't want to touch it. It's been fascinating in doing research to get up to speed on open source and where it is today. First we're going to jump into defining open source, what it is and what it isn't. But first what I thought we would do is take a minute and have the panel introduce themselves so they can tell you about their background and why they're here. MARTIN ROESCH: Hi, I'm Martin Roesch with Sourcefire. We're a company located in Columbia. I'm the founder of the company. I'm actually also an open source developer, after working on an open source intrusion detection system called Snort for the past six years that is one of the most popular technologies of its type in the world. I know a decent amount about both sides of the open source equation, from developing it to building a business around it, because Sourcefire is built around the open source Snort technology. KEITH MOULSDALE: I'm Keith Moulsdale, partner at Whiteford, Taylor & Preston in Baltimore. I'm in the technology and IT section. Most of my companies are technology and software companies, and I'd say about 70 percent of my practice now is open source software licensing. One of my biggest clients is MySQL, which is the distributor of the world's largest open source database. PETE NASH: My name is Pete Nash. I'm a Windows platform architect at Microsoft. My role is to help customers understand the whole breadth of Microsoft technology, how they all fit together, as well as our vision of where we're going. And one disclaimer. I am here as a Microsoft employee, but my opinions are my own. I am not personally speaking for Bill Gates or Microsoft. BOB UNGARETTI: I'm Bob Ungaretti, president of Raven Technologies. We're a21-year-old systems integration firm specializing in the Unix operating system. We have been a SCO Premier partner since 1985, and since then have built relationships with Microsoft, Novell, and recently the Linux suppliers and open source technologies that we use in supporting our customers. While we're a SCO partner, I am in no way associated with Darl McBride, although I know him and I understand their arguments, we're an independent company. I'm here to at least argue on some of that side. We find ourselves on all three sides of the argument very often with using open source technologies, Windows software, and Unix software. It's an interesting mix. LARRY FIORINO: I think we've got a great panel that will provide a balanced perspective. We're going to have a lot of fun today. Why don't we jump right in with an explanation of open source, Bob? BOB UNGARETTI: -The purpose of Open Source Initiative, which was started in 1984 by the Free Software Foundation was to provide a community in which applications, software programs, and projects could be developed with a community of developers to allow for free distribution of those programs and the associated source code. Since 1987, the Open Source Initiative created a licensing product called GPL, the General Public License, which we will probably talk about today. Basically the GPL says you can use and freely distribute any open source code and make modifications to it, but you have to include the GPL License with any of the code that you modify, and you have to freely distribute the source code that you contributed to that project. Some of the advantages that the Open Source Initiative has had is the creation of quite a lot of programs that you use in everyday life but are likely not even aware of. Probably the most popular open source program is Linux. Linux is a Unix-like operating system. It looks just like Unix, but is found in all sorts of devices, including Tivo. That gives you an idea of how embedded and pervasive open source technology is in your everyday life. LARRY FIORINO: Let me jump in for a second. You had a bunch of great points like the GPL and other licensing. It's interesting, free software -- I guess free is open source. But open source is not free. I don't know if you want to expand on that. Believe it or not, you can get in a lot of trouble using open source. KEITH MOULSDALE: Well, basically I agree with all of your points. Some people believe open source is a business model; some people believe it's a philosophy. But in the end I think it may be one or both of those to you. But it's always a licensing process, the licensing of intellectual property. It's important to know what the fundamental is. In order to distribute open source software there has to be a license, an ownership at the top somewhere, or a right to distribute. LARRY FIORINO: So open source is owned by someone? KEITH MOULSDALE: Under copyright law anyone who writes or authors code owns it, unless they work for a company. So in the end, yes, somebody owns it. LARRY FIORINO: I can't take and do whatever I want with it? KEITH MOULSDALE: That's right. That's a huge misconception in the community. People think it's open source; I can just take it and do whatever I want to. That's almost never the case. There's always a license, which has terms. Some terms are stronger than others. There's the GPL license, which is the most frequently used license under which the Linux software is distributed. Those are sort of free software licenses. Then there are Open Source Initiative licenses which have some of the same characteristics, but they're much less restrictive in the sense that they allow software to be distributed openly and freely, and that software can become commercial again downstream. Under the GPL, code can't become commercial because of the forcing function feature. LARRY FIORINO: Why can't it become commercial? KEITH MOULSDALE: Basically the GPL has one of its provisions called Section 2(b). People sometimes negatively refer to it as a viral clause of the license. It's not like a virus. You can't just touch it and say all my code has to be released.' That's the perception that a lot of people have about open source under the GPL. What the clause actually says is that you are free to copy, modify and distribute and publish the code to anybody freely. LARRY FIORINO: Can you make money from that? KEITH MOULSDALE: You can't charge a licensing fee, but you can charge a distribution fee. But the catch is that if the code you distribute is a derivative work of the original -- LARRY FIORINO: What is derivative work? KEITH MOULSDALE: Now we're getting into a legal discussion. Basically a derivative work is a copyright term under the U.S. Copyright Act and international copyright acts around the world. It is sort of an outgrowth of one program. If I give Martin a program and he starts making changes to it and -- LARRY FIORINO: But he started with yours. KEITH MOULSDALE: He started with mine. And then he distributes the whole, that's a derivative work, arguably. Unfortunately for most people you need a lawyer to sort of go through the analysis, and it's a complex analysis. PETE NASH: How many different open source licensing models are there? I've heard there are up to 40 different variances of open source licenses. KEITH MOULSDALE: There are as many as you can imagine. There's no statutory definition of open source. There's no federal government statute or state law that says this is what it is. It's really a philosophy. Some people take it in one direction and some people take it in another. LARRY FIORINO: Can I create a piece of open source and then put it up and create my own license? MARTIN ROESCH: Yes, you can. Several companies have done that. My people have recently changed their licensing so that they have a free license for non-commercial use and then a paid license for commercial use, or something close to that. I'm sure there are nuances on that. I'm glossing over it. You can create any license you want to. For example, in the world that I operate in we have this other piece of open source software that goes along with Snort that basically acts to take me off of Snort and format in different ways. It's open source. It originally came out under the GPL license. We decided to change the license two releases ago to a license called QPL. The only difference between the GPL and QPL is the QPL compels you to release your source code. With QPL you have to release your source code to everybody, whereas under the GPL you only have to release it if you actually distribute it. LARRY FIORINO: If I'm sitting in the audience right now and I'm not too technically oriented, one of the things I'm hearing is there are a zillion licenses out there, both free software and open source. There are different definitions for both, although there are no statutory definitions. Can any of you guys tie this up in a nice bow and tell a business person thinking about open source what to do? How do they figure out what license they're governed under? How do they keep their legal fees down to a minimum if they just want to download an operating system? How do they navigate this first maze with -lots of licenses, lots of people touching it, derivative works? Who wants to jump in? How do you avoid all this stuff? PETE NASH: That gets back to the fundamental issue of open source versus software. Of course, as a Microsoft employee I would encourage you to use Microsoft. But I think it's a very complex issue. You really have to understand how each product you're using is licensed and what the implications are of those licenses. LARRY FIORINO: Bob, you just made a very good point. I could have multiple pieces of open source software and they can all have their own licenses, which may conflict. How do you put together a solution using open source? BOB UNGARETTI: Licenses themselves don't conflict. Most of our customers are running three separate environments integrated together-Unix , Windows and Linux, because we want to be able to use the best technologies available from all sides. We are able to integrate those technologies together. LARRY FIORINO: Well, what about a solution, like Linux, Apache PHP? BOB UNGARETTI: They're not really solutions. They're just tools to a solution. LARRY FIORINO: But you put them together. Are there any issues with licensing when you start putting tools together that are all open source? BOB UNGARETTI: Well, there are in some cases. If you look at MySQL, for example, you have to pay a licensing fee to MySQL Company to commercially distribute that product. You don't have that with Apache. You can use the web server anywhere you want to as long as you're using the binary and you're not changing the source. LARRY FIORINO: What do you mean by that, using the binary and not changing the source? BOB UNGARETTI: In terms of using the freely distributed product that you can download off of the Apache website and run on Linux, Unix or Windows, there are no royalty fees associated with using the web server. If you wanted to make custom modifications to the Apache web server, then you're dealing the licensing issues of the GPL where your contributions to that code need to go back into the source code and be distributed. If you're writing software, as Sourcefire does, and you're distributing as part of your open source software, then you've got to comply with the GPL with how you distribute it. You can't make your own custom modifications to that open source software and sell that as your own work. It's covered under the GPL. You can make modifications to it and give it away. MARTIN ROESCH: You can sell around it. You can sell the value added solution as a solution, but the modifications that you made to the open source software and links to that all have to be open source. Some rules of thumb that we use are: if you write software that uses open source, modify the open source software, or extend the open source software by actually developing code that links against the open source code, then the code you write has to be open source. If you develop software on top of open source, it doesn't necessarily have to be. So if I'm using Linux and I write a program that runs on top of Linux, that program does not have to be open source. If I modify how Linux works and my program counter-operates with that, that program does have to be open source. There are some nuances in there. You also have to be aware of which licenses you're talking about. The GPL license enforces that you open up your software. It protects the intellectual property rights of the original author so that somebody can't come downstream from the open source development and actually turn it into a proprietary system. The GPL-using authors select that specific license so that people can't just take their software and run with it. There are other licenses like the BFT license which allow people to do whatever they want with software, they just have to keep the original copyright notice in their documentation someplace. LARRY FIORINO: So how is this controlled from a business perspective? It seems like with all these chefs stirring the pot you can run into issues with changes being made that maybe you didn't know about. For example, if you have an open source application that's built using a specific toolset and you upgrade Apache, you could break everything else. How is that controlled? If I was a business person I would question it. KEITH MOULSDALE: That's not a problem that's unique to open source. There's a huge misconception here that there are a billion open source licenses and they are out of control. It's not like that. In fact, the reverse is true. There are substantially more closed source licenses, because that's been our traditional model with Microsoft. The traditional model in my firm with representing companies using open source is they come in and we write them a license unique to them. So every single license is different. It's fundamental in the software business if you're developing and distributing code that you figure out if these licenses are compatible. And that's nothing new. I'd argue the open source model relieves some tension in compatibility because there tend to be fewer licenses, and there are model licenses like the GPL that people use. LARRY FIORINO: So there are more closed source licenses than open source? KEITH MOULSDALE: By far. LARRY FIORINO: Are there standards at all in the open source licenses? KEITH MOULSDALE: There are some. There's the Open Source Initiative, which has ten rules. For example, the software should include the distribution of source and free transferability. But that's not to say that people have to follow those rules. MARTIN ROESCH: If you want an OSI-approved license then you have to follow those rules. That's kind of the arbiter of what is open source and what isn't. When the QPL first came out it wasn't considered an open source license until they made some specific changes so that it was compliant with the OSI set of rules. Then it became an OSI-approved license which makes the open source community a lot happier about including it. BOB UNGARETTI: Getting back to one of your original questions, what are the legal implications for an end user using Linux, using Star Office there are some questions about whether they're legally encumbered. KEITH MOULSDALE: I think they're no different than a user of a closed source license. You still have the same issues. You have to think about what the source of the code is. Does it come with warranties; are there performance warranties; are there intellectual property warranties? Who's standing behind the code? Really the issues aren't that different. That's sort of a closely guarded secret, I guess. The analysis is similar. It comes down to reading the license. LARRY FIORINO: So the issues are the same whether you're dealing with Microsoft or any other proprietary-type license or open source? KEITH MOULSDALE: They're very similar at their heart. PETE NASH: Doesn't there become an issue of volume in terms of the number of warranty programs and licenses? From my perspective it's a volume issue. If you buy all your software from IBM you may get one licensing model from them as opposed to Apache. MARTIN ROESCH: How many people buy homogenous setups where they have all one vendor? If you look at the open source models, the predominant licenses are GPL, LGPL, and PSD. You don't see a whole lot beyond that in a lot of open source systems. If I'm a developer using Windows and I'm using somebody else's third-party libraries for integrating with some backend system, and then I'm using some other piece of software like Java for the front end, I've got three licenses to deal with there. The interesting thing about open source is there are about 40 licenses, but you realistically only have to worry about three-GPL, LGPL, and PSD. KEITH MOULSDALE: What's interesting is end users are now seeing this as an opportunity to save massive amounts of money. LARRY FIORINO: But there are studies on both sides that say that one is more expensive than the other. PETE NASH: A lot of analysts' reports say that the licensing cost is only five to ten percent of the overall cost. There are plenty of studies on both sides of the fence. LARRY
FIORINO: From my perspective, just based on information we've put
up here today, it sounds a little complex in terms of how you deal
with it. I think it's a very valid point that if I licensed a hundred
pieces of proprietary software, I'd have a hundred different licenses.
If I go in the open source world I've got 40 total to choose from. LARRY FIORINO: They affect the developer? BOB UNGARETTI: Yes, more impact on the developer than on the user because of the nature of what they are. LARRY FIORINO: So the legal implications of open source are more for the developer to deal with? BOB UNGARETTI: Yes, I think so. MARTIN ROESCH: The developer and the distributor. If Sourcefire decides to take an open source code and modify it and then put it out to our customers, we have to take into account how it affects our distribution. If it's a BFT license then I have to make it proprietary, but if it's a GPL license then I have to open it up. We distribute the software to the customer under a license, and then the customer just uses the system. The onus is on us as the distributor to stay within the bounds of the licenses that we're using. KEITH MOULSDALE: You don't need to take anybody's word on the panel, because people have different views. I think the facts speak for themselves, which is open source products are being adopted around the world in an incredibly fast fashion. There are governments, especially in the developing world, who are mandating its adoption. They really feel like code captives. They can't break through and do the things that people in the developed world are doing. The U.S. Government Office of Management and Budget in July issued a memo reminding its procurement officers that open source is an option. LARRY FIORINO: Are you saying that the main driver for open source is cost? KEITH MOULSDALE: That's certainly one of the main drivers in terms of why people buy it. I'm not sure that's why people develop it and use the model. There are all different kinds of motivations. PETE NASH: If you talk about the cost, is Red Hat's enterprise server distribution free? Let's talk about the cost associated with most of the popular distributions. LARRY FIORINO: What are the other costs associated with open source? I can download a copy of Linux for free. What else is there that's out there that I need to think about? BOB
UNGARETTI: Well, the normal end user is not going to download Linux
for free. For them to get a system up and running, unless they're
a developer or a system integrator, would be very difficult to do. It's becoming easier to do that because it's more Windows-like. That's just a fact. The majority of people are familiar with the Windows desktop and how that runs, and a lot of the open source desktop tools are patterned after Microsoft products because they marketed the interface. LARRY FIORINO: As an integrator you have to choose for a customer what you should build a solution in? How do you do that? BOB UNGARETTI: There's not always one solution. A lot of times there are multiple solutions. Because we sell and support Unix and Windows and Novell and we sell and support Linux, there are a wide variety of choices that can be applied in any particular situation. Most of the solutions for our customers are application-driven. The application that drives your business is going to determine what operating system you run on. Users typically don't pick the operating system. They pick the application. If the application doesn't exist, they might contract with somebody to write the application. Then the application developer will pick their ideal environment to run on. Back when we started Raven Technologies the predominant operating system that was available for multi-user applications was SCO Unix. A customer would call their application vendor and the application vendor would say we run on SCO, call them. . Then SCO would call us and we'd get a call and work with the customer to set up a system for them. That whole business model has changed considerably now, because a lot of the applications that were only available on Unix are now only available on Windows. We find ourselves migrating some of our customers because that's the way the application vendors are writing their software. LARRY
FIORINO: You mentioned SCO, which is something I think we probably
ought to talk about. There was a point in time when Microsoft owned
20 percent of SCO. So Pete, if you could talk about Microsoft's position on open source. Microsoft being an open source provider is fascinating. PETE NASH: Microsoft has released two technologies into the open source community: our WX Installer capabilities and a template library. These are, again, core fundamental development tools, not packaged products. They were released into the open source community to help build community awareness around those technologies. The WX Installer specifically addresses doing installs, which I think most Windows users can relate to having pain in the past around installers and installing programs. The template library is a fundamental tool we see for building applications. LARRY FIORINO: Why not sell that? You sell everything else. PETE NASH: We don't sell a lot of the API that we release. We have a tremendous amount of software development things that are available on Microsoft.com. These are core technologies. These are not packaged products. These are things that people can use to basically build product. MARTIN ROESCH: You usually release something like that to drive adoption. You release it as open source and people start using it, and then they decide they like it a lot can't do without it. and It builds a community of users who decides the right way to do stuff and the way they like to do stuff. Then the vendor who develops this has a built-in community of users, so it kind of spreads virally from an adoption standpoint. LARRY FIORINO: Didn't Sourcefire do something like that? MARTIN ROESCH: We did exactly that, except it wasn't planned. I started writing Snort back in `98. LARRY FIORINO: And what is Snort, real quick? MARTIN ROESCH: Snort is a network intrusion detection system. It catches hackers breaking into your network in real time. So I started writing it in `98 and the plan was to have a good time and see if anybody would use it. LARRY FIORINO: So you weren't interested in making money? MARTIN ROESCH: No. At the time I was a government contractor. I was having fun working on stuff I can't talk about. But within two years Snort was the most popular technology of its type in the world. It had more deployments than any of the other intrusion detection systems. I started realizing that I could probably build a company around this. So in 2001 we opened Sourcefire. The
idea originally wasn't there. It was just to have a good time. Then
one day I realized this thing was in use everywhere--governments,
big banks, military, utilities, universities. I said, wow, I've
got something It's kind of like the Apple model when they pulled into the schools-we got them all hooked when they were young. Back when people were in college and they didn't have any money, they downloaded Snort. Or when they were dabbling in intrusion detection systems and wanted to see how they worked, they downloaded Snort. And
then they got used to it, and by the time Sourcefire showed up as
a company they were ready to start deploying a commercial solution
that had all these features with the core technology that everybody
liked and all these add-ons that would drive value. MARTIN ROESCH: It was a mistake. But it just kind of worked out that way. KEITH MOULSDALE: What were the benefits of the development process once you released it? MARTIN ROESCH: In 2001 there was a round-up of network detection systems in Network Computing Magazine and they compared ten intrusion detection technologies, including Snort and the nine other commercial ones. At the time this review was done they were using the last version of Snort I released before I started Sourcefire. Out of a field of ten in this comparison with big networking and security companies, Snort came in third. What that told me was that the open source model works. You can build superior software. This was us goofing around in our spare time, and we were able to beat billion dollar companies with our technology. So the open source model works really well. If you use it appropriately you can develop some very, very high quality software on a shoestring. The open source model is a very powerful development model when you use it appropriately, when you actually leverage your community to take advantage of the things they bring to the table. LARRY FIORINO: Some people were sending you feedback saying 'This doesn't work' or 'I wish it did this'? MARTIN ROESCH: Yes. LARRY FIORINO: Are there other people downloading the source and changing it themselves? MARTIN
ROESCH: Yes, they would send little patches and updates that we
could include in the system--little pieces of functionality. They
would put it on different formats. LARRY FIORINO: But that didn't necessarily speed your development. I think one of the things about open source is there are lots of people that get involved and they find more problems with the program. MARTIN ROESCH: Many eyes make all bugs shallow. What a lot of people don't realize about open source development is that it isn't just a bunch of guys getting together and developing something. Usually they're what I like to call benevolent dictatorships--one guy at the top decides what's in and what's not. Then there's kind of a hierarchy of people who are contributors, and people who make the contributions, and people who decide what's worthy to go into the system. It all funnels up to the top, and the guy at the top decides what gets in and what doesn't. Then they put it all together and make a new release. LARRY FIORINO: That sounds like the Microsoft model. But that's not really the point of open source. I can download and change it if I want to. If I'm downloading it, testing it, and finding something it doesn't do, asking you to change that for me, how is that better? MARTIN ROESCH: Because the development cycle is much, much faster. LARRY FIORINO: Why? MARTIN ROESCH: Because I don't have an extensive QA process like Microsoft does. LARRY FIORINO: Is that bad? MARTIN ROESCH: No, not necessarily, if wedo rapid release cycles. In those, we take the feedback from the community and repair the bugs that we know about, do another small incremental release, fix those bugs, add in new features, and have another release. PETE NASH: Doesn't that imply that people are constantly upgrading? MARTIN ROESCH: Usually early on in open source development cycles, when the products are relatively immature, we see a lot of rapid releases. But the upgrade costs are relatively painless because you're seeing small incremental changes fairly rapidly. Like the Linux kernel we have gradual upgrades where we have kernel revision coming out every two years or so. The pace of development actually slows down and the feature sets from release to release get much richer, but the feedback from the community is still incrementally improved. You have frequent micro-releases for the people who like to do the testing and development, and things like that. LARRY FIORINO: How does that impact an integrator with micro releases? BOB
UNGARETTI: Well, it drives us nuts. The customers are not going
to want to pay for you to do constant upgrades to their system.
It's important for us to put in a stable environment that runs.
We've had that luck with Unix. We have customers running the same
system for ten years, no changes except for upgrades every now and
then. It's not trivial with commercial software either. Theoretically there's more testing that goes into commercial software because of its compatibility with different operating systems and other applications than there is with open source stuff. We've had some of those problems with the PHP and Apache revision, where successive revisions to one package takes out a functional link required to connect to another piece. It causes our developers some pain because we have to spend a lot of time fixing those problems which we can't bill our customers for. KEITH MOULSDALE: Now, you have to fix those problems? Since the software is open source, you've got a finite number of eyes looking at this code. But you've got an infinite number of people in the community, developers who are constantly looking for integration issues and bugs, then fixing and releasing them. Can't you just sort of go out and grab those? BOB UNGARETTI: Typically you'll go out and look on the networking or user groups and see if somebody else has had this problem before and fixed it, and if a patch is available for it. Sometimes you get lucky and sometimes you don't get lucky. That cycle requires effort. You could argue about how long it takes to fix a problem with a proprietary system as opposed to an open source system. The fixes will happen faster, but there are more of them, and you've got to make sure that you've got them all chased down. LARRY FIORINO: Now, are those fixes being made by different people, or one group of developers? BOB UNGARETTI: It's anybody. PETE NASH: And, you know, there's recently been issues -- when we addressed this concept of a million eyes makes all bugs shallow, there's recent issue in SendMail that's been there for 15 years. So there's really no hard data to prove this concept that a million eyes makes all bugs shallow. MARTIN ROESCH: We had a bug from Snort that created a security problem back in early 2003 It was a piece of code that had been in the system for 18 months. All bugs are shallow only if it's something that's manifesting itself so everybody can see. This was in a little corner of the code that nobody actually saw very often. So it sat there for a while. And that's been one of the lessons learned from me as an open source developer. The community is going to test the core functionality of the system very well, but the outlying stuff, not necessarily as well. But interestingly enough, when we do hear about bugs they get tracked down almost instantaneously. We had a problem back in 2001. I got a notification from a security company on Friday night that the intrusion system was handling one way of encoding web protocol inappropriately. Sourcefire was just getting going at this time. So we were only three people. We had a patch committed into our service control system within four hours of notification Friday night. It would have taken commercial vendors weeks and weeks to get their stuff out. PETE NASH: How much time did you spend testing that fix, doing regression testing, doing compatibility testing, packaging it? MARTIN ROESCH: I told the community about it on that night and by Tuesday morning we had several hundred people reported that it was working fine for them. So we launched it. We do community-based testing. Here's a release candidate. We think this is ready to go. You test it and get back to us. We decide we're good to go and we launch it. LARRY FIORINO: Isn't that similar to what Microsoft does as well? MARTIN ROESCH: But it's a lot faster and a lot more in the open. LARRY FIORINO: The models seem to be strikingly similar. MARTIN ROESCH: The assumption with open source is that it's community driven. The community gives feedback to the developers. I have a limited development environment. It works fine in my environment. LARRY FIORINO: That's true with software everywhere, right? MARTIN ROESCH: It's true, but if you look at Sourcefire, we have a couple million dollars worth of test equipment in house for testing our stuff and a QA process, and all this other stuff. We have a process and it takes time. When you have direct developer and community interaction it's very different than when you have very indirect interaction. This happens when developers sit in the lab and do their work, then hand it over to the QA research guys who verify the functionality, then kick it over to the marketing team for final packaging and then release. Then it goes out to the community and there are bugs that get reported back to the tech support organization, who then report through whatever channel, and then back to developers, and it goes back up the chain again. Whereas in the open source world I've got a guy in Bangalore with a bug in the system; he writes me an e-mail. It goes straight to me. I see it and do a patch. I tell my people I just patched this; can you check it? They check it. We decide it's good. We say community, please test this for us. They give us the thumbs-up and then we do a release. And this cycle can be anywhere from hours to a few days, as opposed to multi-month release cycles. LARRY FIORINO: Is that more a function of size? MARTIN ROESCH: It's a function of size and also a function of the communication you have between the people. If I have a person who can communicate directly with us, then that interaction is going to go much more quickly than if it has to go through six layers of management and get in a marketing requirements document for the next release. PETE NASH: There's the QA process that goes on that questions the downstream implications of this bug. Basically, it asks what is everything that this could possibly interact with? MARTIN ROESCH: It's a continuous QA process. PETE NASH: So there's always QA; there's always a next release? MARTIN ROESCH: Not necessarily. You mark stable versions, and they have the release version, and then they have the development version. So depending on your level of comfort with the system, if you've got a known bug in a stable system, you work around it. If it's a code change, then you put it into the head branch. KEITH MOULSDALE: I think I see the sales pitch on each side. LARRY FIORINO: Keith, what about -- you represent MySQL, a large company. How do they deal with this issue, and is their response time better than Microsoft because of the model? KEITH MOULSDALE: I think they would say so. LARRY FIORINO: How big are they? KEITH MOULSDALE: They've got employees in almost 40 countries dispersed around the world. I think they would argue that their patch time is dramatically quick. What's important to distinguish about release is that a lot of open source companies, like MySQL, don't simply put out commercial, generally available releases to use in your everyday mission critical systems. They launch alpha and beta pre-commercial releases and let people test repeatedly, then fix that version. Not until they're assured that 99 percent of the bugs are fixed do they actually designate it as a version for mission critical release. LARRY
FIORINO: We'd now like to take some questions. MARTIN ROESCH: The question is, how will this be handled in the commercial world, where you have production releases and developing releases, and they can have radically different performance parameters that nobody is going to put these in their production systems to test. In the web services, typically there's the staging area and a production area. The staging area is where testing like that would typically happen. But what we see in my part of the world, where we have intrusion detection systems, are high performance pieces of software. People have places where they run side by side with the stable versions that they have and check out the performance. On the part of the user there's a dedication to deciding to be a person who participates in this development process if all it is is participating in the QA cycle. When a new release comes out they test the software to see if it works well in their environment. Some of these pieces of software for intrusion detection systems are very complex pieces of software, so there's a lot of testing. We've found that when you have very engaged developers working directly with the community, it leads to good software development practices. In this scenario, when I make a change to the system it doesn't have lots of downstream effects on a properly architected system. What we find in the open source world is that this happens because we have a very unforgiving environment. BOB UNGARETTI: A lot of that has to do with the maturity of the product. Apache is a very mature web service. It's been in use for ten years. You can get the last stable release of Apache and know that it will work. It's the most popular web server out there. Newer open source contributions are more risky because they're new projects. SPEAKER: You talked a lot about quality and upgrades and release candidates. All of us software users are very frustrated with all that, whether it's commercial or open source, because it seems like it's always breaking. I wanted to focus the question a bit differently to the business drivers for using open source or not using open source. Why should a software vendor use open source, like Apple uses the BSD units for the Mac operating system? What's the driver for that? If you're a systems integrator, a lot of them seem to use J-Boss for an application server. What's the business reason? Why choose that versus Web Logic? An end-user in an IT organization where maybe they're buying Red Hat or Linux versus Windows, what are the business reasons for choosing one over the other? BOB UNGARETTI: From our standpoint it's two factors. It's performance and price. And it's a juggling act. It really depends on the customer. If money is not an object -- we've yet to find that customer -- then we're going to deploy the absolute best technologies that are available for that customer. But money is always an object. Sometimes it's a licensing issue and sometimes it's not in terms of cost. Sometimes it's a maintenance cost. LARRY FIORINO: It can be money for the customer as well. We had an application running Web Logics and our customer would have had to buy Web Logics licenses for $8,000. Instead we ported to J-Boss, and got a performance pop as well. The application performs much better and the cost to our customer is $200. MARTIN ROESCH: The cost of entry a frequently is what you see, especially up front. We have to actually compete against our open source products. A sufficient number of people have Snort deployed that we sell, and sometimes we have to sell against our open source technology. You have to make the argument, you save a lot of money up front, but what are the total costs associated with it? You get people to take the long view and then figure out what costs they can tolerate. Sometimes a proprietary solution is more appropriate than an open source solution, or sometimes they can get more value from a proprietary solution over the long term. But in terms of cost of getting started, open source solutions are usually extremely cheap up front, if you've got the time. PETE NASH: If you've got the time. LARRY FIORINO: Very low cost of entry is what I'm hearing. PETE NASH: For the license. SPEAKER:
I'd like to know the business model for the software developer,
the cost incurred building the software. Does an open source vendor
expect to get this all back from services when you give it away? We also have proprietary technology wrapped around that doesn't directly touch that technology. They generate the data it needs to do its job and they understand the data it outputs. We've got a model that's a value add model where we wrapped the proprietary technology around the open source technology. And we use that to bring value to the customer. We have what we at Sourcefire call the separation of church and state, where we have the proprietary stuff that you worked on. And then we've got the core stuff which is open source. And as we work on that we acknowledge right up front the open source stuff is going to stay open source, and everything else is going to be ours. KEITH MOULSDALE: There are more business models. I think generally speaking there are two, but they're only limited by your imagination. MySQL, for example, all of its code is distributed and is open source and there isn't really a separation of church and state, so to speak. What it distributes on the open source side it also distributes commercially, pretty much the exact same code. The difference is there are companies out there who want a commercial license. We sell commercial license for a fee, but there's also maintenance, integration, training, documentation, and MySQL publishes books. SPEAKER: My question is to Keith. You mentioned that developing nations and the U.S. government are actually issuing memos as to the validity of open source and the fact that it's probably cheaper. It sounded like you're convinced that the TCO actually is lower for open source, but the counter I'm giving is that over the long term with the added development costs involved, it's not. What is your opinion? It sounded like you're convinced that TCO is actually lower. KEITH MOULSDALE: I don't buy software. I represent companies that distribute it. I'm on both sides of the fence. I think it's fact- specific. I don't think you can say open source is always cheaper in the long run or short run, or that closed source is always cheaper or more expensive in the long run. It depends on the situation. I think there are arguments on both sides of the table. LARRY FIORINO: There are paid studies all over the place that go both ways. SPEAKER: My question is about security and accountability. What kind of control mechanisms are in place if you've got a lot of people contributing to the code? What's there to try to keep someone from slipping something in and not being reviewed maliciously? And once that is found, who's accountable for that? MARTIN ROESCH: Open source technology tends to be pretty self-policing in terms of the security issues. The whole notion of somebody trying to slip in bad code intentionally -- it's hard enough to write software in the first place, so I don't know if you would be able to tell the difference between maliciously contributed and non-maliciously. We have an audit process where we review the code before it goes in the system, and some projects don't have that. It's a little bit of buyer beware. You have to be aware that most of these products tend to be pretty self-policing or they get a reputation for being insecure, and their user levels drop off, whereas more secure alternatives tend to pick up. SendMail is the most popular mail server out there, but it's had security issues over the years. So a lot of people have picked up QMail and things like that to use another open source system with a much better track record on security. What we see historically in the open source world is there's been more concentration on doing secure implementations than there have been in a lot of proprietary systems. In the proprietary world, especially in the bubble, there was a ton of software written without attention to the security of the system. And now we have a lot of software out there that's very insecure because it was written as quickly as possible with as many features as possible, with no notion of security built into it. That's had some real effects, and it has cost people a lot of money. As with pretty much everything we said up here today, the open source and proprietary aren't too far away from each other. What we see in open source is people tend to concentrate on it more -- well, people in the past have concentrated on it more. Certainly now, like Microsoft, they are very dedicated to building secure systems. SPEAKER: I'd like to hear from both the legal and developer side your opinions on the standardization of open source. Is it possible and does there need to be a more rigid legal statute for open source to become more commercially viable in the marketplace? I know the ambiguity helps to keep your billable hours up. But in the long run would a more legal statute help open source mature? KEITH MOULSDALE: Personally I hope there's not -- and it's not because of the billable hours. But I hope that there's not more standardization from the legal side, especially when you have an early adoption of some sort of technology. This has been proven with the Internet, that the fewer statutes involved and less laws passed to control it, the more freedom people have to invent and create business models. So I really hope that there won't be significantly more laws passed in this regard. I think also over time there will be case law that will develop which will validate things like the GPL license. A few years ago, everyone was asking whether or not the GPL was enforceable, because it was a new concept. When people take a step back and look at the legalities behind it, they realize it really isn't that much different than a lot of other contracts and licenses around the world. A couple of months ago a court in Munich, Germany basically said that the GPL under German law is perfectly enforceable, and there's no reason why it shouldn't be. I think over time there will be more of these cases and people will start to analogize GPL licenses and open source licenses to other types of licenses in the closed source community. LARRY FIORINO: Bob, do you see standards in the open source development community emerging? BOB UNGARETTI: I don't think so. If they're legal standards, what they'll end up doing is stifling development of additional technology. And that's certainly something we don't want to do. With respect to inoperable compatibility standards, those are inherited by the existing standards on the books. It's more or less survival of the fittest. If the program works and is adopted and is popular and supported, it will survive. If it's not popular and it doesn't work, it's going to die. So I think it's going to be the best program wins. KEITH MOULSDALE: Let me just add one footnote, I think there already are standards for open source licensing called the U.S. copyright law. It allows people who own software the exclusive right to copy and distribute. And it's certainly within their rights to distribute and sort of be inclusive and let people distribute and make other copies. LARRY FIORINO: Unfortunately, that's all the time we have today. Thank you to everyone for a lively and informative discussion. STEVE KOZAK: This was truly one of our best panels, a very rich conversation. Thank you to our panelists. Thank you to you all for coming out. Thank you to our sponsors and Doug and Qorvis Corporation for being a sponsor. |
|
|
