Kicking off day two of the Gartner Open Source Summit in Phoenix, Gartner gurus Yefim Natis and Niko Drakos hosted a "Mastermind panel" featuring Stuart Cohen (OSDL), Brian Behlendorf (Collabnet) and Mike Milinkovich (Eclipse Foundation). Here's my best efforts to capture the session in real time and I think I got about 90% of it. If I didn't get the words completely accurate, I hope I at leat captured the spirit of the conversation. Some of the converation is a bit basic, but that's partly a reflection of the fact that Gartner is aimed at the mainstream.
Yefim: Thank you everyone for joining us. Today's panel we have three of the top people driving open source. I will play devil's advocate in some questions and I hope no one has any tomotoes or throws anything. Let's start with Stuart. What is it like being the boss of Linus?
Stuart: Linus is free to work full time on the kernel in a neutral non-profit environment. I don't think anyone is really Linus's boss, but we get information from conferences like this and bring it back to him.
Yefim: I'd like to be a fly on the wall when you do his performance review. (Laughs.) Does OSDL focus on more than just Linux?
Stuart: Linux is now at 18% of all servers worldwide, so now OSDL is involved in mobile market, smartphones, other areas of the server. We focus on how to leverage open source more broadly.
Yefim: Mike tell us about what you're doing at Eclipse.
Mike: Eclipse will be celebrating its 5th year anniversary in February 2007. It's made a significant impact in its lifespan, even though its not been around as long as other projects. It originally started as a platform for building development tools and is most famous for its Java IDE. It was spun out of IBM in 2004 as an independent organization. Eclipse has a good governance model for enabling many companies to work together. There are now over 140 member companies and 60 different projects. Much like Apache expanded to many projects, Eclipse has gone from the Java IDE to a much broader range. We are mostly focused on frameworks and tools, but now also looking at runtime environments, such as the Eclipse Rich Client Platform (RCP). RCP works well on Windows, Vista, Linux, Mac. A lot of people care about heterogeneity on the desktop. An area Eclipse is deeeply involved in is the Embedded market. Eclipse is now the basis of the tool chain for virtually every real time OS including, Monta Vista, Windriver and others.
Yefim: What is the process like for committers? How many do you have? How many are from IBM?
Mike: Eclipse has about 740 committers, roughly 45% of that still comes from IBM. We'll never turn away a project idea or committor from IBM, but in 2 years we've gone from 80% to under 50%. We have 10 major topics and 64 projects, some are just getting started.
Yefim: Brian, you've had major roles in three significant open source areas, with Apache, Mozilla and Collabnet. Give us a bit more background.
Brian: Apache got started in 1995 as a group of webmasters that there was a need for a better webserver out there. There was no single "Linus Torvalds" of Apache; we wanted a consensus-driven approach. In 1998 we formed an apache non-profit organization to provide legal protection to those working on it. We also realized the structure would help us scale beyond just the web server, such as server side java, middleware and so on. It's a membership-based organization based on the individual contributors, not their companies, not who they work for. It's about how we build healthy software development communities. We've been a neutral ground for companies like IBM, Oracle, Sun and invididuals. We recognized the consensus-driven, highly distributed approach led us down a path towards something more generalized. In 1999, I built Collabnet as a company, around tools for version control, issue tracking and how we make the ad hoc information part of a software development process. For the last 7 years, we've provided that as a service to companies, to public open source projects. The majority of our business is about building open source collaborative communities inside companies. Sometimes on a private or semi-private basis between companies or organizations. We try to coordinate the cooperation between lots of people.
Yefim: Why did this need a separate organization?
Brian: Apache is a non-profit. I felt the mission was different for Apache than from Collabnet. I felt that Collabnet could help companies figure out how to collaborate internally before they could collaborate publicly on projects.
Yefim: I'd like to play devil's advocate. Why should an enterprise user of technology in a corporation, spending decades working with Oracle, BEA, Microsoft, IBM, Sun, why should they switch to open source, based on a bunch of "unknown enthusiasts?" But, please, don't throw anything at me!
Mike: first of all, there's no need to switch. Every company on that list, except Microsoft, is building a reliable business based on open source. If you've used Websphere, for example, you're already using software that includes open source. But I would not characterize open source as a 'garage band' approach to software. There are many people in the open source community that are enthusiasts, but at Eclipse, for example, 85% of committors are full time employees of companies.
Yefim: Isn't this a conflict? Is it really independent if the committors work for companies?
Mike: Yes, it is independent. But it's collaborative. The contributions are made available to everyone on the same terms and conditions. Many marketing guys don't understand the difference between a partner program and an open source effort. Open source provides a level playing field so that people work under the stame term & conditions. Independence and governance is important to look at.
Stuart: It's simpler than that. Why do companies buy software? Because it solves a problem. Why do companies do business with startups? You do it because of the value. You have a business problem and they can bring you flexibility, security etc. You shouldn't look at acquiring software as a closed versus open mentality. You need the same decision criteria.
Yefim: Yes, but in your case, Linux had a major milestone with the endorsement of HP and IBM. Is it necessary to get that endorsement?
Stuart: Whether it's Apache or Linux, what's been proven is you can collaborate and create a community. How the code gets developed, the leadership model, how the code is supported, these models are all different. There are different deployment and support practices.
Brian: There's a myth that you can treat software as a blackbox. For mature products, sure. But in other cases, whether its commercial or open source, it's not always fully baked. The ability to see beyond the docs and the API and see underneath the covers is important. Even for a database, or groupware or CRM, you want to see what's going on, even if its just occasionally. Your technical folks need that ability. It's essential. Just like buying a car, you want to have access to the engine. The ability to treat software as more than a black box, is essential to get the job done.
Yefim: I'd like to ask the audience, how many have looked inside the code. Ok, the majority. And how many have changed the code. Maybe 30-40%. So that's a significant distinction. How many of you used consultants or third parties to make the change. Mostly nobody. So you need skills in your organization to be able to look at the system software, make changes and take responsibility. So you need the skills to maintain that effort.
Brian: You need a process and systems to manage the changes. For managing patches into the mainstream.
Yefim: There is some argument for chosing open source or for not chosing it. When should companies favor open source and when should they prefer to stick with closed source? Is there any situation where closed source is preferred?
Mike: this is not about religion. If you can get the solution you need from closed source, you should do it. It's not an either/or proposition. There will be a symbiotic relationship for a long time. If you look at the average stack built in a company, 80% of the software is not a differntiator. You end up building software that really doesn't matter. There's 10-20% at the top that matters. So focus your energies on what matters to your business. If you can get the 80% from open source, or you can buy it, great.
Yafem: Interesting, no one has brought up price. But that's what I hear from customers. That price is a key reason they look at open source.
Nikos: Here's a question from the audience. What practical advice can you give on contributing to open source projects. What advice do you have for CIOs and managers to make sure it doesn't become a distraction?
Brian: First of all, make sure people are using open source. Make sure they have training to use it. Drive it as a skill set focus so that engineers are staying fresh, with technologies like Ruby on Rails, Ajax etc. As a part of using the technology, they will start reporting bugs, asking questions of the community. Work ahead of time with your legal department so that you know how people can participate and contribute. Make sure employees know its safe to participate. If you find something that's necessary but missing, consider making that contribution.
Yefim: Most enterprises are not able to contribute at the OS level. Is that a distraction?
Stuart: Just as you ask employees to get certified on Red Hat, Microsoft, Cisco, you should look at the areas they work on, can they participate in areas that matter to the company. A lot of companies start with figuring out what the participation should be. What are the rules. Make sure everyone is comfortable with it. You need to dispell the myths, put the process in place and then move on. Relating to Linux specifically, the vast majority of Linux kernel contributors work for vendors or adopting companies. We have people who participated in our customer advisory board three years ago and now they're contributing. They had technical issues that needed to be solved and now they are participating and contributing because they see how these things are being used inside their organizations to their own competitive advantage.
Yefim: What I'm hearing is that the benefit is that you develop internal expertise with products you depend on. That's going to pay off at some point. That's a price worth paying.
Brian: The buzzword is 'center of competence.' You need to share knowledge. Find the different experts within your company, bind them together, give them a common place to work together. Even a financial services company can contribute to the Linux kernel, for example by testing patches, sending the information back into the kernel team.
Nikos: Here's another question. What if someone wants to contribute code, but they want to do it anonymously. What if they want to be shielded? Would you accept the code?
Mike: Absolutely not. We will never accept it without clear origin of the code. Everything that comes into Eclipse is completely transparent who wrote it. That's a basic principal.
Yefim: Can someone sign a contributor agreement and keep it secret?
Stuart: No. There's a certificate of origin that goes with every piece of code that's submitted. The developer is stating that it's their code. That's why the SCO lawsuit is a complete fiasco for SCO, because this process is in place.
Yefim: So who owns the copyright and the trademarks to the code?
Brian: Apache contributors sign an agreement. It's not an assignment of copyright, but it gives Apache the right to redistribute and modify the code. Apache owns an aggregate of all the contributions. That's why we have a copyright. If it turns out a contributor intentionally or not had something they shouldn't have contributed, the contributor is liable. But its never come to that.
Yefim: Is that a common model?
Mike: Eclipse has some subtle differences. We believe very strongly that the people who consume our code know we can trace the origin of all the code in Eclipse. Eclipse foundation has 3 full-time paid staff, including a lawyer who scrubs all the code. IBM, SAP, and other members also review the code. The code that comes out of Eclipse is carefully scrutinized. It's far and beyond the scrutiny of code than found in commercial closed source software. We have more checks & balances in open source than a typical software company.
Yefim: Sure because the code is visible. So if Eclipse is a legal entity could it be acquired?
Mike: No, it can't be acquired. Eclipse is a 501 C6 organization which has no shareholders. Like Apache or Mozilla. None of these can be acquired. Sure Red Hat, MySQL, Jboss could be acquired.
Brian: Mozilla is a 501 C3 non-profit for the public good. We created a for-profit subsidiary for Firefox, so they could create commercial relationships with search engines. But its owned by the non-profit, guaranteeing that the code is for the public good.
Nikos: What about patent indemnification? Is this a problem? How can it be handled?
Stuart: The quick answer is that patent infringement against open source is not an issue. There have been threats about patent holders using their portfolio against open source, but I think its just noise. There's no practical way for it to happen. As a user I don't think its an issue. There are many vendors providing indemnification. Many users ask about it, but when they have the discussion with their vendors, they get comfortable and it's not really an issue. There's more of an education issue.
Yefim: Open source providers say its more a perceived threat than a real threat.
Stuart: You can probably get indemnification from some vendors. But its not really needed.
Yefim: But there's an ongoing set of patent issues in the software industry, whether its open or closed.
Stuart: That's a longer discussion.
Nikos: Brian, how do you establish an open collaborative effort in a traditionally closed company?
Brian: You need a toolset to enable collaboration, so you should buy Collabnet (laughs). Many traditional tools don't make it easy. Look for pilot projects that involve developers at different locations. How do you enable a developer in another area of the company to contribute? You need to move beyond conference calls and hallway conversations. You need to be clear about producers of interfaces and consumers of interfaces.
Yefim: One of the contributions of open source and its momentum that it brings to the software industry is a new way of software engineering. It's more disciplined and collaborative.
Stuart: We saw this happen at OSDL. For example, we took on scalability with the Carrier Grade Linux project where Nokia, Ericsson, Intel, HP, Monta Vista and many companies worked collectively to create a scalable Linux for the wireless industry. We're now getting requests from, for example, the insurance industry. How can we help them be more collaborative?
Yefim: Open source is more than just software, it's a model of collaboration.
Nikos: Stuart, what about security?
Stuart: The reason we got involved in scalability was that developers didn't have access to 4-way, 8-way, 16 way servers. In the area of security, there are now many companies involved. It's not something that OSDL is involved in directly, its at the kernel and subssystem level throughout Linux.
Nikos: With Apache, the individual is the lowest level contributor. At Eclipse, you have to be a commercial organization effectively. Is that true?
Mike: One of the misconceptions is that Eclipse is that it's "pay to play" and you have to be a member to contribute. Any individual can contribute by showing up and helping and gecoming a committer. Roughly 15% of our committers fit that role. The difference between Eclipse and Apache is both a matter of style and substance. At Apache it's all about the individual. At Eclipse we think code is pretty important and more important than the individual. We're also different in style. For example Eclipse committers can use their work email from BEA, Iona, IBM. At Apache, you use your personal email. Its's a different culture.
Yefim: Open source has penetrated the world of software. We have open source platforms, middleware, databases and applications. Open source is contirbuting to the industry. Not just the software, but new ways of software engineering and design. It's a benefit to developers, to the enterprise, to the industry, to merge the best of open soruce and closed source to move forward. We will continue to talk about open source in the future. And you will find yourself using it more and more. Thank you everyone.