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, but 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

A week ago I was invited to participate in he Hanselminutes postcast by Scott Hanselman to talk about Nancy and Micro Web Framework. The recording for episode #270 can be found at Nancy, Sinatra and the Explosion of .NET Micro Web Frameworks with Andreas Håkansson

I had a great time talking to Scott, who is an excellent host, but one thing I did not get an opportunity to do was to extend my gratitude to the awesome people that are forming up a community around the project, everybody from the people that blog, tweet, screencast or in some other way help Nancy grow into an awesome framework – so thank you to all of you!

The following people have all contributed to the Nancy repository and have helped us get many of the awesome features and bug fixes (if your name should be on this list, but it not, please drop me a line and I will get sorted out!)

Andy Pike, Bjarte Djuvik Næss, Chris Nicola, David Hong, Graeme Foster, Guido Tapia, Hernan Garcia, Ian Davis, Jonas Cannehag, José F. Romaniello, Karl Seguin, Luke Smith, James Eggers, Jason Mead, Jeremy Skinner, João Bragança, Johan Danforth, John Downey, Maciej Kowalewski, Martijn Laarman, Mindaugas Mozûras, Patrik Hägne, Pedro Felix, Piotr Wlodek, Phil Haack, Robert Greyling, Simon Skov Boisen, Steven Robbins, Thomas Pedersen, Troels Thomsen, Vidar L. Sømme

I would like to extend a special thank you and shout out to my friend and co-conspirator Steven Robbins a.k.a @GrumpyDev on Twitter. He is a continuous source of awesome for Nancy and the project is better for having him onboard, that is one thing I am certain on. Thank you buddy!

It seem that every 3-5 month or so, the discussion on the state of the .NET open-source community flairs up. Some say it’s a dead horse being beaten, other that it’s a vibrant, thriving community. Sound familiar? Who cares?! Seriously, who cares? The right thing to do in either case is the exact same thing; keep injecting more value into it!

If the movement (if you can call it that) is truly dead, then what? Do we just roll over and play dead, or do we add more value to it and help breath new life in to it? If your answer is the former then you are simply not an open-source kind of guy. Now imagine that it’s is, in fact, a vibrant and thriving community, full of goodies to choose from. What should be do then? Stop adding value to it since it’s already doing well, or do we keep on pushing to add even more value into it? We keep adding value, of course, if it wasn’t already obvious that would be my answer.

Alright then, how do we inject move value into it? Contribute to an already active project or start a new one? It truly depends on your visions. First of all let me make it perfectly clear that I think diversity is not only a good thing, but a sign of a healthy community. There is no single “silver bullet” that will solve all problems or in a way that out domain requires them to. It’s very rare for a “all-in-one” solution is the best for your scenario and that’s why I believe opinionated solutions is required.

Everybody won’t agree to a single opinion, it’s just not ever going to happen, so how could a single framework or product be the solution to all problems we face in our industry? It can’t.

The first thing you should get out of your head is that your source code is where the gravy is. Sticking to that story won’t get your very fare. Any decent programmer can probably reproduce any functionality with their own implementation. It might not be as fancy as your solution, but I’ll bet you that it would work well enough to solve the problem they were facing – they’d see to that.

So if the value is not in the source code, that you’ve spent weeks, maybe months, perfecting and to work just the way you wanted it to, with all the fancy solutions and patterns in place, then were is it? It’s in the vision of the source code. The vision is the heart and soul of your project and it’s what will ensure that the project can live on even if you loose interest. It’s your opinions on how things should be done.

Now, of course, if you vision is nearly the same as the next guy and all you do is pinch his source code and call it your own thing, then you’re just being an ass hole. I’m sorry, but you are. If you have a clear idea on how you thing a certain set of problems should be solved, that’s when you have the foundation for a nice opinionated solution…that’s the vision of your project.

The vision of the project should be set in stone before you make the first public release. Be careful to be blinded by the massive amount of suggestions and contributions that you might be getting. If they will lead you down a path that is not true to your vision – ignore them. Send them a “thank you, but this is not for this project” and if they don’t like that then they should distil their visions into their own project. It’s impossible to say which would be the better solution – heck, why can’t both be just as good but suite different people? Diversity.

If you nurture the vision of your project well enough and attract equal minded people then you have started a community and they will make sure the project stays true to the original vision, trust me. Should you suddenly loose interest in the project, or for some other reason not be able to commit to the cause anymore, the community can simply fork and create a new authorities branch. This has happened time and time again in many of the big open-source projects.

I’m happy to say that I keep seeing the diversity in the .NET open-source community grow as we speak. I keep seeing more and more small, opinionated, projects pop up and that they are being embraced by a subset of our community as a whole. Sure, the .NET community has probably quite a bit more to invest in open-source, but it’s getting there and the only way to get there faster is to be part of the ride!