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
I think it’s a great idea that makes more sense than the RMM since you actually get more value the higher up you get 🙂
I think Developing in the Open and Accepting patches should be expanded to include enhancements, features, bug-fixes, issues, feedback, etc.
There should be a tight feedback loop with the community who should be collaborated on all major decisions to ensure the project is heading in the right direction.
Although this really needs an info graphic to be complete with a halo above the “Glory of OSS” label 🙂
Keep up the good work!
Interesting post. I think there are two broad categories of OSS project.
1 = here’s something I made, and you can use the code if you want, but don’t expect anything more from me (no updates, no support, no accepting patches). A lot of developers release small projects like this, and I don’t think it should be thought of as second class OSS. It is just realism – a lone dev does not have the time or inclination to keep the project going beyond the purpose that it was originally created for. People who want more can fork it and take it wherever they want.
2 = here is a library/app that we have future plans for, and want to build a community around. This is where the real frustration comes in if that community find themselves in the dark about what is being developed, or unable to contribute features/fixes, etc. Your maturity model would fit well here. I would perhaps consider adding how they deal with bug reports. Not every user of an OSS project is in a position to fix bugs, but a “mature” OSS project should be making some efforts to address issues found by the community.
I think that Level 1 and Level 2 are the wrong way around. If you are developing in the open you’ve already been making your code available.
Of course I don’t think just giving a roadmap, or saying what features are coming is developing in the open. Almost every product does that.
I think I disagree. You can talk about features, stuff that should be included in the next release etc, with your community but still not make the source for the features available until you are ready to release a new stable version
But then nearly every product ever made fits into the scale. How often do companies (not counting apple) actually develop behind a curtain and then go, here’s the goods? I think that’s still treating the community as customers, and not members.
I think that’s one of the key things as you move up the scale. You go from having customers to having members. Now not everyone would ever send a commit, but to get that level of engagement it’s beyond just “using the product” to actively contributing to it.
Thank you Kevin, that’s a fair point
I vehemently disagree. To call it a “maturity model” implies that if you don’t progress between levels you are doing something wrong. Accepting patches has nothing to do with a project being open source.
I see your point and name suggestions are welcome. However Richardson’s Maturity Model doesn’t state that you need to advance in order to be doing things right.
Neither did I state that accepting patches had anything to do with open-source. I quite clearly pointed out to the defacto definition(s) of open-source, but also pointed out that we, the community, have added additional layers of values that are used in debates.The concept still stands though. You have the OSI/FSF definition of OSS and then you have the tacit / community consensus on things like transparency, upstream and so on.
Giving numeric values and implying that those numbers represent growth implicitly doing something better, don’t you think?
Accepting patches is an orthogonal concept to open source. And trying to get them in the same model doesn’t make sense to me.
(1) Well said. I have a few of those out there myself, and in turn have consumed other people’s petrified projects. This is the long tail of OSS, and that really is its power. Fork and continue…
(2) I feel like there is a creeping entitlement attitude percolating through the interwebs towards these types of projects. At the end of the day, if a project meets Level 0 criterion (to even be called OSS), you can always fork and continue as well. Granted, this is often a bit less trivial than the Category I codebases.
Having been peripherally involved with a couple of Category II OSS projects, I now appreciate how hard it is for the leaders of these efforts to keep things moving forward. I also appreciate that from the outside, it’s hard to understand the constraints these projects often are run under. My personal experience is that, if there appears to little or no community engagement, the principals would rather you just fork and continue anyways. Send a pull request, but don’t wait on them to, or even expect them to, accept it.
I like the maturation model paradigm, but only insofar as it relates to helping people set appropriate expectations. Now if only ohloh.net would respond to my repeated requests to add this feature into their project profiles… ok, just kidding.
Rather than quibble over definitions, I think it might be better to observe why Node/Rails/Django/etc are able to explode as effectively as they are.
Read this:
https://github.com/visionmedia/express/issues/1032
Open Code, Open License, Open Sesame – who gives a shit. These are tools for us to use. We wait while corporate machines have design meetings and align strategies… meanwhile our customers wait while we write boilerplate code that’s been solved already.
Ridiculous.