+972 52-548-6969
Why RavenDB is OSS
There are actually several reasons for that, not the least of which is that I like working on OSS projects. But there is also another reason for that, which is very important for adoption:
Joel Spolsky have an interesting article about just this topic.
When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed. "Trusted" doesn't mean that they were made by some big company that you're supposed to trust like IBM, it means that you know in your heart that it's going to work right. I think today most Windows programmers trust Visual C++, for example. They may not trust MFC, but MFC comes with source, and so even though it can't be trusted, it can be fixed when you discover how truly atrocious the async socket library is. So it's OK to bet your career on MFC, too.
You can bet your career on the Oracle DBMS, because it just works and everybody knows it. And you can bet your career on Berkeley DB, because if it screws up, you go into the source code and fix it. But you probably don't want to bet your career on a non-open-source, not-well-known tool. You can use that for experiments, but it's not a bet-your-career kind of tool.
I have used the same logic myself in the past, and I think it is compelling.
Comments
I think it's bullshit.
The main argument I have is that this only works when the tool is small. If it's bigger, the user who wants to fix things himself has to dig deep and spend a lot of time to grok everything in the sourcecode to understand why things are the way they are. (and please, don't come to me with 'but you can read the unittests and understand it' because that's even bigger bullshit).
So 'fixing' things yourself might sound 'cool' but it's really a hard thing to do, and often people don't have the time nor the skills to do that.
Additionally, another big issue is that if you make changes, you immediately move away from the progressive path of the original source. This means that if a new version is released, you have to migrate your changes over, which might be breaking or not mergable with the new release, and the more you change, the more you have to maintain yourself, as every change you make is YOUR responsibility till the application eventually dies, which can be over 10/15 years maybe.
Instead, people use tools which 'just work', and do what they are claiming to do. Found a bug? Report it and get a fix for it. That's 1) cheaper and 2) easier: no maintenance costs, and no time wasted on fixing unfamiliar sourcecode.
It makes great sense. Some companies however won't work with open source because it means extra legal paperwork for them to meet ISO standards etc.
That's easily overcome though by offering the developer a yearly support fee :-)
Got bitten by this recently: a hosted, closed source shop eventually seemed to lack some - to my opinion, relatively elementary - things we really needed (guess our assessment wasn't thorough enough). There's no way to get these features, but wait for further development or getting another (OS?) shop.
It looked cheap to buy a license and go ahead and use the package, but the closed model eventually worked against us. Guess the shop wasn't "well-known" enough :)
And how many people are actually contributing patches to berkeley DB? Most people only complain about that something is not working, but most developers don't have the time to patch most of the problems. They just file a bug report..
But what about Telerik controls? They're not open-source but when you buy it (with a subscription) you do get the source.
As a .NET developer I also use VS and R#. None of them are open-source, but they work better than every other IDE out there.
I Just use the tools and libraries that work. I use a lot of OSS like Ninject, Windsor, (Fluent) Nhibernate, but also closed libraries like the Wintellect threading library.
That's why I like really like things like GitHub. When I need to patch an OSS product I can quickly fork, make my changes and send a pull request.
More often than not, the change is then integrated and we don't have to deviate from the official version too long.
Now, when the change is not accepted this might be a bit annoying :)
@Frans
I agree with you but I think it's less bullshit ;)
What if your found bug is not fixed or is scheduled for a timeframe that will cost you money? Your customers are immediately affected by the found bug and they can/will not wait for it to be fixed. In such a situation you'd better have the sources and (try to) fix it yourself ...
I have done that, been there and was lucky to fix the problems but without the sources I would have been nowhere.
// Ryan
@Frans,
I can tell you that we routinely get patches to NHibernate and Castle Windsor . That 27 different people contributed code to RavenDB. That many complex projects gets a lot of patches, Linux being the obvious ones, but Postgres SQL is another complex one that gets patches.
It isn't something that happens all the time, but it does happen. And being able to do so is a great confidence booster for a project.
As for making changes, that is why you use something like Git, where you can actually do stuff like that and still stay on top of any changes that were made by the project. That means that keeping your fork up to date is literally no work at all.
I don't say that everyone will do it, or even that it is commonly happening as a precentage of the users, but it is happening very often. And it is a huge boost in confidence.
@Peter,
That is why RavenDB is dual licensed. You buy the commercial version and don't deal with the OSS version.
Dave,
Actually, a few.
Telerik handles things the same way, if you really have a problem, get the source and fix it.
R# & VS fall under the well known category, I think
That's even better then :)
Ayende,
I've recently hit the wall, when I found a possible (hence, existing) race condition in NServiceBus API. Repairing it would be a breaking change in the NSB API so it's a some kind of lock and not getting updates, at least for a while. How often do you get a proposal for breaking changes, and how often you introduce them?
For sake of reference: blog.scooletz.com/.../nservicebus-callback-failure
I'm not saying NOT having the sourcecode is BETTER (e.g. we provide almost all sourcecode of llblgen pro runtime framework + code generator etc. to customers too), I'm just saying that assuming that because you have the sourcecode you can fix things and that that is better for you in the end is stupid.
Sure people supply patches for nhibernate, but how many of them are actually included in the main trunk? Not all of them. But let's focus on the other aspect: what happens if I change things and I now have to maintain that change for the rest of the project's lifetime. That's a big burden. If you leave the project and someone else takes over, does that person know the 'nhibernate' powering the project isn't the vanilla NHibernate, but a custom made one, with altered code? that's a big burden for the maintainer.
Also, just because someone thinks s/he can program his/her way out of a wet paper bag, doesn't make that person capable of fixing a framework. For starters, the sourcecode of a framework doesn't come with design decisions, i.e.: which alternatives were taken into account and why they weren't (!) chosen. The handy-man coder who thinks he can fix a 'bug', doesn't know these decisions, and might fall into the pitfall of doing all the alternatives which were rejected all over again: spending a lot of time on a useless effort. Not to mention the fact that the person first has to understand what the code is doing and _why_.
Fixing a small tiny issue, that's not that hard, break in the debugger, hack some code around the problematic code to make it work, compile, go. What's far more complicated is to refactor some code to make a bug go away, make it better performing etc. That's stuff not a lot of people (if any) will do without investing a lot of time. I.o.w.: it's a fallacy, big bugs won't be fixable by the USER of a framework.
And, Ayende, how many patches did NH receive for fixing the lack of any groupjoin support in NH3? 0. Why? because it's complex stuff and takes a lot of time to get into that problem and know what to do to make it work always. Just by having the sourcecode and being able to tamper with it in an editor doesn't make the user of it suddenly capable of fixing things in that codebase.
My experience is to agree with Oren, but I'm not sure that Frans is far off either. What do I want from a framework:
1: The ability to try it in a non-commerical setting, learn how to use it so that I can recommend its deployment in a commercial setting from experience with it
.
2: The source. The old adage "Use the Source Luke" applies here. My copy of MFC Internals was well thumbed back in the day, and having the source was better documentation when things behaved strangely than anything else. I shudder at how long it took to give us .NET Framework source.
3: Some certainty that if you go bust or give up, I'm not out in the cold. If I have the source, and can build from it, I can maintain myself, or someone else could. Otherwise I am dependent on you continuing to support it and your financial viability. In that case even buying IBM might not be the right choice.
But if you can meet those some other way than OSS i.e. free for non-commerical, perhaps with shared source to customer, and some kind of escrow agreement, then that could be another way to go. I'm not going to reject Frans if he can meet my needs, even if his model for meeting them differs.
OSS is one way to solve a set of problems, its not the only way. It does seem to be a successful way.
As I keep saying it's all about diversity, about letting a thousand flowers bloom.
Most companies I worked with are very hesitant of open source projects because they assume there is a lack of support. Just read the NHibernate google group. A lot of problems are ignored or have a rude-ish replies like "don't expect me to waste my time unless you provide an SVN patch."
Even when there are companies that provide commercial support, it still usually is a not convincing argument because the company does not have nearly as much stake into the product vs. a company that built the product.
scooletz,
Huh! I know that bug, I explicitly designed RSB to avoid it :-) Of course, I did it by NOT supporting the notion of callbacks.
Regarding breaking changes, that really depends on the project and the project owner.
Faced with a patch for this, I would probably mark the current API as obsolete and create new one.
This is one case where I think that this is the right thing to do.
I think it's just because:
You get sourcecode contributors
You get people to know it fast.
--- When that people want to use it in a real commercial application, they have to pay for it!
That's why RavenDB is OSS and free for other OS projects, people get to know it fast, but they have to pay to use it in a real application!
Well, it is certainly MUCH harder if you DON'T have the code.
Over 90%, I would say.
Forking the project is something that you always have to do very carefully, but it is something that can happen. For that matter, I got clients who use me to create / maintain custom versions of NHibernate that are tailored for their specific needs.
I could continue, but I think that we arguing right past each other. I am not saying that all users will be able to do stuff with the codebase that would be meaningful or will be incorporated back to the codebase. I am saying that they _can_. And the fact that they can means that their is a much higher confidence in the project.
Dmitry,
You get what you pay for. If you want to get commercial level support, you should go for the commercial support option.
Like this one: http://nhprof.com/commercialsupport
If your car broke, would you try to fix it yourself or call a mechanic and pay them to fix it for you? Is software so much different?
If you're a woman, you'd buy a new car.
If you're a guy, you'd try to fix it yourself, then buy a new car.
From Joel's:
"There's another risk when you modify source code that you bought from a vendor: when the vendor upgrades the code, you are going to have a heck of a time migrating your changes to their new version."
This one is huge. Going back to some of the projects I was involved in a number of years ago. There was a Java team which selected a newer framework that made promises and had potential. This team fixed various bugs they encountered, and extended the framework to suit their needs. However, those changes didn't make it back into new versions so they pretty much locked themselves into a version of the tool.
That and breaking changes. I was quite "annoyed" when the team behind Moq decided to completely change the API between versions 2 & 3. It's not a mission-critical tool, but if something like that happens with NHibernate...
A few words, the way I see it,
baxevanis.typepad.com/.../...-source-software.html
Comment preview