Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Software

"Forking" Greatest Danger of Adopting Open Source? 471

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.
This discussion has been archived. No new comments can be posted.

"Forking" Greatest Danger of Adopting Open Source?

Comments Filter:
  • by aheath ( 628369 ) * <<ten.tsacmoc> <ta> <htaeh.mada>> on Tuesday December 09, 2003 @10:36AM (#7667985)
    Does anyone know the link to the article by Dr. Robert M. Sauer that is mentioned in the story?
    • by aheath ( 628369 ) *
      The article in question is Open question. The government claims open-source software means a 60% saving. It doesn't add up. [globes.co.il] Dr. Robert M. Sauer has a homepage [huji.ac.il] if you are interested in finding out more about his other work.
  • Religion (Score:5, Funny)

    by satyap ( 670137 ) on Tuesday December 09, 2003 @10:36AM (#7667989)
    If forking is acceptable in religion (notwithstanding "mine is the One True" etc.), it should be acceptable in software.
  • by Creepy Crawler ( 680178 ) on Tuesday December 09, 2003 @10:36AM (#7667992)
    The Sky is falling!!! Watch for falling Bits.

    Havent we had enough of this "dangers of open source" crap?
    • by jxs2151 ( 554138 ) on Tuesday December 09, 2003 @10:52AM (#7668156) Homepage
      ...Havent we had enough of this "dangers of open source" crap?

      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 [uchicago.edu] 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.

    • by azaris ( 699901 ) on Tuesday December 09, 2003 @10:54AM (#7668185) Journal

      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.

  • forking eh? (Score:4, Insightful)

    by alx512 ( 194670 ) on Tuesday December 09, 2003 @10:37AM (#7668001)
    And how many versions of windows are there?

  • by mekkab ( 133181 ) on Tuesday December 09, 2003 @10:38AM (#7668011) Homepage Journal
    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.

    • by interiot ( 50685 ) on Tuesday December 09, 2003 @10:54AM (#7668179) Homepage
      If splitting your resources is an obvious tactical mistake, then capitalism in general is doomed. We have, nay encourage, multiple companies who work independantly on the same problem (the more the duplication of effort, the better, so they tell me!). Not only that, but they're practically and legally encouraged and helped with government police/judiciary salaries to reduce the amount of cooperation beween them. Pure madness, I say.
  • by ericspinder ( 146776 ) on Tuesday December 09, 2003 @10:38AM (#7668014) Journal
    TCO; isn't that a microsoft generated excuse designed for inclusion in power point presentations.

    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).

    • by ccoder ( 468480 ) * <ccoder&shiznor,net> on Tuesday December 09, 2003 @10:45AM (#7668078)
      If you need it enough you can pay for it's development.

      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 :).

  • forking IS useful (Score:2, Insightful)

    by ccoder ( 468480 ) *
    I concur with the author's last sentence about forking sometimes being a blessing. Missing features, design work, and other features sometimes get left out of OpenSource projects because some developers just plain don't want to do the work. Another project may work out important issues (even if for only a few people!) and increase usability.

    Of course, I can see how more projects means less people to "help", but lets face it: the people that use 'forked' projects most likely (ok possibly..) picked that spec
  • by MarvinMouse ( 323641 ) * on Tuesday December 09, 2003 @10:40AM (#7668030) Homepage Journal
    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.
    • by pubjames ( 468013 ) on Tuesday December 09, 2003 @10:55AM (#7668188)
      Saying forking is a bad thing for open source is equivalent to saying random mutations are a bad thing for evolution..

      I would prefer this to be worded:

      Saying forking is a bad thing for open source is equivalent to saying speciation is a bad thing for evolution.

      Speciation occurs when two different groups of organisms evolve in response to different environmental pressures to the point that they can no longer interbreed. If speciation couldn't occur, life on earth would probably still be at the "grey blob" stage - a generic organism that can cope in a wide range of environments but is not really effective in any of them. Speciation - like forking - creates diversity and specialisation, which are good things.
    • by harrkev ( 623093 ) <<kfmsd> <at> <harrelsonfamily.org>> on Tuesday December 09, 2003 @10:56AM (#7668198) Homepage
      Forking MUST be bad. I am a hardware guy, but I hear the software guys talking about the "forking" software all the time, and from their tone of voice, it does not sound kind. They are always talking about the forking compiler, the forking debugger, etc.

      At least I think they are saying "forking."
    • 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...

      Is that an extremely subtle "*BSD is dying" troll hidden in there? :)

    • Exactly.

      Forking brings short-term problems, but is far better for everyone in the long-term. The fuss just seems to underline how business tends to think mostly in the short term, whereas open source hackers have a more responsible attitude!

    • On a more serous note...

      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.

      While you are correct that forking leads to evolution, it is not a perfect model. In OSS, frequently only one tyne of the fork survives very long. But when the features do start to diverge, each of the two p

    • Whatever is best for the end user will get used, and whatever is useless will die

      The only downside is that it sometime takes a long time for the inferior fork to die. If half your customers go with one fork, and half go with the other, you have to support both. Although it's hard to tell, since the article doesn't contain any links (WTF?!?), maybe this is what he is worried about.

      However, since forks are relatively rare, and forks of forks even rarer, and since most important software is standards bas

  • i think this is somehow part of human nature: in science (where i work) people tend to have collaborations until some a**hole comes along who does not believe in collaborating. the project splits and suddenly you have two papers about the same. if there was one paper in the first place, it would probably been a really good one, but now you have two mediocre works. if you now are a scientist in industry (which would correspond to something like microsoft) you better know how to work in a team or you are out.
  • by holygoat ( 564732 ) on Tuesday December 09, 2003 @10:41AM (#7668044)
    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.
    • Their own maintenance has rocketed the cost well beyond 60% of installed cost per year.

      This sounds like the result of the people making the decision not fully understanding the implications of forking, and how to manage that process intelligently. For example, if the team maintaining the fork tracked the mainline releases, the upgrade path would have been made much easier. That's assuming the code was open source in the first place; your post does not imply this. If the code was not open source, it wou
    • by Hell O'World ( 88678 ) on Tuesday December 09, 2003 @11:18AM (#7668401)
      You make an interesting point. For the most part I agree with the pro-open-source posters, that forking is like evolution, and it leads to better and better software. The problem, as you point out, is the burden on the individual companies who bear the cost. The Borg just keeps growing and getting stronger, while the individual suffers.

      But what you have to realize is that no matter what choice you make, whether you are going to use someone's software package or forge ahead on your own, the future costs can't be known in advance. You always have to make such decisions with incomplete information. And the costs of switching is always going to be high.

      Perhaps trying to save money on maintenace is not a strong enough reason to support your own software inhouse. But surely that bank got some competitive advantage, by getting exactly the software they needed? I work in the Health field, and my company was able to be flexible when Medicare buffeted us with huge changes, just because we had made the choice to take control of our own software. We grew while our competitor shrank.
    • It's a problem in the enterprise market, where custom software gets built, as well as in Open Source software.

      The problem in enterprise is actually bigger. Open source can actually help avoid the problem of "no upgrade path to the latest commercial version" which is VERY common when modifications are made to proprietary vertical market apps.

      With open source the changes can, and usually should, be given back to the main developers to be included in the main source tree. This usually allows the custom

    • by wiresquire ( 457486 ) on Tuesday December 09, 2003 @11:55AM (#7668768) Journal
      In that case, it's not called forking, it's called job security.
    • Several years ago I worked on a 1-million+ line ERP app which was maybe 20% customer-modded - i.e. very heavily.

      All mods, i.e. differences from the original, were carefully documented (in the form of extensive comments in the code, as well as keeping the original code in a canonical commented-out format inside the source - in a fashion that the original code could in principal be reproduced algorithmically with a program if desired; in fact this was tested for as part of the QA process).

      With the help of

  • by phoenix_orb ( 469019 ) on Tuesday December 09, 2003 @10:41AM (#7668045)
    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.

    • by Anonymous Coward
      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.
    • by Joseph Vigneau ( 514 ) on Tuesday December 09, 2003 @10:52AM (#7668161)

      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.


      Of course, this assumes those hours that were spent on GNOME would have been spent on KDE. This is simply not the case.
    • by jackb_guppy ( 204733 ) on Tuesday December 09, 2003 @10:53AM (#7668163)
      Now take look at Xwindows. There is no them and us so X is static - dead?

      Now look at Smoothwall GPL vs IPCop, one was fork from the other. Smoothwall yesterday annouced GPL 2 version. It includes many features that have been in IPCop for up to 2 years. Smoothwall went away from the GPL users years ago, now with IPCop showing that users want and need growth, they have moved the project agian. - Alive.

      It is the them and us that gives to growth. A single monolihtic project is dead, even if it does not know it.
    • by vidarh ( 309115 ) <vidar@hokstad.com> on Tuesday December 09, 2003 @10:56AM (#7668204) Homepage Journal
      You are making the flawed assumption that the amount of resources available to a "united" project would be the total of the resources available to each project. That's simply not true. Many projects are started as a response to perceived flaws in another project, and leads to resources being made available that wouldn't otherwise be there. Many of the Gnome developers would never have bothered working on a desktop project if it wasn't for the QT debacle, for instance.

      Many projects are also started because another, similar projects demonstrates that something is doable, or give people a chance to gain experience that they can build on in a fork that may have different goals.

      Yes, there is a lot of duplication, but this also means that the risks are lower - if a development strategy turns out to be a dead end, people will just move to another OSS project that didn't screw up, or fork, and you will still be able to leverage any good code in the failed project, and if you really need support or enhancements for the failed project because you can't migrate immediately, "anyone" can pick it up and support it for you (at a cost, but this opportunity wouldn't be there for a proprietary end-of-lifed product or a proprietary product from a bankrupt company)

      Contrast that with proprietary software, where you are entirely at the mercy of a company that may go out of business leaving you without support, which may end-of-life it's products at any time, which may refuse to fix problems you have, and where all the resources that went into the product have been wasted if the product disappears off the market.

      Forks means that you get an alternate product that starts of a possibly mature, well tested base, instead of the wastage of the proprietary world where most competing products have to be written from scratch. Look at the variety of vastly different Mozilla/Gecko based browsers for an example - writing a browser from scratch means spending huge amount of resources getting the basic rendering right. If this guy is against wasting resources by forking, does he also think that free market competition is a waste?

      Also forks in the open source world also often gets reintegrated. Look at EGCS vs. GCC for instance: GCC stagnated, got forked, got competition, and the end result was that GCC was revitalized and the projects merged again. This is again something that would be unlikely to happen with proprietary software, leading to more wasted resources.

    • That's not forking. (Score:4, Interesting)

      by 3Suns ( 250606 ) on Tuesday December 09, 2003 @11:19AM (#7668406) Homepage
      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.
  • This sounds like the typical excuses I hear from the Microsoft-brainwashed people that give presentations to the public-school Tech Coordinators in my area... "It's open-source...anyone can look and see your code!" "It's got a higher TCO!" "It's open-source! It might fork!" My response is the same as a previous poster...Windows forks every couple of years, so what's the problem?
  • 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
  • by Anonymous Coward on Tuesday December 09, 2003 @10:44AM (#7668070)
    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.
  • by liquidpele ( 663430 ) on Tuesday December 09, 2003 @10:44AM (#7668073) Journal

    This is just dumb. If there are different forks, it does not matter. A company will pick one that does what they require and they provides good support from an organization they trust.

    I can understand why a company would be turned off by a software project that forks, then the original dies off, then the fork forks and dies off, etc. But it seems to me that that software must have not been well thought out, or they owners have issues, so in this respect it seems good to stay away from it. If the original and first fork stick around and imporve too, then what is the big deal? Use it, get support, and be happy! If you don't trust it, then don't use the damned thing. Different versions won't make people not trust something. Poor support from shakey companies does.
  • by DrHyde ( 134602 )
    I used to be scared that the open source software I used would fork, but it hasn't happened to Linux, nor to perl, nor to apache, nor to exim, nor to any of the other tools I use day in and day out. The only forks I've seen in major projects have been when a new version has been released but the old version has continued to have occasional maintenance patches released. And that, if anything, is *better* than what you get with commercial software.

    I suppose OpenBSD could be considered a fork, but the effe

  • by tacokill ( 531275 ) on Tuesday December 09, 2003 @10:47AM (#7668101)
    If OSS is going to be successful over the long run, remember that the market responds to what IT wants -- not what the OSS community wants.

    The only reason I say this is because most of the replies seem to go something like this, "yes, but forking is good for software". Well, it may be good for the people producing the software but it really sucks for customers.

  • by Dr. Photo ( 640363 ) on Tuesday December 09, 2003 @10:47AM (#7668105) Journal
    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.
  • Unhappy with the focus of the GUI, Mozilla Firebird and later Mozilla Thunderbird forked from Seamonkey. These have been very successful. Unfortunately, many Seamonkey developers were unhappy about the way it was done and some may refuse to contribute to the *bird projects out of spite. All of these projects are under the domain of the Mozilla Foundation, but the roadmap has not been updated in quite a while.
  • by Noryungi ( 70322 ) on Tuesday December 09, 2003 @10:49AM (#7668120) Homepage Journal
    Which is that both sides of a "fork" actually adopt the best practices and best code/functionalities of each other.

    Imagine there are two projects: "A" and its fork "B". If "B" programmers are smart, they'll keep on tracking the changes brought to "A" and incorporate the best features and patches from the original project.

    In the same way, "A" programmers will keep an eye on "B" and take the code they need to improve "A".

    And there are many examples of this in the open-source world: NetBSD and OpenBSD, Emacs and XEmacs, etc...

    Forking does not necessarily means a loss of quality or incompatible programs. In the worst possible case, if one side of the fork is clearly better, it will eventually replace the other.
  • ... because it forces them to make a decision that can only be rationally made on technical grounds (which fork is best for our needs, is the cost of supporting multiple forks worth it, etc.).

    PHBs fear decisions like this, because they either have to defer to their better-qualified underlings to decide, or take a guess and risk looking stupid afterwards.
  • I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger.

    Two statements, both of which I would agree with, but one thought that occurred to be is how often does one lead to the other? When a project gets forked, you usually get rapid development on two seperate areas, as rivalry (friendly or otherwise) tends to add impetus to both teams, which is great for developers and users alike.

    But how often do projects get forked, with both forks initiall

  • Evidence? (Score:3, Interesting)

    by Bilbo ( 7015 ) on Tuesday December 09, 2003 @10:51AM (#7668150) Homepage
    I don't see a link to the actual article, but I wonder if the author has any real evidence of this forking, or is he simply working from arm-chair philosophies? Sure, it's possible in theory, but where are the examples? In the case of a fork, does one side quickly die off, and the other branch simply re-absorb the developers? Is forking no more than evolution at work, with the strongest (i.e., the strategy most supported by users) ultimately surviving in the end? Is the proprietary model an example of one person's vision of how a project should work being forced on users? (examples: horrendous implementations like "Bob" and "Clippy"?) Is the proprietary approach an example of the useless features and software bloat caused by isolated software developers, dwelling in their ivory towers, huddled around clueless "focus groups"?

    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.

  • by linuxislandsucks ( 461335 ) on Tuesday December 09, 2003 @10:52AM (#7668155) Homepage Journal
    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!

  • Two simple rules (Score:5, Insightful)

    by FearUncertaintyDoubt ( 578295 ) on Tuesday December 09, 2003 @10:56AM (#7668200)
    Closed-source: it's about money
    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.

  • by Rahga ( 13479 ) on Tuesday December 09, 2003 @10:57AM (#7668215) Homepage Journal
    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.
  • by cabalamat2 ( 227849 ) on Tuesday December 09, 2003 @10:58AM (#7668220) Homepage Journal

    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.

    • by 0x0d0a ( 568518 ) on Tuesday December 09, 2003 @11:18AM (#7668403) Journal
      If Sauer ignores the TCNO, he is either stupid, or a Microsoft shill.

      Neither.

      His paper probably would have been ignored, except for the fact that Slashdot posted it.

      Every day in every field where it's hard to conclusively show that someone's theories are wrong immediately (public policy, economics, etc), there are a lot of papers produced arguing new points that are a bit dubious. If someone can get attention from putting out a new idea, they can move up the academic/corporate ladder.

      You shouldn't be pissed off at this professor. Instead, you should be happy that open source is such a facinating new area of economics that professors are now publishing lots of papers on it to try to explain it an analyze it. Will there be ones that explore what people consider to be the negative sides of open source? Sure.
  • ... he sounds as though a fork would somehow cripple him, leave him powerless. With access to the sourcecode, and a couple hundred bucks or a geeky nephew who likes him, the software is his to modify / improve to his hearts content. He sounds as though he's still reliant on the companies to fix things for him, which he's NOT. True, if there's a fork, the less popular one is in danger of dying (Darwin strikes again), but if there are people willing to prop up a dying fork, it can stay alive for a long time.
  • by mr_lithic ( 563105 ) on Tuesday December 09, 2003 @11:00AM (#7668235) Homepage Journal
    I would assume that forking is the result of software filling specialty niches. No software project can produce an application that can or will do everything and eventually it will fork to allow it to adapt to the needs of the users. This is similar to the evolutionary mechanism of punctuated equilibrium.

    VNC is an excellent example of this. The ancestral WinVNC has forked into a variety of specialty projects which each do their own area best. UltraVNC is a very good full feature app, while TightVNC handles thin clients superbly.

    This does not endanger the VNC project, rather it strengthens it by providing a larger group of usres and contributors that may not have been interested in the software until the variation had appeared.

    As long as the unwritten rules of forking are adhered to (as stated by Eric Raymond) and it occurs to satisfy project needs and not individual's egos then I would see it as a positive occurrence.

  • BS (Score:3, Insightful)

    by hackstraw ( 262471 ) * on Tuesday December 09, 2003 @11:01AM (#7668245)
    ...has written a article saying that the hidden costs of OS add up to a higher TCO

    OK, 1st I have never seen a valid way of _measuring_ TCO and this guy can measure "hidden costs" in TCO. So are these "hidden" costs things like security breaches, viri, worms, buggy software, new bugs introduced by a patch/upgrade, etc? And these things can be preemptively quantified in terms of $$ ?? !! Amazing.

    Now with the forking problem. Well, its a part of life. Churches do it, companies do it, religions do it, nations do it. I have never been negatively affected by a forked opensource project. The biggest fork of a project I can think of was when gcc was forked into egcs, which was eventually unforked back into gcc. I'd take the gcc we have today over the one years ago anytime. Even with the gcc/egcs fork there was no problems any different from an upgrade from any complex computer program.

    And in closed source, this keeps "forks" from happening? Closed source companies go out of business, their programers go to other companies, etc. Although code rarely gets transfered when these things happen, other closed source projects spring up to compete or fill some void for people. That is similar to a fork except its more like a rewrite.

    Back to work. I've got to unhide some hidden costs to lower the TCO for my PHB ASAP.
  • The problem with forking is that the more projects that get forked, the more abandoned projects we have. If everyone's effort is on one project, then the liklihood of that project losing all developers is slim compared to if you had several forked projects all competing for the resources of the developers.

  • Misconceptions... (Score:3, Interesting)

    by mindstrm ( 20013 ) on Tuesday December 09, 2003 @11:02AM (#7668250)
    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.

  • If you say that programming is the stepped solution to a problem, you could envisage it as a climb up a fitness landscape, with the goal of the program being the ultimate summit.

    Fitness algorithms (people, in this case) mainly take small steps in the direction "most promising", but can easily be trapped into local maxima (in other words, the route that initially looks the best solution ends up with a non-optimal solution). A code-fork is the method OS uses to make a longj(u)mp (pun intended :-) onto a diff
  • yawn (Score:2, Insightful)

    by twitter ( 104583 )
    Department of Economics

    Yeah, yeah, another MBA pusher adicted to power point and other M$ junk that thinks he knows something. I can't stand these idiots. They never personally demand more of computers than cutsey clip art and tiny access databases that they don't know how to organize and never use, but they think they know how to run an IT department.

    This particular one is just echoing the usual set of M$ bullshit. Only Microsoft could continue to blither on about some myserious Total Cost of Ownershi

  • by BillsPetMonkey ( 654200 ) on Tuesday December 09, 2003 @11:11AM (#7668325)
    Dr. Robert M. Sauer of the Department of Economics at Hebrew University of Jerusalem, and president of the Jerusalem Institute for Market Studies

    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. ... we interrupt this broadcast ... to get a comment on the NASA programme from Dr. Hibbert of the Chicago Institute of Modern Art ...
  • by BigTom ( 38321 ) on Tuesday December 09, 2003 @11:11AM (#7668327) Homepage

    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.

  • by Walkiry ( 698192 ) on Tuesday December 09, 2003 @11:11AM (#7668328) Homepage
    OSS forks.
    Windows borks.
    Apple is for dorks.

    Now choose!
    (Wonder if I'll be modded down by mac users with no sense of humor...)
  • by olethrosdc ( 584207 ) on Tuesday December 09, 2003 @11:14AM (#7668350) Homepage Journal
    Or what have they ever had known about any kind of technology? I know around half a dozen people that are economists, one of them a uni professor, and none of them exhibit any understanding of technology. Here is my question to the prof:

    If it costs X to produce the main branch of the code, how much does it cost to fork it N times? The upper limit would be NX, but actually it should be much less. Furthermore, what is the utility of the main branch? It is true that the utility of the main branch, or any fork, might be the same for just *one* customer, but what when there are many customers which want different things?

    Furthermore, what about closed source software? With closed-source, each client will have a completely customised version of the software. If one of the forks for one client gets a fix/upgrade, the fork for another client will not necessarily get it. Plus, it is much harder for to migrate. (If something is open-source, it would be easy to write a migration application).
  • Monopolists (Score:3, Insightful)

    by LuYu ( 519260 ) on Tuesday December 09, 2003 @11:17AM (#7668391) Homepage Journal

    Claiming that forking is bad for Free Software is the same thing as saying that competition is bad for capitalism.

    Then again, I suppose monopolists like MicroSuck think that competition is a bad thing to have in the market place. It reduces their control over the consumer.

  • by salesgeek ( 263995 ) on Tuesday December 09, 2003 @11:30AM (#7668531) Homepage
    I'm really, really sick of seeing people act as if Open Source (TM) is some kind of software development corporation. It is not, it is a process. The assertion that a private interest developing software is somehow guided by the market whereas OS development is flawed:

    * Open Source is guided by it's market of user-developers. This is the opposite of the author's assertion: reality is that closed source software is insulated from market demands - how many years has it been since MS Word's index feature was broke? How many years will it be till they fix it?

    * Forking is where generally needs diverge and the user-developer creates a product more close to their need. In conventional private development, this rarely happens unless a market is large enough of a cusomter's need is enough to fund development. That open source products fork to smaller markets is a strength of the model - people can spend less to get exactly what they want.

    * What the author is trying to express is that open source products more quickly diversify - in fact it's possible in the open source world for a product to spin in to thousands of uniqe forks where each fork may have as few as one user!

    What the author is missing is that Open Source allows for the market to take control of a product - whereas we are used to the model where the product is insulated from the market by the company that makes it.
  • by supermojoman ( 699985 ) on Tuesday December 09, 2003 @11:35AM (#7668576)
    Seems like this is a risk - a calculated risk - that everyone incharge of some IT decision takes and has taken for years now. We see it happen with certain standards all the time. A few solutions rise to meet a certain problem. Some succeed, some don't. That's why careful evaluation of adopting anything is necessary. You don't want to go one way while everyone else is going another.

    NIST does this sort of evaluation on standards all the time with its Application Portability Profile [nist.gov].

    Basically, I don't see how this "forking" is really something exclusive to open source. Society, as a whole, forks all the time. Which forks will be successful isn't without some level of predictability, however.
  • by aphor ( 99965 ) on Tuesday December 09, 2003 @11:39AM (#7668616) Journal

    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."

  • Ob Python quote (Score:3, Insightful)

    by BenjyD ( 316700 ) on Tuesday December 09, 2003 @11:40AM (#7668629)
    The answer to project splits is simple - make all OS developers watch the Life of Brian. It's impossible to take intra-group political fights seriously after that.

    "Judean People's Front? F*** off, we're the People's Front of Judea."
    "Whatever happened to the Judean People's Front, anyway?"
    "He's over there"
    "Splitter!"
  • by sribe ( 304414 ) on Tuesday December 09, 2003 @11:59AM (#7668817)
    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.
  • by happystink ( 204158 ) on Tuesday December 09, 2003 @12:46PM (#7669333)
    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!
  • by Angst Badger ( 8636 ) on Tuesday December 09, 2003 @12:59PM (#7669474)
    I can count the number of significant projects that have forked on one hand and still have a finger free for Darl McBride. Sure, forking happens all of the damn time with silly stuff like MP3 players and web-based BBS software, but aside from the BSDs, when was the last time you heard of a significant infrastructure project forking?

    Only the gcc/egcs split comes to mind, but the two were folded back into one tree and the result was a better compiler. There's the StarOffice/OpenOffice split, but that's also largely collaborative. Most other forks are dead ends that wither away quietly, no matter how loud and vociferous the original argument was.

    This is just more Microsoft FUD coming from one of the most Microsoft-saturated countries on the planet.
  • Umm (Score:3, Interesting)

    by anthony_dipierro ( 543308 ) on Tuesday December 09, 2003 @12:59PM (#7669475) Journal

    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.

Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie

Working...