"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

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?

[gbjbaanb]

you do have customers on Win3.1 - think of all those banks that still run it because it does exactly what they want (ie. client apps), and they've rolled it out to hundreds of thousands of desktops.

Now, the difference is that MS doesn't support that product anymore, it costs too much to maintain that and the others, but the customer is still using it. (note that the cost of upgrade isn't in new licences - so no 'they should get linux posts please', but in the cost of physically rolling it out to all the branches).

At some point the same thing will happen with OSS - the existing stuff will be used, but not upgraded past any end of support - the customer will be happy though as thwey have the source code and can twiddle it themselves. (which raises an interesting point if, say a bank has OSS product that was superseded by new versions, but modified it to be a niche product, would it still be unsupported?)

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!

[Pionar]

You can't honestly try to compare DVD players and software development! DVD players are a commodity product anymore. The same rules don't apply to OSS projects. Even in that industry, though, the industry members realize that collaboration on some things is better. That's why there's the DVD Forum. (I believe that's what it's called. It's the group that defines DVD standards.)

I was making the point that the duplication of efforts among many companies isn't duplication of efforts at all. They aren't going after the same result in marketing and production. If they were, every Linux vendor out there would be shipping the same exact product. They're not, so obviously they have different goals. Different companies have different markets, different customers, and different cultures. If the OP had his way, there'd be one company for each product. That's not capitalism. Have the state be that one source, and you're in socialism, teetering on the edge of communism.

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

forking IS useful

[ccoder]

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 specific one for a reason! For me, the particular flavor of P2P software I use lies SOLELY in its features, not because I think the name is catchy, or it has a neat blue icon. And when I go for support/documentation - its usually there!

Re:forking IS useful

[Anonymous Coward]

It comes in two flavors though:

1) project forks, takes two different directions. Project A drops features and adds different kinds of features. Project B goes in a different direction, but doesn't add features in A.

You now need an amalgam of A and B to get your job done. Guess what - you have to combine them yourself.

You can say that's great - i have choice, i can integrate the two.

Yeah but now you have to do software development. How many law firms are going to be doing software development? How many financial businesses want to go and hire their own staff to customize open source software to their business needs?

Commercial products are tied to the market. If I say 'I'm going to remove this feature' then my customer can say "I'm going to remove you as my vendor." Features are tied to what the customer wants, and you may lose technical flexibility, but you gain in solving the exact business problems of your customers.

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.

Death By Forking?

[Anonymous Coward]

With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces.

The development centralized within a firm is precisely the danger. The future of the product is determined by a single isolated set of minds, subject to groupthink and short-term goal setting.

But that's beside the point. Does he give any examples of Death By Forking to begin with?

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

[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

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

[ViolentGreen]

Because we all know that open source is perfect and anyone who says otherwise is from Microsoft...

If OSS is to be successful

[tacokill]

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.

Re:I agree completely.

[GigsVT]

How is unix/linux behind Windows? The way I see it, it's way ahead of Windows in nearly all areas.

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

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.

Doctor Sauer Doesn't Have the Open-Source Mindset.

[bfg9000]

... 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. Just look at all the people propping up that dying and pathetic "Windows" thing. That POS should have died long ago, but a bunch of uninformed people are fighting evolution viciously to keep it alive.

Anyway, a fork is better than proprietary software's habit of just disappearing and not giving people the option of keeping it alive as a community effort. If BeOS was open-sourced, it would be twice as big today as it ever was, due to massive community interest. Instead, we have people trying to rewrite it from scratch with a more open license. Bummer. THey're 5 or 10 years behind because of BeOS' licensing structure.

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.

BS

[hackstraw]

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

yawn

[twitter]

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 Ownership that has nothing to do with real cases. The forking argument is a really ancient troll. Blah, blah, blah, can't these dummies think of anything new?

Forking is a great strenth. Free software developers are free to take the best parts of any fork and roll them into any project they want. A project only forks when there's great interest in it and no project like that ever dies. If there are not enough developers to sustain more than one branch, surprise, there is no fork. There are countless examples of forks, such as EGCS, where the best parts of both project were merged without harming anyone's code or requiring much work from the users.

Back in reality, comercial software yanks you around much more and therefore must cost more. You can the GCC case to M$ junk such as VB which continually changes form and contiually burdens it's users with modifications and rework. Microsoft has even made versioned something as simple as word processing. If rewriting word docs all day is not a hidden cost of comercial software, it's hard to think of one.

Other hidden costs of comercial software are poor security, uncertian lifespan, virus/worm trouble, and all else connected with the upgrade train. The intentional waste alone always costs more than honest efforts. The cost of virus protection and all the other evil Microsoft band-aids adds to it. Everyone knows that you need more "admins" to run a Microsoft shop than you do for an equivalent Unix, Mac or free shop.

Evolution not a perfect model

[RevMike]

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 projects tend to imitate the more successful features of the other. Eventually, the forks will often merge, which is something that doesn't generally happen in evolution.

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:Cluck the chicken says...

[penguinstorm]

Well, yeah - maybe we have. On the other hand, haven't we had enough of this "open source is salvation" thing that seems to come up. I mean, Vancouver's recently municipal elections had a guy running on a platform of Open Source. That was it - his entire platform was that Open Source would solve our budget crisis. I personally thought he, plus the guy who's platform was Naked Vancouver, would have made a great team. So anyway, the Professor here makes a fair point: if a compnay makes a substantial commitment to a piece of open source software that then gets abandoned, there could be real consequences. Of course, the same person probably made a big commitment to Windows 98, which Microsoft is now abandoning to the wolves. I still say: put your money into people whenever you can, not software. It will always pay off in the end.

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.

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

Monopolists

[LuYu]

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.

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.

Bad Economics = Bad Assertion

[salesgeek]

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.

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

[timeOday]

Valid criticism is one thing, but forking? Not a major problem in my life.

Linus credits the GPL (as opposed to other open-source licenses) for preventing fragmentation:

I personally think that the BSD license is a dead end for serious projects, since it inevitably results in forking with no way to re-join if it becomes commercially viable.

Perhaps he has a point, because none of the GPL OSS I use has been spoiled by forking.

Re:Forking commercial software

[k12linux]

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 customizations to survive version changes. If you are overly protective of your own modifications and don't want to share... then be prepared to accept the consequence of forklift upgrades.

This is not limited to in-house development. Many vendors will modify thier own software for a customer to the point where a simple upgrade is impossible. Part of the problem is poor fork management and lackluster customization skills. But that doesn't make the next upgrade any cheaper.

Another point that should be made is that forking is less of a problem in OSS because the pool of developers is not fixed and small like it is with proprietary software. Forks generally increase the number of developers overall. And forks tend to either be merged back in, die off, or replace the original completely depending on the quality and popularity of the changes introduced.

Also, forking a proprietary software package can be much more risky than forking proprietary. Lets say you customize accounting software that sells for $1000/seat and resell the custom version (assuming the license permits it) for $2000/seat, making $1000 gross profit per sale. What happens if the next version doesn't permit resale? What if a "source" license jumps to $10,000/seat? What if the parent software company goes out of business and the full source goes into limbo?

Of course, with proprietary, you always have the option of not forking at all... but you do with OSS too, so big deal. More to the point, in the vast majority of cases you don't even have an option of forking proprietary if it doesn't meet your needs. Instead you have to force your business to fit the software instead of the other way around.

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.

Ob Python quote

[BenjyD]

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

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

Re:Religion

[sharkey]

Instead of forking projects, we create schisms.

And sects. emacs or vi?

Re:Religion

[Anonymous Coward]

Perhaps. But don't you think that bad ideas can lead to forking?

Hypothetically speaking: If a large group were trying to make pedophilia an acceptable part of your religion, would it be intolerant to reject that? Or should you just accept the change in the "name of tolerance" ?

I think a splinter in that case would be fully justified.

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

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]

