The signature attribute of the open source development practices employed by most projects is that change is fast, furious, and non-stop. The codebases for most community backed projects is almost always in a rapid state of change. Many blessings flow from this process:

• Rapid innovation and quick embrace of new concepts and capabilities
• A spotlight is cast upon defects and bugs that inflicted past versions of the software
• The rapid pace of development is a foundry for up and coming developers. If they have the chops they can make a name for themselves by pioneering new work. New members are the lifeblood of a vital and living community.

The disadvantage of these rapid code communities is also obvious: there is so much change that the codebase can become hard to grok.

Vendors can help by putting the brainpower (or sometimes just the boring brute force) required to grok the changes and backporting these changes to the version of the software employed by your product. This adds value by both through the creation of intellectual property (in the purest form… the understanding) and artifacts (the modified and tested patch).

There can literally be hundreds of thousands of lines changed between the product the customer is using and the version where the fix is expressed. Pulling out the few dozen lines that manifest the fix and backporting it reduces risk to the customer that has a fielded product.

Now I’m no pollyana who sees the world as only being helped by the behavior of vendors and the wide world of the open source communities as being some great unwashed morass of decrepit code. That’s not true. Thomas Gleixner at last year’s CELF 2007 opening keynote made some profound observations about the difficulty balancing community originated and vendor managed codebases. As both a recognized Linux kernel community participant and a vendor he has a great perspective on these matters.

The real conundrum is that change has real and concrete risk. Moving fast can be at odds with moving safe in the eyes of developers who are responsible for building commercial products rather than community projects. I’ve seen customers of ours be suspect of even taking periodic well understood kernel patches that solved identified problems in their products. Some commercial products are even prohibited from being updated.

No one person is right. No one group is wrong. There is just a real impedance mismatch between community speed and commercial speed in almost all cases that I’ve observed. Every company’s open source strategy (you do have one, right?) has to recognize and deal with this impedance mismatch.

ShareThis

This entry was posted on Thursday, May 8th, 2008 at 5:02 pm and is filed under support.