Open source maturity models


In Bill Hilf’s latest post from his somewhat counter-intuitive position as head of Microsoft’s open source laboratory, he mentions a Carnegie Mellon West initiative called OpenBRR. This is an attempt to assess the business-readiness of open source software. In other words, if you want to adopt a particular piece of open source software in your enterprise, how ready is it for a production system?

To quote from the introduction:

There is no widely used model for evaluation. This complicates open source adoption, as companies assessing open source software can rarely learn from each other’s experiences.

A fair point, but is a formal standard the answer to this problem? It seems like there is already a lot of formality about open source development because you are replacing a closely-knit development team with a looser congregation of individuals and the only way to manage this is by having high-quality source code management processes. So in that sense, some formality from the user side fits nicely with the supply side disciplines.

On the other hand, open source development is supposed to be a new paradigm for a new era. Is it right to hamper it with old-school technology evaluation methods? The OpenBRR proposal builds on two existing maturity models, Navica’s Open Source Maturity Model and Cap Gemini’s equivalent. The target audience for these processes seems to be decision-makers who would be more comfortable buying big iron from IBM.

The OpenBRR specification is not bad in itself. In my organisation we used a very similar proces for evaluating BPM software not so long ago. We faced the same challenges: (1) reducing a large number of potential vendors down to a manageable shortlist and (2) making sure our efforts were shared and available to other technology teams to prevent them having to go through the same expensive and time-consuming exercise themselves.

In this respect the process was no different between open source and traditional vendors. An open approach to sharing these results is a great idea, but I’m not sure it needs anything other than a public wiki to do so.

Advertisements

2 Responses to “Open source maturity models”


  1. 1 Ian Rogers May 12, 2006 at 14:30

    The “Old Skool” method of software procurement would include writing a functional spec., issuing RFIs and getting vendors to tender.

    But with free (as in free beer) open source software there’s no vendor as such, just the developers (who don’t “do” selling). So the purchasing IT department has to evaluate the software itself. – this is probably a good thing given all the blarney that IT sales reps. normally dish out by the shovel load :-)

  2. 2 Andrew Yeomans May 9, 2006 at 15:38

    Practically everything I’ve seen that says you should specially treat Open Source evaluation / procurement / deployment has an alternate agenda of instilling FUD. As you say, the process should be no different between Open Source and traditional vendors, with the exception that you can get personal assurance on code quality, lack of copyright infringement, support responsiveness yourself, without having to trust what you are told by the vendor.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: