The open-source maturity model
The discussion, about what constitutes OSS and not, have been going on on Twitter and the .NET blogosphere for a couple of weeks now. The root of it all has been whether or not Microsoft should call their work with ASP.NET MVC as open-source or not. Reading what has been said and taking part in the discussion myself I feel that quite often the discussion is clouded by our individual thoughts on what constitutes as open-source or not, rather then what the actual definition states.
So what does the definition says? Well we can look at the Open-Source Definition, by the Open-Source Initiative, and the Free Software Definition, by the Free Software Foundation for guidance on that. I won’t recite any of sources because both have very clear definitions on their websites.
What’s missing from this picture?
There are a couple of things missing for both of them. Things like when and how often do you need to make source code publically available? Do you need to develop in the open, with public roadmaps and feature discussions? Do you have to accept code contributions or not?
For the most of us (?) those are no brainers; you should put code out in the public as quickly as you can, engage in discussions with your community and accept contributions with open arms as long as it is true to your vision.
However these are all values that we, as a community, layer on top of the definition of open-source and open-source software. These are things we have seen help increase the transparency in our projects, help improve quality and add more value to our work.
You can take all of that away and still do open-source, but you are selling yourself short (if you ask “us”) if you do.
What can we do?
You tell me! One idea I had tonight, while arguing about this on Twitter, was that maybe we need a way to measure the maturity of open-source participation of a company/product.
If you’ve ever read anything about REST you may have come across the Richardson’s Maturity Model for services on the web. Basically it’s a measuring stick for how far you’ve come with your REST adoption. Check out the link so read about the 4 levels of the model.
What if we could apply the same idea for open-source? What if we had something like this
- Level 3. Accepts patches
- Level 2. Make code available on a regular basis
- Level 1. Develops in the open
- Level 0. Compliant with the OSI / FSF definition of open-source
These maturity levels aren’t something I’ve been philosophizing about for a long time, in fact they popped into my head about 30 minutes ago while I was engaged in the Twitter discussion.
Just to be crystal clear; The number of levels and the the definition of each level is not something I would consider set in stone at the time of the writing.
Instead I hope they can inspire to some interesting discussion and perhaps even a consensus on what such a model should look like.
Maybe I’m just talking out of my ass here or maybe I am onto something. Either way, let me know in the comments. I personally thing something like this could help out when we, the community, talk about open-source and open-source software