The state of open source: Avenues for acceptance

Roundtable: 11 leaders from the open source and vendor communities discuss the current open source climate and outline the challenges and opportunities ahead

Question 4: What are the next steps needed for open source as a software production methodology to reach the next level?

img96221.jpg

Matt Asay

Vice president of business development
Alfresco

Asay: If by "the next level" you mean widespread adoption, commercial success, and rampant fear within the proprietary vendors, aren't we already there? Seriously, open source has proved its merits as a commercial and development methodology. The only thing remaining is for a few industry laggards to stop consolidating long enough to realize that they have more to gain from open source than lose, but to gain they must act immediately.

img96216.jpg

Chris DiBona
Open source programs manager
Google

DiBona: The marketplace is still trying to understand open source, and so a better question is, How long until the business world understands how to best use and take part in open source software development? I think the answer for some companies is never; and others, well, that depends on the company.

img96222.jpg

Robert Sutor
Vice president of open source and standards
IBM

Sutor: More software development companies need to adopt internal software development models based on what we have learned from open source communities. We need more best-selling books on open source development models that are bought and studied by mainstream programmers. We need more people to ask, "Why wouldn't we open source this?" We need to better reward developers by recognizing merit and earned technical reputation.

img96220.jpg

Mark Spencer
Founder and CTO
Digium

Spencer: I think increased focus on the transition from project to product (especially through for-profit companies) will help carry open source projects from a more limited audience to the consumer markets at large. For example, Digium's focus today is not only on providing component hardware and software but on providing solutions for small businesses that are not only understood by consumers but understood by the traditional channel that reaches those consumers as well. I think that partnership between open source projects will also help improve their ability to interact with one another, thus helping innovate in the area of high integration. The power of that integration will in the long run help solidify the value proposition for enterprise customers, in particular.

img96219.jpg

Javier Soltero
CEO
Hyperic

Soltero:We need a better understanding of the economics behind the various business models used by open source companies. At this point, no company except Red Hat has been able to demonstrate the type of large-scale economic viability that is necessary for a software company to be able to innovate at scale while using open source. Many are trying, but we're not there yet. The reason this is important is it acts as the proof behind how a company can fund the development of product(s) that are delivered in an open source model and still stick around to realize the benefits. It's not a one-size-fits-all approach, so I would not expect there to be a single recipe that everyone can follow. However, I do believe that the whole equation needs to be considered in order for this to work -- low customer acquisition cost + continuous feedback and contribution from the community + subscription value + scaled R&D. The R&D benefits are the most difficult to realize for a company like ours [Hyperic] because the audience for the product is not composed of software developers and the software is inherently complex. It's a little like operating systems such as Linux ... lots of people use them, very few know how to build them.

img96215.jpg

Bruce Perens
Creator of the Open Source Definition
Co-founder of the Open Source Initiative

Perens: Well, we really are at the next step for a lot of software development. We define the best practices in software development today. After all, how many companies have software staff that are as motivated to work for them as the open source developers are motivated to make something that everybody shares?

Most proprietary software is written with the assumption that nobody's looking over the programmer's shoulder. With open source, the whole world is looking over the programmer's shoulder. Programmers write better code because they know that. Consider what happens today when a programmer is hired. How can any company tell much about the quality of their work? You can't get much good data out of their previous employer, if you can get any. But you can look at their open source code, and you can check out their interaction on the project's discussion lists and see if they are a team worker or a flamer. So, I think a lot of programmers realize today that their open source work is their résumé. That's a big quality incentive.

But what would I like to see for a next step? I would like to aim high. See that Macintosh desktop? It's got great consistency, it treats the user pretty well. Can we beat it? I think it's possible, but it would take strong leadership and a dedicated team.

When I left Pixar in 1999, Steve Jobs still didn't believe that open source could produce a good GUI at all. Two years later, he introduced Safari, which was derived from open source GUI work, while standing in front of a slide that said "open source, We Love It." I guess I won that argument.

img96218.jpg

Eric S. Raymond
Programmer, author, and
open source software advocate

Raymond: I think the need for languages and toolchains with provable security and assurance properties is growing acute. Though that need is not exclusively an open-source issue, the work to address it is going to have to be done in open source -- because who in their right mind is going to trust a closed binary blob?

img96223.jpg

Sam Ramji
Senior director of platform technology
Microsoft

Ramji: As a production methodology, open source development reduces to distributed collaborative software development with an implicit social model (power users, community developers, committers, leads, maintainers). This is largely independent of the scale of the project. Past models that have reached maturity have generally “arrived” when they are richly supported by tools (for example, object orientation and UML). We are already seeing team development tools on the market that are built around these distributed collaboration models, and include wikis, forums, and the typical features seen in open source forges.

img96213.jpg

Andy Astor
CEO
EnterpriseDB

Astor: If open source is going to become mainstream, then we are going to need guidelines, standards, and best practices around how to make a create a succesful open source project. And yet whenever you put too many guidelines, standards, and best practices on projects, they tend to lose their edge. Figuring out how to reconcile this contradiction is essential to moving open source forward.

img96217.jpg

Dave Rosenberg
CEO and co-founder
Mulesource

Rosenberg: Some of the tooling associated with group development needs to become more mature and needs to be able to be integrated effectively. Wikis and bug-tracking systems need to be integrated with build systems.

There are frameworks in place now that make distributed development easier, but it’s not yet easy.

img96224.jpg

Zack Urlocker
Vice president of products
MySQL

Urlocker: The most important next step is the emergence of what I call "Enterprise 2.0." It's time for mainstream corporate IT departments to look at the best practices happening in the Web area and determine how to make their own infrastructure and applications more Web-based. Companies like Google, Yahoo, Amazon, Travelocity are all running open source stacks meeting huge demands of their users for high availability, performance, scalability, and security. These are the same things that corporate IT needs. So I think there are lessons to be learned in making corporate IT more nimble and more cost-effective using open source software.

[ Roundtable home | Topic No. 5: Missteps and lessons learned ]

Copyright © 2008 IDG Communications, Inc.