I thought his fear was that whatever solitare^H^H^H^H^H^H^H^H software he is running might be discontinued and him forced to start using another one.

But isn't the possibility of a fork better than the idea of complete discontinuation (don't even know if that's a word, but you get it....) A project splitting would most likely be better than a project dying...

I'm still waiting on the upgrade for Microsoft Bob... you'd think they'd have it done by now...

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.

TOC - (Subjective Cost of Ownership)

[ericspinder]

Guess you never took any management ? - from an AC troll

As a matter of fact I did take management classes in College, plus Accounting and Marketing.

Sorry.. truth hurts. - same AC troll

I don't really think the Microsoft invented that term, but they do have a tendancy to use it whenever they describe their advantages. So to associate MS with that term is appropiate. In your overly simplistic and trollish way you are correct, TOC (Total Cost of Ownership) is a valid term. What I mostly object to is the incomplete usage and analysis that usually goes along with it. For example, they never include the cost to protect against viruses, or the cost of repair infections(which is also a "fact of life"). Another is the cost of having to change your software when a company decides that they no longer want to sell that product (which has happened to me). Granted not ever company goes out of business, so the cost of changing software would need to be multiplied by the historical chance of the company pulling software. There are many other "costs" which never seem to make it into calulations for the TCO. In fact, I have never seen a proper line-by-line balance sheet description of a TCO analysis, if you have I would love to see it. Even if you can find something that might pass to you as a complete example of TCO, you must understand that most people's TCO anaylsis includes a lot of hand-waving and "trust me it's cheaper", without any real data.

If you have ever had an advanced accounting class, which I doubt, you will know that there are many ways to look a particular set of numbers, to "spin" them to be appropiate for your point (if you will). That is why I perfer to call it SCO (Subjective Cost of Ownership), but since SCO is already a well known curse (at least in the Slashdot world), lets just call it really is "FUD".

DOS/Win/Win98/WinME SystemN/BSD/SunOS/Solaris/...

[Ungrounded Lightning]

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.

Dead on.

Proprietary projects fork and change, too. But after that one fork generally gets dropped or spun out and the older system abandoned. Users are stuck with the vendor-chosen "upgrade", or with changing vendors.

With an open source product they CAN'T pull the rug out from under you. The older version is still there, as are the multiple newer versions. Pick a fork and upgrade in your own time - and if nobody wants to maintain it for you you can always maintain it yourself, until YOU chose to hop versions for some cost/benefit improvement to YOU.

Forking is a PLUS for open source, not a minus.

Re:Religion

[willtsmith]

Speaking of religion, let's talk about economics. Specifically, ALL market economists would claim that a diversified, competitive marketplace is GOOD.

In this case, multiple open source varieties compete to gain over the larger community. The poorer one's are abandoned. Other entrepenuers than take the superior source and innovate on it. It's a perfect market solution. Save one thing ... no one is selling it.

Of course a Soviet Style software planner would choose the Microsoft model. All code is proprietary and must be approved by the bureau of global dominance.

I think this economist needs to revisit his messed up models and worship of corporate mega-dominance.