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! 

Shortly after announcing the first drop of Nancy, my friend Mark Nijhof asked me

“one thing that keeps sounding in the back of my head is; why not use Sinatra instead?”

The short answer to this is; If it makes more sense for you and your project to use Sinatra, then you should! However it is my experience that it’s not always that black and white when it comes the question “why don’t you use…?”. The answer really depends on what type of developer you are and the surrounding circumstances.

Now let me clarify that Mark said he liked Nancy and that this was just a feeling he got while reading the post. This post has less to do with Mark and more to the discussion about “why don’t you use…?” since it is a repeating topic that pop back up every now and then.

Say you are doing contract work, either on your own or at an agency. Here is depends on two things; do you specialize at delivering software on a specific platform or do you target a wider audience? Second, does the client have any demands on the platform and technology stack that you use?  So the ability to choose technology stacks in either of these situations should be self evident. If you are in a position where both the client and employer lets you choose the best stack for the project then you are in a sweet position!

Imagine you are working in-house at a product company, should you just be able to pick any technology stack that you feel is the best for the task? Would you let your employees do that if you were the CEO? There are additional costs for training team members and you risk in getting way too many go-to-guys, the people that have a passion for a certain technology. And what if some of these guys were to leave? Then what? It’s not that easy to recruite people with cross-technology stack experience, especially those with senior skills in all of them.

I know that at the place where I work it would not be a good idea to start building out products using django, ruby, scala – whatever – simply because our organization could not handle it. At least not today. And who knows what it will be like in another year? A couple of years ago we wouldn’t have been able to use Kanban efficiently, but we matured over time and today we use it with great success.

I am a firm believer of “use the right tool for the job”, but I am very aware that it’s not only the framework or programming language that defines what “the right tool” is, there are lots of organizational and surrounding factors that all have a play in that.