Reasons to participate in open source
Tim Bird's notes on participating in open source.
Other people's talks
Many people have written papers or given presentations on the value of participating in open source. Over time, I may collect the ones I know about, and list them here.
(For starters, there are the excellent presentations by Andrew Morton and James Bottomly) Andrew Morton gave one of the best talks I have heard, at Embedded Linux Conference 2008 See: Session:The_Relationship_Between_kernel.org_Development_and_the_Use_of_Linux_for_Embedded_Applications_ELC_2008
James Bottomley gave a great talk at LinuxCon Japan, 2011 (I think), where he described the reasons that it is valuable for a company to contribute to open source. I'll try to get a link to the talk and any video that was recorded.
I'm sure that Greg KH has given talks of this nature as well.
my old talks
[Note to self: Look up my old talks.] In the early days, I presented on this topic a lot, but I haven't recently. However, many companies still don't participate in open source like they should. I should put some links to my own talks here.
Some of my ancestors crossed the plains and mountains of the western United States as pioneers. One interesting story from this era, was that earlier parties would perform work for parties that were to come subsequently. In one extreme example, one group of pioneers planted seeds, another group of pioneers tended crops, and a later group of pioneers harvested the crops, all along a route that none of them expected to visit again. The first two groups put in labor that benefited the third group.
One question that arises, is how could the third group contribute to the first group's work? They couldn't plant the seeds, because they weren't physically there. They couldn't break the trail, because they came later. Even though they benefited from the work, they couldn't help with it initially.
Now, software development is not nearly as linear a pursuit as is crossing (what to them was) a wilderness. However, there are parallels.
Companies often don't have the expertise to contribute upstream. Even long-term users of open source software may be several versions behind the upstream releases of software they are using. This makes it difficult for them to contribute in a meaningful way.
However, companies can hire experts, and have them work directly on the upstream source. This would be similar to a pioneer company sending a few of their individuals in the advance parties, going ahead of them to help guide the initial group, and help break the trail for their passage.
One difficulty is that it's very difficult to measure the value of such people to the group that sends them ahead.
Companies used to put a lot of effort into standards organizations, because by controlling what standards were adopted they could help themselves and hurt their competitors. When standards are needed for interoperability, if a company invests in a particular technology by developing it for market and integrating it into their products, if that technology becomes a standard, they have leveraged their investment. Network effects make that technology more valuable. If something does not become a standard, then the opposite happens. Network effects tend to discourage adoption of the technology, and the investment can be a total loss.
For this reasons, for particular standards there were huge, costly battles to promote one technology or another.
This is tree to some degree with open source software as well. A first-mover in providing an upstream implementation has an advantage against their competitors. Admittedly, the advantage is less, since competitors can use the open source code sooner than they would if the implementations were proprietary and unavailable. However, there is still an advantage to the entity that has their code accepted upstream.
List of reasons
- control of direction
- first-move advantage
- reduced maintenance cost (vs. maintaining out of tree)