"Forking" Greatest Danger of Adopting Open Source?
TTL0 writes "In response to recent descisions in favour of Open Source in Israel (see here
and here),Dr. Robert M. Sauer of the Department of Economics at Hebrew University of Jerusalem, and president of the Jerusalem Institute for Market Studies. has written a article saying that the hidden costs of OS add up to a higher TCO. However, The greater danger Sauer writes, is that of a OS project forking. "The forking of open-source projects occurs when passionate disputes between open-source software developers over product design lead to the splintering of projects into a multitude of varieties. With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces."" I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger.
If forking is acceptable in religion (notwithstanding "mine is the One True" etc.), it should be acceptable in software.
I understand that from a purely tactical point of view, splitting your resources is very dangerous when they are thin to begin with.
However, open source isn't about tactics; its power comes from zealotry. And there is nothing that fires a persons mind up more than a little competition. There are plenty of anecdotes of people being told "You can't do this." and then rising to the occaision just to prove them wrong.
In the future, I would want to not be isolated from my friends in the Space Station.
One of the nice things about open source is that if the project forks, you can "fork" it right back, you are not at the mercy of your software suppliers. If you need it enough you can pay for it's development. This is also true if the project is otherwise abandoned, with paid-for software you would need to be the highest bidder at the auction (or at the mercy of some gready and broke VC).
The grass is only greener, if you don't take care of your own lawn.
Saying forking is a bad thing for open source is equivalent to saying random mutations are a bad thing for evolution. Forking causes essentially evolution in an otherwise non evolutionary area of development.
Sure, lots of work is wasted by forks that no one but a select few use, but the real thing is that forks that no one uses will die off, forks that people use become better, but only when these projects fork and these radical concepts get implemented can the software evolve.
You see, by forking from where you left off before, the end users have the option to use the original fork, or use the new "mutation" of the software. Thus, allowing for a form of evolution. Whatever is best for the end user will get used, and whatever is useless will die. Sure sometimes good things die by "accident", but that as well is true of the natural world. Unlike corporate development "vats", where the code has to be one fork only, and the company decides which "fork" and which "changes" are best. Open source allows the end user to decide which things are most important, and thus is far far far more useful for consumers, and individuals than corporate devlopment is.
~ kjrose
My PhD supervisor once worked at Schroders Bank. They didn't want to pay 20% of installed cost per year for an information system, so they decided to maintain it themselves.
Bad idea.
Cut to a few years later. Their own maintenance has rocketed the cost well beyond 60% of installed cost per year.
Even worse, the forking has meant that there is no upgrade path to the latest commercial version, causing the system to be an absolute millstone - and no way out.
It's a problem in the enterprise market, where custom software gets built, as well as in Open Source software.
Forking can be detrimental to a project. Why, just because some jokers forked the tree, chimpanzees have failed to take over the world.
What's more, so much redundant effort is going to the forked project. P. Troglodytes and H. Sapiens share over 97% common code base, and yet the splitters couldn't be bothered to add a few new features to the chimp. Nooooo, they just had to start their own little project instead of working with the existing code base. If this trend keeps up, open source is doomed.
Havent we had enough of this "dangers of open source" crap?
Hear hear. Now let's get back to the objective "open-source perl-hack saves world"-reporting.
Is Sauer misguided, or is he in the pay of Microsoft?
Forking is rarely a problem for open source projects; when it does happen, it generally reflects unresolvable differences about where the project is going; which is fine, since two groups may legitimately want to do different things with it. Indeed, forking is good, because the threat to fork keeps open source honest.
If Sauer is concerned about the TCO, that's a valid concern. But a much more valid concern, which Sauer seems to ignore (I've not read his article yet) is the Total Cost of Non-Ownership: when you use Microsoft software, you never own it, and the future of the software is controlled by Microsoft, not you. Hence upgrade treadmills, deliberastely incompatible file formats, and the like. It's because one doesn't have the right to fork MS software that MS can get away with doing this. If Sauer ignores the TCNO, he is either stupid, or a Microsoft shill.
No, not because open source is perfect, but because the guy is plainly an idiot who doesn't know what he is talking about, Dr. or no Dr. Forking is extremely healthy -- look, for example, at the Apache project. Apache is in a continous state of forking, with bits falling off and bits being tacked on all the time. For example, IBM will take a specific version of Apache, create a fork, put it in Websphere, and after some time, trickle some changes back to the Apache project.
Clearly, Apache is a massive example of a successful Open Source project.
As the other poster rightly asked: "how much did he get paid by MS?"
People who think they know everything are a great annoyance to those of us who do.
With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces.
Uhm, yeah, but what he fails to mention is that "disciplined by market forces" often means "going out of business and leaving customers with no recourse except an extremely painful and expensive migration". The closed-source proponents that I've seen never factor the cost of being stranded like that into the TCO, yet we know that outside of operating systems (because MS is pretty healthy and is very likely to be around another 10 years) this happens all the time.
First of all, forking has nothing to do with projects being abandoned. Forking is the opposite of abandonment. It is the equivalent of a cell division. Where you had one cell, now you have two. This reduces the possibility of abandonment as there are two projects that have to be abandoned where there was formerly only one.
Secondly, and even more importantly, with Open Source or Free Software, if a project is abandoned, you still have the source code. If you still need the project's functionality, you can maintain the code. Projects can only be abandoned if you and everybody else abandones the project (i.e. if nobody wants it). Therefore, "abandonment" is not really abandonment in Free Software.
This stands in large contrast to closed source software. If Microsoft decides to kill a project, you are SOL. You do not have access to the source code, and even if you did, you would lack the right to modify it or even use it. In fact, MS can even revoke your right to use code that they have already distributed and that you have already paid for if they decide to.
Open Source or Free Software protect you from being locked out. You can use Free Software forever. Long after there is no market for a particular application, you can still have it for your purposes and customize it to your preferences.
Free Software is synonymous with free choice and customization. Free Software is software individualism.
All data is speech. All speech is Free.