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.
Does anyone know the link to the article by Dr. Robert M. Sauer that is mentioned in the story?
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.
How is the risk of project forking greater than the risk of product obsolesence through buyout? Ask all those folks who've had a software vendor bought out, only to be forced into a 'new' of 'better' product.
-chris
I agree. My company uses that approach with alot of things such as our customized mail servers, DNS scripts, etc. We take Bind, and add features (sure most are in shell scripts, but still..). We take Courier, and fix problems with certain domain names (mostly irrelevant to the world).
That's what I like about my job, being a evolutionist for hire, so to speak :).
"During times of universal deceit, telling the truth becomes a revolutionary act" -- George Orwell
1) Would everyone have to learn C++?
2) Would QT still be GPL?
3) Would KDE hackers
a) work as hard without the competition?
b) be as open without a rival?
Much as I love KDE (and use it) I don't think it would be anywhere near as good (or free) without the constant threat of Gnome in the rear view mirror.
Sure, it's all well and good for a bunch of "researchers" to sit around and pontificate on the "Dangers" of one development approach or another, but until I see some hard numbers and indications of actual long term effects, I'm not impressed.
Your Servant, B. Baggins
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Everyone remember... if you aren't used to the open source world.. there are some things you take for granted that need to be re-assessed when you go to open source.
Things like : forking.. when you see a project, and it forks.. you think of a company that just split in two, having developers leave, internal strife etc.... it will probably hurt the customer. Not necessarily so with open source.. the fork could be simply becaues a couple recent developers wanted to take things in a new direction. You don't lose, everyone wins.
Version numbers: Commercial ventures use versioning as a marketing tool.. but with many OSS projects, it's just a developer tool. Just because something is 0.xx or 1.xxBETA doesn't mean you can assume anything at all about it's stability or features, or worthiness. Sometimes it's 0.xxBETA simply because the developer always had one feature he wanted to add, and never got around to.. it could be rock-solid. The old adage about "never use a 1.0 release in production" comes about because commercial developers usually call their first release 1.0.. and the first commercial release is usually buggy as hell, as it came out early due to marketing pressure... and it's the first time it's hit a wide audience.
Support: One of those things that means differnet things to different people. Remember, many non-oss people just want individual applications, and somewhere to go for concise info about those applications.. they don't really picture everything as a big pile of tinkertoys to glue together like with unix/oss. In 10 years of OSS, I've never had problems finding answers to my questions.
GPL fud: Seriously, the zealotry about hte GPL has got to stop... everyone should read it and question their assumptions about it. A great many people still think that anything you write for Linux has to be GPL, and that you can''t practically write closed software for linux. They think the compiler requires you to publish your source, etc. I know it's obiviously not that way, but to many , it's not.
Dictators: People see one guy in charge of a project, Linus being a common example. They say "who's to say linus is going to do what business needs?". Well, true. Nobody can guarantee that. But for a decade he's done a good job.. and what they need to realize is that the projects are driven by those who contribute to them. The reason it's popular, and that you hear about it, is because it's good. These leaders aren't dictators... people follow them because they are doing a good job. If Linus went insane and started doing weird stuff, you can bet there would be a new leader or group emerge.
When I was working for a major global firm, and we dealt with small closed source development companies, we always had code escrow agreements. If the vendor went out of business or dropped support of the product, we had the ability to get the source and support it ourselves.
I can tell that you're trying to make a valid point, even if it's one that's been tried many times before. It's a misguided point, of course... would software be so much better if the industry didn't have so much duplicated effort and everyone went to work at Microsoft? I hardly think so. Besides, Gnome developers usually become that way because they can't stand the thought of coding for KDE, and vice versa.
However, Gnome and KDE are most certainly not an example of forking. They grew up entirely on their own, and there was never a common parent. Forking means taking one project and making new projects from it, starting at a branch point. Examples: Emacs and XEmacs, XFree86 and Xouvert, Sodipodi and Inkscape, RedHat and Mandrake, Debian and UserLinux (in the future), Net/Open/Free BSD's.
Sometimes forking can hurt a project, but often times it encourages innovative work in a different direction. Usually, however, it signifies a problem in the management of the project; if a developer is frustrated by the project leadership, they might fork the project rather than struggle to get their viewpoint heard on the main project. One of the testaments to the managerial skills of Linus Torvalds and his lieutenants is the fact that the Linux kernel has not undergone major forking. Kernel developers in general feel that they can get their work done adequately on the main Linux branch.
-3Suns
~~~~
The Revolution will be Slashdotted
Note that the Halloweed docs were a "secret" set of memos prepared by a top MS employee for Microsoft top management when they were developing their strategy against Linux. So it is certainly not biased in favor of open source!
Therefore, I think that the assertion that code forking is a "danger" which cannot be mitigated is wrongheaded. Rather, forking can be a problem, but can be managed by adjustment of the licensing agreement for the software.
I think you're right in saying capitalism is doomed and you're right about what will cause it's doom. Only a bit more is needed to trigger it's fall: robots. Read this story if you're interested in such things; it gives a good indication of what will happen once robots become good enough to replace most jobs (which imho is inevitable) and describes a few scenarios which we might expect. The conclusion is: capitalism is doomed but it might take a few decades.
0x or or snor perron?!
What other possible reason is there for wanting open source and a free software license but for the right to fork? If you edit one single file and recompile, that binary and the file you edited are a fork in the development. This is what programmers do when they share. They fork off of each others' work, and then *gasp* they merge their respective forks!
There can be no merge without a respective fork. Forking is essential. It is the meaning of life. Fork fork fork. Merge merge merge. Fork; merge: because you can. When people ask "What is Open Source?" you should say "Promiscuous forking and merging of everyone's ideas and code."
Now, the danger to a business in Open Source: they might think it is a free lunch. TANSTAAFL. Everything you have also has you, and if you think you don't have to pay there will be surprise costs. It's either blood and sweat or enough money to get someone else to throw in sufficient blood and sweat. When you adopt free software, you either fork and freeze, or you commit to keeping up with development. This is the same as commercial software patch management. The prior developers are writing code for purposes outside the scope of your business mission. You can't "squeeze" the vendor in free software, but you can hire programmers to make your own fork. There you either commit to merging your changes back into the project, or you commit to maintaining your own fork. As long as you understand those costs and you compare them to migration from one piece of software to another, you just have more choices than closed proprietary software.
More choices is a problem for the business world. The suits are struggling to maintain business competence in an increasingly technological. More choices requiring more technical engineering perspective mean more challenges to the established order of wink-and-handshake discretion in business decisions. More power is unwelcome responsibility without the skills to master the empowered situations and their choices. Part of the problem is the suits' idea that mistakes are unacceptable. The real issue is why the suits are so afraid that they are choosing between "the devil you know and the devil you don't know."
--- Nothing clever here: move along now...
Very true. Thats why I said "Corporate software" as opposed to "closed source". There are some open source projects that are being financed by corporations. A more appropriate title for the article would be ["Forking" Greatest Danger of Adopting Distributed Development?] Distributed development also has some advantages that compensate for this drawback that outweights the risks in my opinion. But I mostly agree with writer on this item.
The price of freedom is eternal vigilance.
Basically you are decribing Open Source. It's religion, not software development. And that is why it will never be anything without someone like SUN putting the project into glue. We should all be kissing Sun's ass because THEY are the ones that will kick M$ off their dias, not WHINERS like RMS and half or two thirds the jackasses who babble on here.
My Karma is bad. May I take you out for a drink? It's on me...
>we dealt with small closed source development companies, we always had code escrow agreements. If the vendor went out of business or dropped support of the product, we had the ability to get the source and support it ourselves.
Have you've ever had to do this?
Small company + out of business = "Here is the code we scraped together, no one left knows how it works or even if its all there. Good Luck and Good Bye!"
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces.
Sure, forking doesn't take place, because of copyright issues. Instead you have two different companies working on the exact same thing from scratch. Yahoo Messenger, AIM, MSN Messenger, all worked on separately without any collaboration whatsoever, and completely incompatible with one another. Forking is better than the alternative.