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.
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
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
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?!