Reasons to participate in open source

From eLinux.org
Revision as of 17:38, 19 April 2013 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Metaphors

Pioneers

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.