Slashdot Mirror
"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.
And how many versions of windows are there?
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.
Look at Gnome and KDE. Both great windowing managers. Both took great amounts of time and effort to make.
Yet for joe-six-pack-end-user (which everyone here on slashdot eventually wants as linux users, right?) , there isn't "multiple window managers", there is the start menu, and he doesn't really care whether it is a "K" or a "foot" down in the lower left hand corner.
The article basically is correct in stating that passionate dissagreements fork projects. The doubling up of energies on very similar projects (like Gnome and KDE) work against open source.
Why?
Because all of the man hours spent building up Gnome were spent on KDE (or K-Office, Konquerer, etc), the code would be much tighter, with greater functionality.
What isn't stated in the article is that there aren't that many human interface experts working in open source. Most interfaces are done either by programmers themselves, or graphic designers who have no idea how most users navigate through systems. What good open source projects need is human interface experts who are willing to lend their knowledge to make a easier navagatable program.
Blah Blah Blah.
I think the professor doesn't understand how Open Source really works. I've rarely seen forks in Open Source projects and more often than not, a new idea is tested out in a branch at first. Once the idea has gone through sufficient testing and validation from real-world use, it gets adopted by the main tree. Without the ability to fork, branch and vary, the speed at which new ideas are tested and weeded out is significantly slower. The primary difference in my mind between Open and closed development is open source allows unpopular ideas to prove itself. Whereas in a corporate environment, unpopular ideas get killed very early in the dev cycle. Perhaps the professor needs to learn how real software development happens in real life.
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.
how aobut some factual proof to back up this bad biased peice of crap!?
Lets see as a startup I have saved $250,000 in software infrastructure costs using
BLender3D
Gimp
CinePaint
Eclipse
Now where in fucking hell does my using Opensource increases costs such as hidden costs? show me or shut f*cking up already..
Its because I use opensource that I can compete with those outside the us who are using closed source software infrastructures, well duh!
Don't Tread on OpenSource
Absolutely not! Only through open and honest (painful) discussion of the merits and weaknesses of anything can it be strengthened. If it was too weak in the first place, it will not stand up to the scrutiny- otherwise it will be strengthened.
Take some time to read this paper for enlightenment on why open discussion by people with differing viewpoints is a good thing.
Funny thing is that closed source people don't want discussion of their warts...I would think OS would be different.
It's a dodgy analogy.. but what the hell:
Like the a**hole Galileo who wanted to go his way and say that the earth went round the sun, instead of helping fix the bugs in the current theory...
Btw, have a look at: this
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.
Open-source: it's about ego
Companies are often concerned about the long-term market viability of software they purchase. If the company won't be around in a few years, or the software may be abandoned, it is seen as a risk.
In the case of proprietary software, the question boils down to money: will this software be profitable enough that the publisher will continue to develop and support it?
In the case of open-source, the assessment is similar, but the motive is different: do the developers of this software seem committed to its long-term health? It may appear harder to answer that one, because you don't have numbers that management can put in an excel spreadsheet to prove it. Not that those numbers, when applied to predicting the future proprietary software, would be much better, but they give the illusion of hard facts.
Either way (open or closed-source), the risk is the same: will this software suddenly be abandoned, or changed in a way that makes it unsuitable? It's just a question of what the chances are of that happening, and the scenario that would cause it.
If you are worried the most about forking, then you probably read much more open-source heavy press (Slashdot) that key the communities in to every newsworthy development in the hopes of expanding user and developer bases. On the other hand. To quote:
"With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces."
The main problem with that statement is the use of both "disciplined" and "market forces". If a proprietary tool is extremely useful to you and few others, you can almost count on it getting discontinued after a year or two of stalled sales. If a tool can work wonders for many people, but is insanely hard to market, it will get split into a family of product each geared to a specific market. Those forks make open source forks look like small splinters or development experiments.
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.
Dr. Robert M. Sauer of the Department of Economics at Hebrew University of Jerusalem, and president of the Jerusalem Institute for Market Studies
... we interrupt this broadcast ... to get a comment on the NASA programme from Dr. Hibbert of the Chicago Institute of Modern Art ...
Why is the media always taken in with the idea of the "all-purpose expert"? This guy has a PhD in economics, not software design or management. There is nothing to suggest he knows what he's talking about when it comes to software.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
If you use proprietary software the danger is that it gets discontinued.
Then you are stuck with an unsupported legacy system that you can't support at all
Competition in the proprietary market means that you have to bet on a product and if the provider goes under you (at best) get left with a load of crappy, undocumented escrowed code that often won't even build.
Alternatively you buy a product and the provider "discontinues support" so that you get hung up for a big upgrade (usually with a shed load of license costs to go with it).
For equivalently functional products (for my project's needs) I'll take OSS as a risk mitigation measure every time.
Certainly, it worked well for Apache, but I don't know if that's the kind of fork he's talking about - that's more like a "development version" kind of fork. And, as you say, there's a good kind of flow between the two projects, where one is clearly the "Main Version" so there's no diluting of third-party support, etc.
Not so fun would be the "antagonistic" kind of fork. Here, there can be no flow between the two projects, practically. Additionally, the leaders of the two projects may rather kill the project entirely than adopt features from each other. It also may not be clear which is the "Main Version," diluting third-party support, and if it's a roughly equal split, the future direction of either fork may not resemble the previous project that much. It also may dilute the talent pool, since the manpower is split.
All in all, I think it depends what kind of fork takes place, and under what terms. However, I like all of you would have liked to have seen this nebulous "article" alluded to. Hey Taco, how about not posting stories where some asshat claims to have an unposted, mystery "article."
-Looking for a job as a materials chemist or multivariat
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.
how could we sensibly comment on it if we had RTFAed?
I think the danger that thr Dr. refers to is pretty guessable and might not require the article. The danger is not the forking, per se, but the diversion of talent that occurs. In a centralized undemocratic closed system, there are fixed goals at a certain point. As it progresses, due to constraints (human, time, budget, technical..etc), compromises have to be reached. Not everyone will agree with those compromises, but professional discipline dictates that they remain focused and continue. In a GPLed project, if a segment of your talent pool has different ideas about the end goals, they might fork in the middle and deprive your original project of their talent, fragmenting the development effort. You might not necessarily regain an equivalent pool of talent towards your project even if it can be proven to someone interested that your goals are better/more feasible..etc. There is no fiat by which to impose discipline in an open system.
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.
Stop the Slashdot effect! Don't read the articles!
Forking is part of everything I hate about open source. I hate the forking bugs, I hate the forking users, I hate the forking beards, I hate the whole forking thing!
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.