Summary
A recent Java.net interview with Ron Goldman focuses on how businesses can build and nourish open-source communities. Goldman differentiates between user groups and true developer communities, and highlights when open-sourcing a company's product makes sense—and when it doesn't.
Advertisement
Ron Goldman is a senior engineer at SunLabs, and as Sun's shepherd for projects such as Jini, OpenOffice, NetBeans, JXTA, and java.net, has had a long interaction with open-source communities. Goldman and his long-time collaborator Richard Gabriel, wrote a book about their experiences with open-source in the context of a business. The entire book, Innovation Happens Elsewhere, is available on Goldman's web site.
Interaction between open-source communities and businesses is important because, as he mentions in the interview, open-source is very reliant on corporate support, and corporations are increasingly relying on open-source software for their IT operations. Goldman notes that about "30 percent of the people working on open-source projects are paid to do so as part of their regular jobs."
In addition to the possibly of higher-quality output, a business benefits from open-sourcing a product by a greater chance of getting the product right the first time, according to Goldman:
When designing in the open, you get immediate feedback such as, "Well, that's not what I want to do with this," or "Why doesn't it do this or that?" And so you can build things right the first time... Most software projects fail not for technical reasons but because the product they build is not one their customers want. You must be flexible enough to take the information your community gives you and use it. If you fail to recognize innovation or simply slough people off, you can miss opportunities.
At the same time, open-sourcing a product will likely not save money for the business, at least in the short run, according to Goldman:
The biggest misconception managers have is that they can cut back on the number of people in their group working on a project by making it open source, because the community will pick up the slack. Actually, it's just the opposite: An open-source project takes more resources than an internal proprietary one. Employees working on open source might spend an additional 25 percent of their time on community interaction. It costs more to do open-source development, but the benefits of better design and increased quality justify those costs.
Goldman also talks about the importance of establishing trust with outside developers in order to gain their input, both in opinion and in source code:
It's harder for a company than an individual to sponsor and run an open-source project. Everyone tends to mistrust a company's motives, so it's very important to be up-front about how the open-source effort is part of the company's business strategy. If it isn't clear how the company plans to benefit, then potential contributors will be suspicious and worry that they will somehow be exploited.
Finally, Goldman suggests that open-source as a methodology can be used even inside a company or in gated projects between business partners. As such, open-source is both a process as well as a community-building tool, according to the interview.