[Update: Nate was kind enough to link so we could enter a conversation]
Yesterday, I made a certain comment on a person’s decision to release something in open-source, and they made a certain comment, and I’m very disappointed…
I could’ve started this entry like this, without providing you quite enough information to enter the conversation yourself. This is the way Nate decided to go about it in his entry last night entitled Open Source is not a Zero-Sum Game.
Let’s see what happened.
Nate - [Announcing the release of Siesta]
Victor - @nkohari seen snooze http://tr.im/wamQ ? why the need for siesta?
Nate - @vkornov Hadn't seen it.
Victor - @nkohari you need to ask on twitter before coding your own ;)
Nate - @vkornov Eh, nothing wrong with different approaches to the same problem.
Me -@nkohari if it was a different approach or a different problem, maybe. If it does the same as other REST frameworks, it's a waste of time and resources.
Nate - @serialseb Then don't use it. Sorry to bother you.
Me - @nkohari that's not the question that was raised by Victor, but fair enough, i won't use it. Meh.
Nate - I'm really disappointed to see people complaining that I open-sourced part of my commercial product. Sorry, next time I won't try to help.
So now you have the background. I won’t go and bore everyone with the countless support messages Nate received telling him to ignore the whiners and naysayers, I’ll let you decide for yourself if this was worthy of such a long rant.
From the system builder: don’t build it
Leaving aside the non-conversational aspect of Nate’s entry and twitter messages, there’s a couple of points I think are worth discussing. As I intend on having a conversation about this stuff, comments are open, you can name me in your blog and leave links to your blogs in there, I’ll add them to this entry.
When you require infrastructure code, you should always ask yourself this question: Is it worth me building? This is the Not Invented Here syndrome, and unless your business model is to reinvent the wheel for IP protection reasons, it’s an expensive process, as not only do you spend your time building it, you’ll have to maintain it.
There are two reasons why you’d want to build something. First, there is no equivalent on the market that can solve your problem in the amount of time it’ll take you to build it yourself (or slightly more as, as seen before, you’ll have to add the maintenance cost). Secondly, if the existing solution is poor and there’s no easy or cheap way to make it better.
If you’re building stuff for any other reason than the two above, you’re generating waste, spending time building code that is not going to give you a competitive advantage or serve your product / user.
That’s the point I tried to make in my twitter conversation. If it’s a different problem or if the solution is innovative, then maybe there’s nothing wrong with a different approach. If it’s the same, with a new brand, then it is a lean:waste. And there, I agree with one of Nate’s sentences: rolling your own is not always waste (emphasis mine).
From the open-source maintainer: do as you wish
The second part of the conversation is about open-sourcing code. I think those are two different conversations to have, as one doesn’t usually have the same waste-eliminating concerns when dealing with open-source.
Open sourcing code is great. I love doing it, so do others. And a myriad of frameworks pop-up, thanks to open source. Just in the ReST space, you have Snooze, BistroMVC, Restful MVC, now Nate’s Siesta, and of course OpenRasta. I’m pretty sure you could achieve some of the same results with FubuMVC too.
The question is not if multiple projects are good, they foster innovation by providing new ways to think about a problem, and new best practices start to appear. I know I am taking in a lot of ideas from all of those frameworks for future versions of OpenRasta. Competition is good.
I do still believe in eliminating waste in open source though. Call me idealist, but I don’t see why everybody would reinvent the infrastructure stuff. Pipeline models, asp.net integration, all those frameworks share some core infrastructure aspects. Why do we all reinvent the same problem over and over? Because we’ve not been collaborating to ensure we have communication in place.
That’s why I told Chad Myers many times: It’s great to see another frameworks with really good ideas, it’s a shame we’re duplicating effort endlessly on parts that are not bringing much innovation or value.
But I suppose that’s the state of things. The bazaar model requires that we’ll all come up and only the solution with the most market leverage will survive. Yes, we’ll have 250 ReST frameworks in a year time. And in two years, only two or three will probably see any usage at all. In the meantime, we’ll have wasted hundreds of hours of developers time.
Maybe the innovation will be worth it, but I’m still unsure if we’ll ever reach even.
Final words
So there you go, here’s the core of the question. Fragmentation doesn’t always lead to innovation, collaboration and discussion can prevent people going in a direction where they don’t innovate but just recreate it their way because it’s only 5 or 6 hours. Allegedly, Nate’s solution is simple and small enough that he’s probably not affected by this.
I don’t however believe that ignorance is a good reason to discard frameworks like snooze (which, by the way, is the one that was mentioned in the conversation, and the work of the ever excellent Andrew Davey).
As a final word, I’d like to remind everyone that one of the constraints of ReST is hypermedia. If you design APIs without any links, and advertise how to build URIs, you’re not doing ReST, your doing something else. It doesn’t mean you’re doing something badly, just that you’re not actually doing ReST.
