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

Comments

Link to the Article by Dr. Robert M. Sauer?

[aheath]

Does anyone know the link to the article by Dr. Robert M. Sauer that is mentioned in the story?

Re:Link to the Article by Dr. Robert M. Sauer?

[ankit]

No, open source is not perfect. But forking is one of the reasons why I use open source! Its all about choice.

Re:Link to the Article by Dr. Robert M. Sauer?

[passthecrackpipe]

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

Re:Link to the Article by Dr. Robert M. Sauer?

[diersing]

I prefer forking, my wife on the other hand would rather spoon.

Forking does provide choice, but too many splits can lead to too many dilluted or feature-less versions versus a relatively singular tree which would include features from all contributors.

Re:Link to the Article by Dr. Robert M. Sauer?

[Gyan]

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.

Re:Link to the Article by Dr. Robert M. Sauer?

[Anonymous Coward]

Unfortunately, the singular tree you mention often will contain only a limited set of those extra features that might be developed with forking. I personally believe that forking allows a much greater choice of features that then can battle it out (in a Darwinian sense) to see which are worthy of pursuit and, perhaps, merger back into the main branch.

Now, how does this translate into a danger for poeple using OSS? Why, by providing more choice! Is his whole argument the same old saw that customers don't want choice? That, no matter how bad the single implementation may be, it is better to use a bad choice than having to pick among many choices that may be more suitable?

Re:Link to the Article by Dr. Robert M. Sauer?

[Geek of Tech]

Forking is like software evolution. One project may split into two, with slightly different plans. Mostlikely one will surpass the other. Kind of survival of the fittest. If neither one grows over the other, then you have something called choice.

Religion

[satyap]

If forking is acceptable in religion (notwithstanding "mine is the One True" etc.), it should be acceptable in software.

Re:Religion

[quandrum]

HA! That's the answer!

Instead of forking projects, we create schisms. Great ideological debates leads to schisms. Egotism leads to forks. Of course, forks lead to pie, so maybe they aren't all bad.

Re:Religion

[tomknight]

Luke...

...use the forks

Tom.

Re:Religion

[sharkey]

Instead of forking projects, we create schisms.

And sects. emacs or vi?

forking eh?

[alx512]

And how many versions of windows are there?

Re:forking eh?

[dasmegabyte]

His argument here is that forking is often a change in direction that means in order to support your product, you need to adapt to one of the two forks. Think of Apache 2.x...completely different from Apache 1.x, to the point that they aren't really compatible -- at least not where modules are concerned. You either had to hang on to Apache 1.x and pray for support or face the reality of the new, get new modules, which in turn means retesting all of your apps, rewriting all of your configs...not a "hard" task by any means, but that's time and energy that could be better spent doing something else.

Of course, Apache's also a good example of how market forces dicatate the fork that succeeds. Nobody wanted to move to Apache 2.0 at first, despite it having a better interface. So 1.x has undergone numerous revisions and security enhancements, it's still a strong product. Whereas new development has really blossomed for 2.x, as developers realized how much better performance and security were with the new model. The result? Two distince proudcts, two distinct platforms, with no strongarming of the market to move to the latest and greatest for fear of lack of support.

If Microsoft had this level of commitment, we'd still have customers on Windows 3.x because it was "good enough." They'd still be supporting DOS based OSs like 98 and ME. And XP would be continuously adding features and improving speed, trying to lull development to it.

All told, it's not as simple as Dr. Sauer's line. Forking does mean increased TCO. But it's as often a symptom of dedicated development as it is of personal bravado. Not that bravado is a reason NOT to fork...if a product is being lead by a short sighted asshole control freak, it's your duty as a citizen in the GPL community to bypass this bottleneck. If you've got the right idea, people will flock to you...otherwise, they've still got the original.

Re:forking eh?

[RevMike]

Don't stake your business on a piece of OSS that you aren't sure is going to be around for awhile.

Same goes for commercial software, fork or no. What if the developing company goes out of business?

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.

Forking is the survival of the fittest!

[mekkab]

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.

Re:Forking is the survival of the fittest!

[interiot]

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.

Re:Forking is the survival of the fittest!

[zmooc]

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.

Open Source means never saying goodbye

[ericspinder]

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

Re:Open Source means never saying goodbye

[ccoder]

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 creates evolution

[MarvinMouse]

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.

Re:Forking creates evolution

[pubjames]

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.

Re:Forking creates evolution

[harrkev]

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

Forking commercial software

[holygoat]

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.

Re:Forking commercial software

[Hell O'World]

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.

Re:Forking commercial software

[wiresquire]

In that case, it's not called forking, it's called job security.

Forking is a problem

[phoenix_orb]

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.

Re:Forking is a problem

[Joseph Vigneau]

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.

Re:Forking is a problem

[jackb_guppy]

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.

Re:Forking is a problem

[vidarh]

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.

forking is good, but rarely happens

[Anonymous Coward]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

The dangers of forking

[Dr. Photo]

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 about some factual proof?

[linuxislandsucks]

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!

Re:Cluck the chicken says...

[jxs2151]

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

Re:hm... sounds like science world

[JohnFluxx]

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

Re:Cluck the chicken says...

[azaris]

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.

Two simple rules

[FearUncertaintyDoubt]

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.

Software dictated by market forces.

[Rahga]

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.

Misguided, or a MS shill?

[cabalamat2]

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.

Re:Misguided, or a MS shill?

[0x0d0a]

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.

Forking is Software Adaptation

[mr_lithic]

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.

Misconceptions...

[mindstrm]

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.

All purpose expert ?

[BillsPetMonkey]

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

Proprietary software just gets discontinued

[BigTom]

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.

Choices choices!

[Walkiry]

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

What do economists know about software?

[olethrosdc]

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

That's not forking.

[3Suns]

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.

Isn't this something IT has always dealt with?

[supermojoman]

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.

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.

Re:RTFA : Forking is the danger not open source

[Theatetus]

Forking is more of a danger in open source because of its mostly distributed approach in development. Corporate software is less in danger of this because all decisions are taken from a central perspective and hence more focused.

Pay your people writing open source code and they won't fork it (or rather, if they do, you can fire them). If you want people to work for you for free, you have to accept the fact that they might want to do their own thing with the code.

Health of forking, kinds of forking

[siskbc]

Forking is extremely healthy -- look, for example, at the Apache project.

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

What about the "hidden costs" of closed systems?

[sribe]

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.

Re:Cluck the chicken says...

[LuYu]

if a compnay makes a substantial commitment to a piece of open source software that then gets abandoned, there could be real consequences.

What real consequences are you talking about?

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.

Forking is a real problem!

[happystink]

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!