"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.
Link to the Article by Dr. Robert M. Sauer? (Score:4, Interesting)
The article link is .... (Score:3, Informative)
Re:Link to the Article by Dr. Robert M. Sauer? (Score:3, Interesting)
Re:Link to the Article by Dr. Robert M. Sauer? (Score:3, Funny)
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? (Score:3, Insightful)
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 wa
Re:Link to the Article by Dr. Robert M. Sauer? (Score:5, Insightful)
DOS/Win/Win98/WinME SystemN/BSD/SunOS/Solaris/... (Score:3, Insightful)
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
Re:Link to the Article by Dr. Robert M. Sauer? (Score:5, Insightful)
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?"
Health of forking, kinds of forking (Score:5, Insightful)
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:Link to the Article by Dr. Robert M. Sauer? (Score:3, Insightful)
Linus credits the GPL [com.com] (as opposed to other open-source licenses) for preventing fragmentation:
Perhaps he has a point, because none of the GPL OSS I use has been spoiled by forking.
Re:Link to the Article by Dr. Robert M. Sauer? (Score:5, Insightful)
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? (Score:3, Insightful)
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...
Religion (Score:5, Funny)
Re:Religion (Score:5, Funny)
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 (Score:2)
Mmmmmmm... fork-pie.... [drool][gurgle][drool]....
Re:Religion (Score:3, Insightful)
And sects. emacs or vi?
Re:Religion (Score:5, Funny)
Tom.
Re:Religion (Score:3, Insightful)
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
Of course a Soviet Style software planner would choose the Microsoft model. All code is propr
Cluck the chicken says... (Score:3, Funny)
Havent we had enough of this "dangers of open source" crap?
Re:Cluck the chicken says... (Score:5, Insightful)
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.
Re:Cluck the chicken says... (Score:5, Funny)
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.
Re:RTFA : Forking is the danger not open source (Score:4, Insightful)
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.
Re:Cluck the chicken says... (Score:5, Insightful)
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 eh? (Score:4, Insightful)
Re:forking eh? (Score:5, Insightful)
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? (Score:3, Insightful)
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 br
Re:forking eh? (Score:3, Interesting)
Re:forking eh? (Score:5, Interesting)
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.
Re:forking eh? (Score:3, Interesting)
Have you've ever had to do this?
Small company + out of business = "Here is the code we scraped together, no one left knows how it works or even if its all there. Good Luck and Good Bye!"
Re:forking eh? (Score:2)
That's like saying "When you go the track, make sure not to bet on the horse that's going to lose". How the hell do you know, without a time machine?
While I agree that forking does not equal "doomed", it is the case that forking equals "look around, see where the project is going, re-evaluate your needs, and make sure you have a backup plan"
Re:Standardised Modular code (Score:2)
Forking is the survival of the fittest! (Score:5, Insightful)
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! (Score:5, Insightful)
Re:Forking is the survival of the fittest! (Score:5, Interesting)
Open Source means never saying goodbye (Score:5, Insightful)
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 (Score:4, Interesting)
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 :).
TOC - (Subjective Cost of Ownership) (Score:3, Insightful)
As a matter of fact I did take management classes in College, plus Accounting and Marketing.
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
forking IS useful (Score:2, Insightful)
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
Forking creates evolution (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3)
If two projects diverge to the extent that it would be such a pain in the ass to try and merge them that nobody wants to do it, that is effectively "speciation" in my book - specialization to the extent that "breeding" (intermingling of code/DNA) can no longer occur.
Still, I doubt there's a point of no return where the difference between two branches are too vast to bridge, the changes impossible to port.
Impossible is one thing, pain in the ass i
Re:Forking creates evolution (Score:4, Funny)
At least I think they are saying "forking."
Wow - that is one subtle troll (Score:2)
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? :)
Short-termism (Score:2)
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!
Evolution not a perfect model (Score:3, Insightful)
On a more serous note...
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
Re:Forking creates evolution (Score:2)
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
hm... sounds like science world (Score:2)
Re:hm... sounds like science world (Score:5, Insightful)
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 [ucsb.edu]
Forking commercial software (Score:5, Interesting)
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 (Score:2)
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
Re:Forking commercial software (Score:5, Insightful)
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 (Score:3, Insightful)
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
Re:Forking commercial software (Score:4, Funny)
Re:Forking commercial software (Score:3, Interesting)
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
Forking is a problem (Score:5, Insightful)
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 (Score:2, Interesting)
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.
Re:Forking is a problem (Score:5, Insightful)
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 (Score:4, Informative)
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 (Score:5, Insightful)
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)
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... (Score:2)
Re:This sounds like... (Score:2)
"Windows forks every couple of years, so what's the problem?"
God you're dumb. Maybe without that your rant would have been passable, but you got greedy asshead.
-- MarkusQ
Forking no more a risk than buyouts (Score:2, Interesting)
-chris
forking is good, but rarely happens (Score:4, Insightful)
Comment removed (Score:4, Insightful)
Forking? What forking? (Score:2, Informative)
I suppose OpenBSD could be considered a fork, but the effe
If OSS is to be successful (Score:3, Insightful)
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.
The dangers of forking (Score:5, Funny)
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.
Re: (Score:2)
Mozilla Forked (Score:2)
forgot the counterpoint to forking... (Score:3)
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.
Forking is a problem for Management... (Score:2)
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.
Forking and abandoning projects (Score:2)
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)
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.
how about some factual proof? (Score:5, Insightful)
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)
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. (Score:5, Insightful)
"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? (Score:5, Insightful)
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? (Score:5, Insightful)
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. (Score:2, Insightful)
Forking is Software Adaptation (Score:3, Insightful)
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)
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.
More forking, more abandoned (Score:2)
Misconceptions... (Score:3, Interesting)
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.
Fitness landscapes and software development (Score:2)
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
yawn (Score:2, Insightful)
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
All purpose expert ? (Score:5, Insightful)
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.
Proprietary software just gets discontinued (Score:4, Insightful)
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! (Score:3, Funny)
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? (Score:4, Insightful)
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)
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.
Bad Economics = Bad Assertion (Score:3, Insightful)
* 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.
Isn't this something IT has always dealt with? (Score:3, Insightful)
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.
This article is a troll. Everyone wants to fork! (Score:3, Interesting)
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)
"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!"
What about the "hidden costs" of closed systems? (Score:5, Insightful)
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.
Forking is a real problem! (Score:5, Funny)
What danger? (Score:3, Funny)
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)
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.
Re:I agree completely. (Score:2, Insightful)