Slashdot Mirror
"Forking" Greatest Danger of Adopting Open Source?
TTL0 writes "In response to recent descisions in favour of Open Source in Israel (see here
and here),Dr. Robert M. Sauer of the Department of Economics at Hebrew University of Jerusalem, and president of the Jerusalem Institute for Market Studies. has written a article saying that the hidden costs of OS add up to a higher TCO. However, The greater danger Sauer writes, is that of a OS project forking. "The forking of open-source projects occurs when passionate disputes between open-source software developers over product design lead to the splintering of projects into a multitude of varieties. With proprietary software, forking generally does not take place since development is centralized within a firm and disciplined by market forces."" I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger.
Does anyone know the link to the article by Dr. Robert M. Sauer that is mentioned in the story?
If forking is acceptable in religion (notwithstanding "mine is the One True" etc.), it should be acceptable in software.
The Sky is falling!!! Watch for falling Bits.
Havent we had enough of this "dangers of open source" crap?
And how many versions of windows are there?
Does this guy actually have any data to show that TCO is higher in OS, or is he just blowing smoke? If I was not mistaken, the data showed the contrary.
Besides, where's the article?
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.
In the future, I would want to not be isolated from my friends in the Space Station.
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).
The grass is only greener, if you don't take care of your own lawn.
do we smell a Microsoft-backed study here?! closing off software is bad, opening it up brings out new ideas and new innovations. its like hoarding the code to some software and making people upgrade to it without having the option or freedom to choose what they want.... Hey, isnt that what Microsoft does?
http://www.geocities.com/baddsectorr
Yeah this is obvious.
/over/under/don't really/ perform..
Its like one of those $2 million goverment funded studies that finds that white/black people
and the data was faked!
(There really was one like that)
Anyways, the point is its useless. Don't really need a proffesser to tell it to me. [Finger] Up yours doc! [/finger]
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!
"During times of universal deceit, telling the truth becomes a revolutionary act" -- George Orwell
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.
~ kjrose
i think this is somehow part of human nature: in science (where i work) people tend to have collaborations until some a**hole comes along who does not believe in collaborating. the project splits and suddenly you have two papers about the same. if there was one paper in the first place, it would probably been a really good one, but now you have two mediocre works. if you now are a scientist in industry (which would correspond to something like microsoft) you better know how to work in a team or you are out.
having said that i conclude with the statement that collaborations are extremely important in order to push towards a novel idea or result. on the other hand having some kind of kindergarten mama (a company) watching over us kids sometimes makes us produce more and better.
but then again, if there are many groups working on the same they will compete. and that ensures a better product/result in the end. ah, what the heck, i don't know...
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?
My PhD supervisor once worked at Schroders Bank. They didn't want to pay 20% of installed cost per year for an information system, so they decided to maintain it themselves.
Bad idea.
Cut to a few years later. Their own maintenance has rocketed the cost well beyond 60% of installed cost per year.
Even worse, the forking has meant that there is no upgrade path to the latest commercial version, causing the system to be an absolute millstone - and no way out.
It's a problem in the enterprise market, where custom software gets built, as well as in Open Source software.
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.
Blah Blah Blah.
How many hundreds of linux distros over the same period of time?
"the hidden costs of OS add up to a higher TCO"
The hidden costs of Operating System? Some people call Free/Libre Open-Source software FLOSS, FOSS or just OSS. I just spell it out and use the words to avoid confusion.
And I'm genuinely sick of people using terms like "hidden costs" and "TCO". Please, just drop this fad-ish jargon. Okay fine, you can use "hidden costs" if you must.
This sounds like the typical excuses I hear from the Microsoft-brainwashed people that give presentations to the public-school Tech Coordinators in my area... "It's open-source...anyone can look and see your code!" "It's got a higher TCO!" "It's open-source! It might fork!" My response is the same as a previous poster...Windows forks every couple of years, so what's the problem?
How is the risk of project forking greater than the risk of product obsolesence through buyout? Ask all those folks who've had a software vendor bought out, only to be forced into a 'new' of 'better' product.
-chris
People are bound to have disagreements, and since they are allowed to make the changes as they see fit, they can simply start their own little "tine" (to keep with the analogy of a fork) of the project and hope people go along with it. This can help spark interest in the project, and possibly provide new advances in the technology that wouldn't have been possible without the "schism".
I don't see a problem with this. It's a natural extension of the "everyone can add what they want" mentality.
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 based on user account deletion
This, I think, is the greatest danger: open source is designed to fit my needs, commercial software is designed to fit yours. Depending on the community you wander into, your level of open source support ranges from extraordinarily helpful to RTFM and a flaming bag of dogshit on the stoop. With commercial software, there is a degree of consistency and integration you just don't get when you're trying to cobble together disparate packages, each with a separate interface and support policy.
Honestly, forking should be at the bottom of the list. Trying to figure out whether you need '/?' or '-h' or '--help' or 'man (whatever)' or 'info' or 'mozilla' to just get usage info about an application is closer to the top. It's hard enough getting people to tell you how many buttons they've got on their printer during a support call.
I suppose OpenBSD could be considered a fork, but the effect on its parent has been practically nill - if anything it has benefited by back-porting work done by the paranoids at OpenBSD which simply wasn't happening before the fork.
Forking is usually a blessing. Think about it :
:
When a project doesn't fit a certain need or the quality of it is not up to date somebody forks a new tree.
If we're lucky the old (crappy) program dies. Therefore it's a sort of evolution : The fittest survive.
If the base project is not crappy it of course continues to live. If however the fork filles a certain niche both base & fork live side by side togther. This not only gives us more choice, but also results in programs better suited to your needs.
The above of course does not happen in open development models. The programs are based on the (usually rigid/outdated/out of sense with reality) ideas of management.
Only problem with forks is
1) Lot's of time money spent on project
2) Better fork comes out
3) NO PROFIT!!!!
The fact of the matter is, unix is ALWAYS behind windows. Until everyone UNITES, Microsoft will never be rightfully usurped.
This isn't just a problem in open source development either. Happens with multiplayer online game servers (Everyone decides to make their own mod, and we end up with 5000 different variation servers, each with 2 people on it. Hooray. Continuum and Quake3 both suffer from this.)
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
We need an "Adam Smith" to write some books for the Open Source community. Sure, by developing software with Open Source, one gives up control compare to closed source model. Just as a free market econonmy has less control over a controlled econonmy. But one has to realize that the invisible hands of Open Source will guide development to a state that best satisifies all participants, developers, users alike.
With Open Source the cream rises to the top. A project may split and goes separate ways but nothing is preventing the groups from incorporating good code from each other. Just look at the *BSDs.
How is a monolithic, closed system better again?..
Trolling is a art,
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.
Forking can be detrimental to a project. Why, just because some jokers forked the tree, chimpanzees have failed to take over the world.
What's more, so much redundant effort is going to the forked project. P. Troglodytes and H. Sapiens share over 97% common code base, and yet the splitters couldn't be bothered to add a few new features to the chimp. Nooooo, they just had to start their own little project instead of working with the existing code base. If this trend keeps up, open source is doomed.
Unhappy with the focus of the GUI, Mozilla Firebird and later Mozilla Thunderbird forked from Seamonkey. These have been very successful. Unfortunately, many Seamonkey developers were unhappy about the way it was done and some may refuse to contribute to the *bird projects out of spite. All of these projects are under the domain of the Mozilla Foundation, but the roadmap has not been updated in quite a while.
Which is that both sides of a "fork" actually adopt the best practices and best code/functionalities of each other.
Imagine there are two projects: "A" and its fork "B". If "B" programmers are smart, they'll keep on tracking the changes brought to "A" and incorporate the best features and patches from the original project.
In the same way, "A" programmers will keep an eye on "B" and take the code they need to improve "A".
And there are many examples of this in the open-source world: NetBSD and OpenBSD, Emacs and XEmacs, etc...
Forking does not necessarily means a loss of quality or incompatible programs. In the worst possible case, if one side of the fork is clearly better, it will eventually replace the other.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
There has been a lot of conflict around just this fork for some time. More information on XEmacs homepage with some mailinglists messages.
Note to self: get smarter troll to guard door.
Never forked? What never? What about the Win 95/98/ME vs Win NT/2000/XP fork? (Or the earlier Win 2.1/Win 386 split?) I haven't counted noses of all the Wince/Win Pocket variants running around recently -- the number changes too quickly.
One line blog. I hear that they're called Twitters now.
Sorry the costs are all up front and there for you to see. Open Source has NO hidden costs.
He did not research his decision well enough.
Closed source can have lost of hidden costs... how many people that use closed source accounting software figured in the cost of having to buy all new software and hire temp's to key in the old data to the new system when the old company went out of business or was not around for the Y2K fix?
Open source? they cant go away or stick you with a timebomb like that is typical in closed source apps.
Do not look at laser with remaining good eye.
... because it forces them to make a decision that can only be rationally made on technical grounds (which fork is best for our needs, is the cost of supporting multiple forks worth it, etc.).
PHBs fear decisions like this, because they either have to defer to their better-qualified underlings to decide, or take a guess and risk looking stupid afterwards.
To a Lisp hacker, XML is S-expressions in drag.
that people don't read the articles and don't even bother to link them.
The only problem with an opensource program forking is deciding which fork to follow. Time is also on on the side of the adopters as they have the same code base for quite a while anyway. It takes time to make those changes that caused the rift.
Forking is definately not limited to Open Source. I've seen it happen many a time to comerical software. For instance: =Microsoft's Windows95 tree vs. Windows NT tree. =Rational's PreVue vs. Performance Studio vs. Performix are just a couple I can think of off the top of my head. What tends to be more annoying when forking happens in a comercial setting is often, they will fork to a new direction, support both for a short while, then cut off all support for the old code, even if the new code cannot fulfill some functions. The nice part about open source is even if a codebase is completely abandoned, a company that wishes to use the code badly enough can take on further development efforts themself. Of course, this is not an option for closed source.
--- It's not my fault this post looks redundant. I just type too slow.
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 initially attracting a reasonable number of users only to have one fork left to languish? There are various possible reasons for this; less users than developer egos need to sustain interest, technical implementation issues, and so on. I can't think of any significant instances where this has happened yet, only smaller ones, but that isn't to say it couldn't happen and a few high profile projects have recently forked that this could happen to.
UNIX? They're not even circumcised! Savages!
Versions of Windows: About 5
Versions of Linux: Hundreds
Forking is a massive problem in OSS, the amount of hours that must be waisted by Open Source Developers basically duplicating code already written somewhere else for a virtually identical but slightly different project is depressing.
If only Linux code could be made more standardised, modular and encapsulated the world would be a better place.
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.
Your Servant, B. Baggins
It's safe to say that a bunch of people who worked on either would not have all worked on one, if both had not existed.
The real problem with Gnome and KDE both existing is that, rather than one reasonably solid desktop (KDE was first), we ended up with a religious war and now a ton of K-apps and G-apps.. and it just leads to confusion, and wasted effort.
If you happen to have 4 billion years. Me, I don't got that kind of time.
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!
Don't Tread on OpenSource
Given the sexual habits of most people involved in software development, I think we can be confident there will be very little forking.
Probably not very much spooning, either.
This is something I've posted about before. Choice is a good thing but having too many variants of the same software (especially when incompatibilities creep in) can lead to massive headaches. Which one do you install? Variant-X has feature-1 but Variant-Y has feature-2. Neither one has both features but I need both. What do I do? Install them both, spend time learning them both, and switch back and forth between them? Again, choice is generally a good thing, but not when there are so many choices that it clouds the real issues. Most home users just want something to work. They don't want to have to sit around spending time thinking about which choice to make when many times they won't even understand all the details about what they are trying to decide, much less the non-relevant details that they'll also have to start factoring in because they *may* want to do them in the future.
Not to mention, having many forks of the same software generally leads to "reinventing the wheel" many times as each political camp believes they are forced to do it "their way" in order to prove that they are "right". Lots of duplication of effort when those resources can be used on something else that is not currently being addressed.
Another issue of forks is from the developer side. So your group is chugging along nicely. You release your code and go into your support mode for it, hoping to make some money. The developers decide to split from your group and open up a competing group to do the same. You just funded the development of the software and are left holding the bill for it while the developers start with a clean slate and take all your prospective support contracts. It was nice of you to donate all your money to their cause.
Similarly, forking of resources during the development of some app can stall both/all forks for an even longer period of time as the resources are thinned and focus diverges.
Also, with many variants out, particularly in the areas of platform advancement (developmental libraries and APIs) for things like sound, graphics, and the like fragment and stall the advancement of the platform itself. You have no API/library that developers can count on being present so you put them into the position of the "you gotta also install" which opens up all those issues (stomping, 3rd party dependencies, etc). You have no common model so the whole scene is fairly chaotic and unorganized. Say what you want about Microsoft, but I firmly believe that their consolidation on APIs such as graphics drove the graphics card industry to be at the advanced level that they are in now, which everyone else is able to take advantage. With a common API and functionality set, it made sense to develop hardware to handle these tasks because the hardware vendors could make money because there was one standard to support, not many. One standard means one final product to develop. With many variants or different APIs/standards, costs go up as you have to develop and support a different product for each one. With so many APIs to do one particular task out there, it's like herding cats across a field trying to advance your platform, IMO.
If there is any example of the victims of forks, Gnome is it.
As you know Gnome is a pseduo-fork of KDE (they forked the idea, not the code), but unlike KDE it had no real sense of Direction, it just wanted be "cooler" than Kool and gnu/Hippy. Now the architecture is mess. Here are three examples of the mess gnome has got into while KDE has done it right.
Window Handling Subsystems (AKA Window Manager)
KDE wrote theirs correctly, known as kwin. Gnome on the other hand outsourced their development of theirs to projects like sawfish and enlightenment. It became inconsistant mess and it was only when Gnome 2 came out did they fix it and wrote metacity, which is still in a beta stage, meanwhile in KDE 3.2 beta, the 3rd generation of Kwin has matured and is a lot better than metacity.
Web browsing.
This is still a mess. KDE has the fast and stable KHTML, which is so stable Apple uses in Mac OS X. Gnome has two competing html engines gtkhtml and gecko and three competing browers epiphany, mozilla, galeon.
File managers
Again, gnome had no clear direction on what to do, in fact they took the horribly buggy and slow nautilus (No wonder Eazel failed) and warped it. They keep changing paradagrims in each point release. Todays flavour is Windows 95, try Gnome 2.5 and see. KDE has had konqueror that intergates using KIO technology, and has a supplemental file dialog to match. Now with Quanta i can save my HTML to the server directly with the file dialog. I cant do that with Bluefish.
There are a lot more examples, but as you can see, without a clear roadmap, defined goals and a ridgid infrastructure, you end up with many forks, implementations and it all ends up in a stinking mess.
Thats why I use KDE 3.2 beta 2, and don't have be a member of the Window manager of the week club.
it's the abandoned projects are the ones that are in danger.
Projects being abandoned/ended abruptly are a risk with any software, opensource or not.
Comment removed based on user account deletion
The danger is not of open source but of forking in/to open source. 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.
The price of freedom is eternal vigilance.
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.
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.
I'd love to see how you managed to integrate a telescopic sight into your rearview mirror. Do you have one of those 1"x1.5" tvs hooked up to a DV camera that points out the rear window or what?
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.
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.
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? :)
ok, gnome and KDE is the best example of a situation where none has collapsed because it was dominated by the other one. Still, it's only a matter of time (IMHO) and these two projects aren't working in different ways. They can even understand each other !
...
...
... guess why ? competition :)
About experts, the whole open-source system proves that the best things aren't necessary made by experts. They are made by people who need it. What make it great software it the test of time. And people will soon become experts in their field
Apple sure has human interface experts, and make beautiful software (even if I'm not a fan, though). Open source projects are a little behind, because you must let the time operate
And the last thing that's great when there is a fork : people tend to be really hyperactive at finding new features
... 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.
I'm not normally an irrational zealous dickhead, but I figure "When in Rome..."
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.
Yes, there are different forks of Windows. For example, there is Windows XP Embedded. But that is only within one company, so it must be good...
g =n efd_top
http://news.com.com/2100-7349_3-5117285.html?ta
They're just lucky we thought they were cute. Without us to keep them alive, they'd be toast.
...has written a article saying that the hidden costs of OS add up to a higher TCO
OK, 1st I have never seen a valid way of _measuring_ TCO and this guy can measure "hidden costs" in TCO. So are these "hidden" costs things like security breaches, viri, worms, buggy software, new bugs introduced by a patch/upgrade, etc? And these things can be preemptively quantified in terms of $$ ?? !! Amazing.
Now with the forking problem. Well, its a part of life. Churches do it, companies do it, religions do it, nations do it. I have never been negatively affected by a forked opensource project. The biggest fork of a project I can think of was when gcc was forked into egcs, which was eventually unforked back into gcc. I'd take the gcc we have today over the one years ago anytime. Even with the gcc/egcs fork there was no problems any different from an upgrade from any complex computer program.
And in closed source, this keeps "forks" from happening? Closed source companies go out of business, their programers go to other companies, etc. Although code rarely gets transfered when these things happen, other closed source projects spring up to compete or fill some void for people. That is similar to a fork except its more like a rewrite.
Back to work. I've got to unhide some hidden costs to lower the TCO for my PHB ASAP.
The problem with forking is that the more projects that get forked, the more abandoned projects we have. If everyone's effort is on one project, then the liklihood of that project losing all developers is slim compared to if you had several forked projects all competing for the resources of the developers.
This guy is an Economist, so clearly he should be telling IT managers and software developers how to do their jobs. Uh. Or something.*
The reality is that if those vaunted market forces push the development of a proprietary app away from your needs you are screwed. If you want bug fixes you have to take (buy) whatever they give (sell) you. But with "Open Source" you can minimally do your own fork that keeps functionality as desired, but allows you to make (or contract for) bug fixes and enhancements.
There is even some hope that a more general fork will break your way. No chance of this with a proprietary package.
By the way, was there supposed to be an article or something?
-Peter
P.S. These are the same guys that went on about "the new economy" a few years ago, and are now talking about "the continued move to a service-based economy" and nodding sagely. Like Meteorologists, they pump inadequate data through flawed models, and then expect us to take them seriously.
Everyone remember... if you aren't used to the open source world.. there are some things you take for granted that need to be re-assessed when you go to open source.
Things like : forking.. when you see a project, and it forks.. you think of a company that just split in two, having developers leave, internal strife etc.... it will probably hurt the customer. Not necessarily so with open source.. the fork could be simply becaues a couple recent developers wanted to take things in a new direction. You don't lose, everyone wins.
Version numbers: Commercial ventures use versioning as a marketing tool.. but with many OSS projects, it's just a developer tool. Just because something is 0.xx or 1.xxBETA doesn't mean you can assume anything at all about it's stability or features, or worthiness. Sometimes it's 0.xxBETA simply because the developer always had one feature he wanted to add, and never got around to.. it could be rock-solid. The old adage about "never use a 1.0 release in production" comes about because commercial developers usually call their first release 1.0.. and the first commercial release is usually buggy as hell, as it came out early due to marketing pressure... and it's the first time it's hit a wide audience.
Support: One of those things that means differnet things to different people. Remember, many non-oss people just want individual applications, and somewhere to go for concise info about those applications.. they don't really picture everything as a big pile of tinkertoys to glue together like with unix/oss. In 10 years of OSS, I've never had problems finding answers to my questions.
GPL fud: Seriously, the zealotry about hte GPL has got to stop... everyone should read it and question their assumptions about it. A great many people still think that anything you write for Linux has to be GPL, and that you can''t practically write closed software for linux. They think the compiler requires you to publish your source, etc. I know it's obiviously not that way, but to many , it's not.
Dictators: People see one guy in charge of a project, Linus being a common example. They say "who's to say linus is going to do what business needs?". Well, true. Nobody can guarantee that. But for a decade he's done a good job.. and what they need to realize is that the projects are driven by those who contribute to them. The reason it's popular, and that you hear about it, is because it's good. These leaders aren't dictators... people follow them because they are doing a good job. If Linus went insane and started doing weird stuff, you can bet there would be a new leader or group emerge.
If you say that programming is the stepped solution to a problem, you could envisage it as a climb up a fitness landscape, with the goal of the program being the ultimate summit.
:-) onto a different hill, which they then iteratively climb, instead.
... isn't that odd...
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
Sure, you have less resources per group, but you are now attacking two different problems, and forked projects can feed off each other (it's OPEN source, remember) so it's not as though you now have 50% attacking each summit, it's more like 75%
Simon.
Physicists get Hadrons!
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!
Ceterum censeo subscriptionem esse delendam.
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.
Friends don't help friends install M$ junk.
They've got you so on guard that you think anything that's dying is BSD.
Take a deep breath. Shake it off.
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 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.
Forking occurs all the time in proprietary products. The public simply cannot see both forks. When a Microsoft product changes strategy - like office file formats, or Windows networking - that is a fork. There is the old way, and the new way.
... that commercial software forks too. Remember when lots of software wouldn't run on the NT branch of Windows?
This article has lots of comments about commercial software switching to a new version with different features, causing a dilemma - Winamp 3 is a prime example.
The only difference that FLOSS provides is that
(a) the teams can trade code easily, often without permission, and certainly without managerial overrulings, which allows feature migration
and
(b) if you're stuck, you have the option to do it yourself.
It's foolish to say that commercial products are tied to a market; they're not. They're tied to a vendor. That vendor's profits are tied to a whole load of customers. If you're one customer, you don't have nearly the power you think you do, particularly when you consider shareholders.
Forking: Simultaneously Open Source's greatest strength and weakness, it seems.
I personally think the strength of it outweighs it as a weakness.
This has happened on Win as with other CSS software (API of the month club). The difference is that you are in the hands of the designers and have no option but to follow, even if you don't want the new features. With OSS, you can fork back to what you want, if you are prepared for the support overhead.
See my journal, I write things there
I consider the possibility of forking one of the significant factors of open source. It may even be the distinguishing factor against proprietary software.
First a good OSS leader might be more motivated to accept changes from other developers to prevent forks. This is like a healthy competition, where one party has little first-mover advantage, because others with good ideas can start from the same base. For me this is much better than when a certain project has a lead which stifles other projects because the have to much catch up to do before their cool improvements become attractive.
However, if the changes are too different from the opinions of the people in control, a fork is always an option. In this case the users can decide which branch they like best. If two (or more) branches exist for a long time with similar popularity, then probably they serve different purposes or user groups.
Note that one of the plusses would be that branches might possibly merge again once the differences are reconciled and the advantages of both branches might become available. Especially the GPL garantuees that such merging is always possible from a license point of view.
My final observation is that I usually consider the fact that a project has no significant fork as a sign of quality. Probably the project has made all (or most) right decisions that there is little need to fork. Usually it is better to go with the flow and be happy with 90% of the decisions and enjoy the support of many community members, than to have all you 100% wishes but be one of the few users. This is probably why you dont see much forks in general.
To conclude: The fact that a fork is possible is probably very valuable, even though (or as a result of which) forks do rarely happen.
Dr. Robert M. Sauer of the Department of Economics at Hebrew University of Jerusalem, and president of the Jerusalem Institute for Market Studies
... we interrupt this broadcast ... to get a comment on the NASA programme from Dr. Hibbert of the Chicago Institute of Modern Art ...
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.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
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.
OSS forks.
Windows borks.
Apple is for dorks.
Now choose!
(Wonder if I'll be modded down by mac users with no sense of humor...)
---- Take the Space Quiz!
The fear of forks, comes from the fear of losing support.
Who didn't feel uncomfortable about Red Hat Linux turning into Fedora? It's the same thing, only Red Hat isn't behind it anymore....
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).
I miss my rubber keyboard.(Homepage)
Fork is a four letter word in my vocabulary, and it is that word that stops me from taking some of my projects open source. I worry that members of the project team will argue and discuss a fork, leaving me to try and hold the 'team' togethor.
paul reinheimer
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.
All data is speech. All speech is Free.
Nothing new here. Just a veiled FUD attempt to support Micrsoft. Forking is a good thing, it gives users more choice but more importantly the better software wins out on merit instead of marketing hype and ponderous corporate greed.
My karma is not a Chameleon.
I can tell that you're trying to make a valid point, even if it's one that's been tried many times before. It's a misguided point, of course... would software be so much better if the industry didn't have so much duplicated effort and everyone went to work at Microsoft? I hardly think so. Besides, Gnome developers usually become that way because they can't stand the thought of coding for KDE, and vice versa.
However, Gnome and KDE are most certainly not an example of forking. They grew up entirely on their own, and there was never a common parent. Forking means taking one project and making new projects from it, starting at a branch point. Examples: Emacs and XEmacs, XFree86 and Xouvert, Sodipodi and Inkscape, RedHat and Mandrake, Debian and UserLinux (in the future), Net/Open/Free BSD's.
Sometimes forking can hurt a project, but often times it encourages innovative work in a different direction. Usually, however, it signifies a problem in the management of the project; if a developer is frustrated by the project leadership, they might fork the project rather than struggle to get their viewpoint heard on the main project. One of the testaments to the managerial skills of Linus Torvalds and his lieutenants is the fact that the Linux kernel has not undergone major forking. Kernel developers in general feel that they can get their work done adequately on the main Linux branch.
-3Suns
~~~~
The Revolution will be Slashdotted
In fact it would have been much better if they had forked from one common base. Less resources had been wasted on developing common bases, and they would probably be more compatible with each other due to the common base.
However, even in this case, with no fork involved, the competition might still be a healthy thing. I am not a heavy user of each of them and have no strong preference, but I assume there still are some fundamental differences in some matters that justifies the two different projects.
Also note that such competition is very common in the closed source world as well. However, in such cases the "intellectual property" might be the driving force, of companies offering very similar products which mostly vary on other aspects (like marketing, pricing, etc)
Note that the Halloweed docs were a "secret" set of memos prepared by a top MS employee for Microsoft top management when they were developing their strategy against Linux. So it is certainly not biased in favor of open source!
Therefore, I think that the assertion that code forking is a "danger" which cannot be mitigated is wrongheaded. Rather, forking can be a problem, but can be managed by adjustment of the licensing agreement for the software.
I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger
no one asked for your opinion. This is a news site, not an editorial forum.
I misread fork for fork()
But it will sigsegv after a few seconds ... i can't imagine a big fork bomb performing on windoze for more than 10 seconds ... = )
WTF am I doing replying to an AC at 5 A.M on a Friday night?
We must Pave The Earth!!
I am very interested to read the article itself. Could someone post a link please? (Included with the submission perhaps??)
Wow! Instant credibility! I think I'll go get my Ph.D.!
I can be like "Dr. Condoleezza Rice" and get actual credibility.
-- I am. Therefore, I think!
The only way that Free Software would raise the TCO is if you wanted the features of two or more forks and expended resources to create your own fork of the forked projects. However, this would be equivalent to writing a closed source tool that did not exist with no market for your own use, except that in this case, you would already have 99% of the work done for you. You would just have to combine the code you wanted instead of writing it from scratch. In the end, it would cost a fraction of writing your own tool from scratch.
All data is speech. All speech is Free.
[Disclaimer: As I have stated numerous times before, I am OS-agnostic, believing in the best tool for the job]
I humbly disagree. I have reviewed both my Eneterprise and Select agreements. For all intents and purposes, I own them. There are restrictions, but they can't take it back (unless I violate the restrictions).
Regardinng upgrade treadmills, nobody forces you to upgrade. I have seen figures that estimate that >40% of all Eurpoean corporate seats are still NT 4.0. When was that released? 1995? 1996? Something like that. I can attest that my company's European subsidiary is still running ~500 NT 4.0 seats and we are the market leader in our segment. We will upgrade this year to, guess what? Win2k. How many people (percentages) are still running their flavor of the version of linux that was released circa 95-96? How about since 2000?
Incompatible file formats? Modulo Access, Office has been compatible from 97-XP and, to my recollection, has always been forwadly compatible.
Open Source is no saint when it comes to backward comptability either. There's no commercial requirement to do so. If it's too hard, or gets in the way of killer new functionality, the hell with backwards comptability.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
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.
-- $G
Projects shouldn't fork, we shouldn't have multiple options.
We should have 1 computer chip, 1 OS, 1 web browser, 1 car, 1 political party.
Choice just causes confusion and waste.
Forking is just one way Open Source gives you more choice. You simply can not make your own modifications and improvements to most closed source software.
Open source excels at the individual level - we are free to do what we want. But for many of us - the issue is also about sustainability. A project with too many forks is less likely to create a critical mass of contributors, necessary to keep the fork alive. A project with too few forks may actually stifle innovation. Management of the huge projects (apache, linux kernel) have managed forking while keeping innovation alive. Less huge projects (KDE, Gnome) have enough critical mass to be sustainable and more freedom within the desktop forks. Something from my group would die if it forked - die from starvation of ideas and loss of critical mass of ideas and energy.
I can't understand why someone from Hebrew University couldn't see the wisdom of self-determination as a primordial human right and its applicablity to open source. Of course, I don't understand a lot of things going on in Israel.
Seastead this.
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.
I've always seen Forking as something of a blessing... it's the abandoned projects are the ones that are in danger.
Forking leads directly to abandoned projects as it dilutes the number of developers willing to work on each fork.
At my last job, the corp. security group wanted a solution that could manage users on a few thousand servers (NT and mostly *nix). What started off as a simple project turned into this huge system (running on Windows, ACK!)that every user would have to go through to get to any network element. So a technician using a terminal for a Sun box (Netra T1120) about two feet away, would have to go through a central-computer buried in a bunker thousands of miles away. Nevermind that something similar had been tried and died twice before.
Without getting bogged in details, my point is that I agree with Marvin that many times an inferior project with a lot of "yes" men (and women) behind it are actually much more of a threat than forking.
I love the analogies to forking = captialism (and evolution). I hadn't thought of it that way, but it's completely true. Just think if no one had come up with an alternative to RedHat's Linux, and now they've walked away from the consumers. My next *nix install will either be Solaris 8 for Intel (cuz I just cant let it go...its my fix) or FreeBSD.
John
this whole topic of discussion has piqued my interest ever since i started this semester with my basic econimics class. basic economics says that competition is a good thing (for the consumers), and that if left alone, the supply and demand model will drive the creation of products pretty efficiently. also in our basic models and graphs of supply and demand in work, price is what unifies the supply graph and the demand graph. this is kind of where the system gets skewed in the OSS world, because there really is no dollar price with OSS, because the value that OSS developers get from supplying product isnt measured in dollars.
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."
--- Nothing clever here: move along now...
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!"
With, what 190 + versions?
The lack of a unified GNU/Linux is what Microsoft will beat GNU/Linux with, just like Microsoft beat Unix with the last time. (you know, back in the 1980-1990's when Microsoft said "Unix was dead")
Since the end users have no monetary connection with the open source developers, why is there any reason why an open souce project mission critical to a given business will be supported in the long term?
Don't parrot the BS about it being open source, you can modify the code to fit your needs since it assumes that any end user critically dependant on the software would have the time, money, development talent or management talent to undertake modifying the open source code.
Most end users are not C/C++/Perl/Python/Ada/Fortran programmers.
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."
-Looking for a job as a materials chemist or multivariat
Wow, a professor who represents an organization for Market Studies says open source software is bad? I never would have guessed.
you just do s/forking/features/g to the article, and it all makes sense!
Let's say you have a problem with talking to certain kinds of hardware so you start writing drivers for them. Someone else notices your project and writes some other compatible drivers that plug in to it. Then another shows up, and another, and pretty soon you have the makings of a classic free software program.
Time passes and you're pretty happy because you've solved the original problem and managed to do the same for others at the same time. Then someone else comes along and wants to add a bunch of things that you don't need, but ultimately will have to maintain if they disappear a year later. This is when forks are good. Let them go off and prove themselves in a sandbox.
Now's when you may have to let go. If the new project becomes good enough that it takes off and eclipses the original, you should look at it to see if it still solves your original problem. If it does, the obvious answer is to start using their software. Bingo - you now have a solution, and you're also free to do other things. Let them run the show for awhile and see how it goes.
The trick is that you have to be willing to give up your project in a sense. You have to be able to admit to yourself (and potentially others) that you were really trying to solve a problem and not be the next free software project pseudo-deity.
If the parties involved can stick to the actual problems and stay away from the vanity, they might see that a fork can be beneficial for all.
...wheres the article?!!!
There's no link to an article in the story!
SURELY NOT!!!!!
That forking annoying SCO and forking scumbag Daryl McBride.
XP is the opposite of a fork: it's the merging of all the 95/98/ME functionality into the NT/2000 codebase.
survival of the fittest
This depends on what market you're talking about. Consumer market, yes. You're probably right.
But the consumer market is a small piece of the software pie. Most software that is written out there is custom business software and enterprise software. And I believe this is who the article mainly aimed at.
If there is a 'proprietary tool' out there that is essential to the operation of a business, you can bet someone will support it for as long as you're willing to pay them to do so. This is why many organizations are still using (and updating) COBOL programs originally written back in the mid-70s, among others. The reasons behind this are many.
A fork though can potentially force them into an upgrade path they don't want to take.
-
Sounds kinda of like that same thing that happens in religon. :)
One Dorks Search for Spiritual Guidance in the Digital Age
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.
Yes, to many here Software is far more important.
Write an article about anything and get it posted on Slashdot. Next up: why ass wiping is standard, and should the process involve project management.
Since this professor is from Isreal, I suppose he would similarly choose to argue that the ability to "fork" the torah is also bad for Judiasm?!
Actually while taken in a humorous context, there is a lot to compare between the modern practice of free software and the practice of the torah, including the ability to modify and create new works which others may then freely modify further, etc...in fact, many of the parellels are quite striking.
But since he claims to be a professor of economics; in a true open market, if demand is unhappy with the supplier, they are free to choose another supplier; a fork is simply the instanciation of multiple suppliers and likely came to exist because there is some unmet demand from the mainline branch. This represents market efficiency, not extra cost.
There's yet another type of forking that can occur which I call "forking up". This is where a small but important module is developed by someone who needs it, and the module later gets adopted into a project with broader scope and larger visibility. This is in fact the norm when projects submit code for inclusion into the standard distribution of Python or Perl. If Python adopts the module, sometimes independent development on it dies, but many times it does not--pybsddb and pyxml are two examples that spring to mind. Other projects do this as well... Twisted and Zope both get a lot of contributions from smaller projects that want to be part of a larger effort.
This is yet another case that supports parent's argument that resources are not being divided.. resources that work on fixing bugs in the higher-visibility project would never have worked on the smaller project's codebase at all. The smaller project can still benefit from porting bugfixes in stdlib over to their tree.
Everybody wins.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Yes, if you only look at the effect on the projects themselves (that is, the software developers involved). But what about the users of the projects?
At best, a Fork means that a project's users have to understand some technical (or political) differences that caused the Fork, and pick one project or another. At worst, they have to stick with an unsupported version of the software, or convert all their old files to some new format, or something equally unappealing.
As a software developer, I'm all for the idea that forking is software evolution in action, better projects survive and less viable ones die out, etc., etc. But that doesn't mean we can ignore the fact that Forking causes (or can cause) extra work and potential loss of investment to users who may not be able to afford it.
1.I've found forking to be fun!
2.How often does a coder get a chance to "fork"?
3.Forking is like programming... make one mistake -- oh, never mind.
4.A fork is a terrible thing to waste.
5.Forking for fun and profit.
6.1.Fork
6.2.???
6.3.{Profit||Baby}!!!
Emacs: for people who just never know when to
Perhaps you didn't catch the sarcasm. Check the parent to my post. I should have quoted it.
Not everything is analogous to cars. Car analogies rarely work.
This is just dumb. If there are different forks, it does not matter. Yeah, what's with having a dinner fork, salad fork, desert fork, etc. My mom would have killed me if I got that much silverware dirty for one meal.
That's why the invinted the spork!
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.
...
'Hi, I'm Joe Random Interface Expert and I would like to point out how your project is horribly designed from a UI perspective. You need to make changes A to Z.'
Response: 'Code it yourself.'
Result:
So it takes a bit of organization beyond the self-organization to get something done outside the medium (code). Without a specially focused effort on this area, it is not a problem that will really resolve itself.
+&x
They aren't looking for choice as much as they are products that work and are easy to use. While Linux is getting better, its not there yet. At least with Windows, there is no shortage of people that know how to use it. Try explaining the difference between Mozilla and Netscape to these people. They don't care, all they want is a browser and they'll read about how some block pop-ups ads and will say, "Get me one of those".
We use SQL-Ledger for our company accounting, however we have the IT staff that understands PostgreSQL and Unix server along with PERL. Joe's Hobbies down the street doesn't and Simply Accounting or QuickBooks works for them.
Now we have sucessfully coverted several offices from Windows to Macintosh. Why? Its easy to use, it has a lot of commerical support from many software and hardware vendors, and it has SMB critical applications like Quickbooks ported to the system. Now, I have three contracts for after the beginning of the year to help businesses switch to OpenOffice. Once they discovered it will meet the basic needs, word processor and spreadsheet, and the presentation portition looks almost exactly like PowerPoint 2000, they loved the it and the price.
In the server world, its a different story. Typically datacenters and server admins will support what ever will work the best for them, even if it is a btich to set up. If fork x does better than y, great. Also, their managers and bosses don't care so long as it works.
Generally speaking, forking is one of the major reason I use FreeBSD over Linux. I like how the organization, as elitest as it may be, works. There are how many differnet distros of linux and how many FreeBSD's again. When we write software, it may work on SuSE and RH, but not slackware. When we write an application for FreeBSD, chances are its going work unless the admin has tweaked the hell out of the system.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Forking is part of everything I hate about open source. I hate the forking bugs, I hate the forking users, I hate the forking beards, I hate the whole forking thing!
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.
You're lucky. Most companies don't offer escrow agreements and most that end up having escrow agreements with companies largely don't have them with companies such as Microsoft. While it's an answer, it's not QUITE as good as Open/Free Software- it's nowhere near the same thing.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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".
The grass is only greener, if you don't take care of your own lawn.
Forking happens all the time in the proprietary world -- it just doesn't look exactly the same. If it didn't happen, then consumers would have no choice. We'd all still be using Visi-calc and driving Model-Ts.
In addition, what's more common in the proprietary world is reverse forking (merger) -- far more troublesome for software consumers.
dada
I can count the number of significant projects that have forked on one hand and still have a finger free for Darl McBride. Sure, forking happens all of the damn time with silly stuff like MP3 players and web-based BBS software, but aside from the BSDs, when was the last time you heard of a significant infrastructure project forking?
Only the gcc/egcs split comes to mind, but the two were folded back into one tree and the result was a better compiler. There's the StarOffice/OpenOffice split, but that's also largely collaborative. Most other forks are dead ends that wither away quietly, no matter how loud and vociferous the original argument was.
This is just more Microsoft FUD coming from one of the most Microsoft-saturated countries on the planet.
Proud member of the Weirdo-American community.
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.
I didn't even start on NT for PowerPC, Alpha and MIPS or Windows 64 or the various platforms for CE.
The fact of the matter is that Microsoft has frequently forked the Windows code base to make it more attractive to different market segments. Some of these branches have been left to die off. (What is the upgrade path for someone running NT on MIPS?) Some of these branches have been kept current. In a few cases, seperate branches have been bolted together to take the best features from both.
You cite an example where a comercial package was "forked" by maintaining an older version. This seems to have nothing at all to do with free software. Some questions that need to be answered are:
Lacking answers to questions like that, there's no way to evaluate your specific case. From here, it's no justification for the implied statement, "free software does not work in the enterprise market".
If free software is not working for you, you are doing something wrong. There's a wealth of free software available to do any task. These can be used by anyone without having to share back, if you are so inclined, but are most powerful when you can identify a community of users who may also benefit with you. What's more, there are now many consultants who are willing to do the work for you. From IBM to the local linux dude, the thing you ask for is what you get. Because most of it can be done without an onsite visit, you literally have the whole world of developers to chose from. For instance, Duck Central is now being programmed by a Russian. There's way more talent on the market than there is demand and the loser is going to be the high priced comercial software solution.
Duck Central is a duck hunting web site. It was built by rubes in Baton Rouge using free and open software. It's fiercly competitive and widely recoginized as the best of it's kind. It has all the pieces of the "enterprise" and could not be a more custom application. If they can do it, anyone can even your PhD supervisor at Schroders Bank.
Congratulations to Ellen for her new boat. Arrrr!
Friends don't help friends install M$ junk.
However, when an OS project forks, the original coders risk losing their credit.
Sure, their credit is supposed to remain in the source code, but not necessarily so in the running GUI.
So, even though forked projects presumably keep the original coders' credits in the source, they typically remove it from the running interface.
And it's the credit in the running GUI that most people will ever be exposed to.
Here's what I do: Bitty Browser & Andromeda
Even if some of the people are antagonistic towards others, the CODE is still Open.
So what if the two leaders hate each other. That just leaves room for a third leader to step in and combine the other two projects. All that matters is that someone is interested enough to continue the work.
. . . having a product being bought out. Anyone use Erwin? That thing's been sold a couple of times and every time it gets a facelift and very little value added. At least with a fork, the "original" will keep going and you have a CHOICE! Jeff
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.
The number of resources, particularly human resources,
that an organization is able to use is necessarily bounded,
at some point.
Sometimes too many cooks spoil the broth,
and this is especially true in design processes.
So if you have company A and B, each with 500 employees,
sometimes it's not true that an imaginary company C resulting
from the merger of A and B creates a better product because
there are more amployees working on the same problem.
The reason for a merger is often that by eliminating
competition you could easily enforce higher prices
on the market WITHOUT having to improve your production.
So, in the end, there IS a waste of resources but
is really in the interest of evolution of the product,
because it allows to explore possibilities using
resources that you couldn't use in many other ways.
I would say that the problem with the capitalistic
way of production is not really the waste of resources,
but the inefficiency that comes from things like
long lasting patents, closed source, industrial secrets,
because it FORCES designers to reinvent the same wheel
many times, instead of leaving them the CHOICE of
reinventing the wheel AFTER having a good look at
the existing wheels.
We learn from history that we learn nothing from history - Tom Veneziano
Dude, I totally read that headline as,
"fucking is good, but rarely happens".
This accurately describes my sex life.
A Google Search provides 13,000 hits, with hoary Rothschild references. They claim $160,000,000,000 managed assests, but is the kind of thing really big dumb companies eat for breakfast. Like any other big dumb company Schroders has a bunch of overpaid executives but this one's tast in boats makes Jim Clark's look rational. Shiver me timbers!
Friends don't help friends install M$ junk.
...CRAP
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
One only needs to look to MS Visio, Project, Visual Studio, Word and other major application to see feature/function "forking" which makes the "new" software uncompatible with previous releases.
The Proprietary vs Open Source argument doesn't work here.
To develop windows, microsoft had a group that worked on the current code (maint) and another groupwork on what became Windows 3.x. Repeat for the 95/95 version, and the NT leadership came mainly from outside (cutler et al). It's part of evolution of software (and meat).
OpenBSD: A NetBSD developer, arguably with some interaction issues, was unsatisfied with NetBSD's pace towards heightened security. And spun of (forked) OpenBSD. Since then, ALL the BSDs have benefited from the heavy code audits, just as OpenBSD has benefited from work in Free and NetBSD.
Got an interesting idea and some resources to pursue it? You fork (usually via CVS) and work on it. It works, it fails, it leads to another interesting way to do it. It's worked out. Then the main fork either integrates it, or is left in maintainance mode in favor of this new path.
This is how software is developed commercially, in-house (eg. not for sale) and in open source.
The problem? You may commit to using a dead end.
In the real world, I know of the cabinet of dead software where one vendor bought another and killed the software we were using (OpenVision's HA, several billion others).
I know folks using Windows 98 because it works for them and does what they need and they can't upgrade without sucking up HUGE other costs of repurchasing their software again.
It *is* a risk. However it's not inherent only to open source.
Do I go with Linux, which might fork, or choose something else? If I go with Linux, I do not know if someone will fork it next year. How will I know which fork to switch to when it happens? I need to know that my applications will be unchanging and static.
Therefore I'm going to stick with Windows 98, which I know will always be there until the end of time...
</sarcasm>
Don't blame me, I didn't vote for either of them!
Here is a good essay that was originaly posted at LinuxCare (I think) :
Fear of ForkingThe problem is that it is not abandoned projects that get forked, it's any project that doesn't please the mob. Democratic rule is not for all projects, and committee design is not always better.
In the early days of Linux, there wasn't as much disregard for the developers who came before (especially if they are still maintaining their project). Imagine if a new group had forked the Linux kernel in late '92, and each of those projects were forked a couple months later, and so on. We'd have a bunch of really weak, unfinished, incompatible kernels.
You guys are all missing the point. The point is not to say that OpenSource is bad. The point is not to say that forking for open-source is bad. The point is about answerability.
A small firm would be more interested in a long-term easy-to-use solution, which will not be rendered useless due to the fancy of some extremely zealous geek.
Success of Intel with the x86 architecture stands as testimony to the importance of "backward compatibility".
The question is whether open source can guarantee that the work spent using it will not be rendered useless.
If there are different forks, it does not matter. A company will pick one that does what they require and they provides good support from an organization they trust.
In my experience, what often happens is: A company (i.e., a small group within the company) picks an app that does most of what they need, with the expectation of having the missing parts Real Soon Now.
With proprietary software, getting the missing parts means trying to persuade the vendor to implement them. This can take a long time, unless you have a LOT of money as a persuader.
With open-source software, all you need is a few programmers. They do their own fork, to get the features that the company needs. If you don't have a programming staff, you can contract it out. In any case, you end up with your own version of the software that does what you want.
If you sell it, the GPL will require that you share your extensions with the world. But, contrary to what the theorists seem to think, I've found that managers hardly ever have objections to this. All you have to do is mention the possibility that some user will spot a problem and fix it themselves.
So I submit the changes to the keepers of the open source -- and in most cases, they are rejected on the grounds that they are too specific to that one company's situation. Or only some of the changes are accepted. In either case, the company still has its own "fork" with added features that are specific to its needs.
This is all based on the idea that a company either has its own programming staff, or contracts out the job as needed. This is quite common, and getting to be more so as the entire world goes computerized and networked.
We could discuss whether such things are truly cases of "forking". They are usually more like small side branches. But it's the way things often work. And it works best with open source.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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.
I agree. Take, for example, the number of forks from Judeaism. Now could this contribute to some of Dr. Sauer's anti-forking bias?
Dear Slashdot Moderators,
Please control our friendly neighborhood neo-nazi's from posting their hate messages here.
This poor neanderthal (above thread) actually thinks tiny, economically ravaged Israel is close to some sort of world domination.
Thanks.
------ The best brain training is now totally free : )
The article in question is Open question. The government claims open-source software means a 60% saving. It doesn't add up. Dr. Robert M. Sauer has a homepage if you are interested in finding out more about his other work.
Uh, no they're not. They may use window managers, but they aren't window managers.
"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."
Neither of these is a fork of the other.
"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."
More man hours == tighter code. At least that part is funny.
And I think the article makes a strong point.
Afterwards we had a cigarette (and really had no desire to write OS software).
------ The best brain training is now totally free : )
Must be well rounded being a Doctor and and Economist.
Forking is not bad, particularly if it allows features to see the light of day that might otherwise have been suppressed. In such an environment the largest group of people can be completely satisfied (both those who forked, and those who did not fork).
Open Source is about dynamism - the ebb and flow of designs through an ecosystem of software. Some die, some gain small niches where they live for many years, and some become 'killer apps' - used by all.
The key is for Businesses and Governments who are considering, or are in the process of moving to Open Source to engage integrators who will steer them through that ecosystem - to locate the tools they need to do the job, and more importantly, choose based on the level of risk they are willing to accept, given such considerations as disaster recovery, and in-house skill sets for maintaining and upgrading software that could be abandoned.
Of course, that is no different than what they have to deal with from proprietary vendors anyway (if Microsoft desides to end-of-life Windows NT, there is not much you can do about it - oh wait - they already did that. At least with Open Source you have the option of maintaining the software yourself if such a thing comes to pass [I haven't heard about Microsoft releasing NT sources yet...and I won't hold my breath]).
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Forking Hell!
.
They will never know the simple pleasure of a monkey knife fight
How can I RTFA if there's no link to it?
As if OpenSource has a problem with forking. Let's look at MS (I know, like shooting fish in a barrel):
Win2k Professional
Win2k Server
Win2k ENterprise Edition
Win2k Data Center
WinXP Home edition
WinXP Professional
Win2003 Server.
Sql Server Desktop
Sql Server Standard
Sql Server ENterprise Edition
All with various incompatibilites built in (can you say 'planned obselesence'?). And this is the short list! MS is an easy target but I am sure that we could find other companies who gratutiously 'fork' versions to pump up sales. The Good Doctor is either ignorant or totally being unbalanced.
putting the 'B' in LGBTQ+
"Dr. Forking is extremely healthy"
The good news is that even if our dear doctor gets sick and can't work on his open source project anymore -- other developers can take over the project.
I don't think Dr. Forking's health is really that big a thread to open source, since it's so easy for others to take over. Now if it were commercial software, it might hvae been harder.
Software companies just call the forks alphas or betas or in Microsoft's case Windows 3.0, 3.1 Windows 95, Windows 98, Windows 98 SE, WIndows NT, Windows ME, Windows 2000 etc...etc...etc...
Forking is not deriable, but has its advataches (using licenses like GPL).
What happens if a company goes out of business?
That does not happend with OS, and if forking ocurrs (not desirable, but if it happens), the worst think that can happen is that you will have more choices. In the log run one or more of the branches will continue and you continue with them.
Unlike religion, when you merge several forks of an open source project effectively, you steal all the followers. Contrast this with religion -- somehow this doesn't seem to have worked for the Unitarians
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Right, that's the stock answer, but the reality is that putting together a team to continue development along the prior path is difficult. A theoretical one-man development team would not be able to realistically pull this off.
So when businesses balk at using open-source because of fork potential, telling them that some mystery guy could always come along and carry on the software they use isn't compelling.
Ultimately, the more ways you fraction a community working toward a given goal, the more wheel-reinventing you get, and the less overall progress is made. To a degree, having the same general problem answered in different and interesting ways can be healthy, but when you have a large group of people who depend on the development of a particular piece of software, and development of that software basically dies because two factions of the team can't get along, that's not good. While you and I can theoretically step in and maintain the old project, the chances that we will be able to make progress like the original, united team is remote.
That's why, if I were recommending software for serious business use, I would use software that is stable and established enough that 1) it either won't fork or could easily survive one, or 2) that we can maintain in house.
-Looking for a job as a materials chemist or multivariat
Regardinng upgrade treadmills, nobody forces you to upgrade.
What if the version you are still using (e.g. Windows 98) is no longer available and you have to install a newer version on new computers? I can imagine an organisation with lots of computers wanting to standardise on one OS, web server, or other piece of software.
Incompatible file formats? Modulo Access, Office has been compatible from 97-XP and, to my recollection, has always been forwadly compatible.
My understanding is that Office is often backwards compatible (can read files generated by older versions), but less often forwards compatible (can read files generated by newer versions).
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
XEmacs or GnuEmacs?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Anybody who does not believe that forking happens in the internal development of closed-source is totally ignorant of the corporate software development process. I have worked at several large compainies and in no cases was the code I worked on not a fork. I would estimate there were 3 or 4 simultaneous forks at all times. In the end one would probably be selected and 3/4 of the work people did was lost. Sometimes it would fork and diverge into totally incompatable products for different platforms, or for "professional" versus "personal" use.
OK, let us establish some facts;
1- Open source will have unforeseen costs (support costs, retraining, or just plain training)
2- So will closed source (Forced upgrades, support costs, training, maybe even retraining)
3-The unforeseen costs for open source will obviously cost more then the software (since it was free)
4-The unforeseen costs for closed source MAY cost more then the software
None of this is news; running software takes money, and the cost you pay for running open source software will be a LOT higher then it's install cost, because it's so cheap to install (there is an install cost because you'll have to pay your IT guy to set it up, or use some of your time to do so yourself).
Tonnes of these articles go over how the 'hidden costs' of open source will cost more then the closed source software, but they rarely compare what the 'hidden costs' of the closed source software.
I'd like to see a comparison of the 'hidden costs' of a closed source package vs an open source package in two comparable divisions of the same company over a 5 year period, but even that wouldn't settle anything, because the technology keeps changing. If I had to hazard a guess though, I'd imagine that the costs of closed source with it's forced paid upgrades outweighs open source which has all the same 'hidden costs' save that one.
Note: support costs include the time wasted contacting free tech support- Frankly if your getting paid $20/hr as a computer tech to fix a problem in an Intergraph product (they do have good free tech support when you buy there very very expensive product), and need to spend a long time on hold: that's company money spent on support. If it's cheaper to pay "OPENSCADA" (made up name) or some other open source program's support fees to get a tech to log on via VNC every now and again to fix the problem; then even though you have to pay for OPENSCADA support and not for Intergraph, it still cost you less for support because your tech didn't have to wait on hold for 2 hours and then have to go through the very same steps the OPENCAD guy did on your machine via remote with 2 hours less time spent.
-Millions of Monkeys, Millions of typewriters, 6 hours of sorting through faeces encrusted pages to find: This post
You won't have the same number of people working on each branch as there was prior to the fork, since the team is split. Hence, there won't be as much progress made in a given time frame as there would be if there was no fork. Ergo, why use Open Source if it just allows headaches down the road anyway? Proprietary software at least is driven by customer demand, not developer preferences.
And who said linux was easy to use? Guess according to you we should all use Windows or Macs because linux is not as easy to use, right? Photoshop is pretty easy to use if you learn it, but it ain't no Mac Paint if that's what you're looking for.
"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.
While many people try to fork projects, those forks only become significant if they fulfill some need. Otherwise, the forked project won't attract the necessary developer base and they will slowly go away.
Forking is an essential part of open source development and it is what gives it strength. Forking protects projects against decisions by the developers that are in their commercial interests but against the interests of users. And forking protects projects against corporate stupidity.
As an example, consider Sun Java. If it was open sourced, it would fork in an instance into a bunch of different, incompatible versions. But the only the best of those versions would survive and become the de-facto standard, and it would almost certainly not be Sun's version. The fact that Java is proprietary means that Sun can keep following blind alleys, no matter what the market actually wants.
The ability to fork is the whole point of open source. It results in lower TCO in the long run because it ensure that systems can always improve and that systems are built in response to the needs of users. You can't have perfect backwards compatibility and innovation--it is logically impossible. OSS gives you exactly the tradeoff between the two that is good for users.
In different words, Sauer just doesn't understand open source.
I'm not sure I understand the problem here.
Is there some problem with maintaining control over the 2.6 kernel?
Has Larry Wall failed to keep control on the perl versions?
Is there some ambiguity in choosing a PHP upgrade path?
Can somebody tell me what the problem is here?
Our company has done somthing similar with a CRM product.
I think the real point to take away is that:
Commercial software forks in an unhealthy way, when a customer needs something the main company will not or cannot provide, leading to division.
OS projects fork only when the people involved feel so passonate about an issue, that the only resolution is two versions. Having two groups feeling so passionate about a project means that it is most likley very healthy indeed.
I can't even think of a project that had a major fork and then had both branches die as a result. Whereas a company taking on too much custom development of any commercial software faces as uphill battle as the people of the company only use it because it's there and the commercial vendor goes whichever way they will. They can't even steal from each other!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I agree totally. While forking does contribute to a slight sparsity of developers, think of all the projects that have had a fork and are still going strong in parallel to what forked (NetBSD and OpenBSD). Sometimes, the forked project becomes the one from which it forked (Python's IDLE). Sometimes, the originator will die off (Linux Router Project), and sometimes, the fork will die (does anyone really care about Zynot?), but more often than not, they will coexist (think {e,x,a}mule). Forking really isn't all that bad, anyway. Given enough information, users will actually appreciate the wide array of choices.
one great band, Uncle Tupelo, forked into two great bands--Son Volt and Wilco. Forking is good. QED.
Stupid people make stupid things profitable.
When people have deep disagreements, companies and dev teams can split, and the leavers go off and found new companies. Fairchild to Intel. Cisco to Juniper. So why does this is Good Thing in business become a bad thing in Open Source world?
And how do we, the consumers, know when the leading lights of a closed-source program development team leave? We don't, so we get newer versions of ever decreasing quality. People don't work on the same products all their lives.
The problem with forking is that the developer pool is not unlimited. There are a couple possible outcomes of the a project forking:
First, both projects go on to be successful. In this case, the number of developers on each project will effectively be halved, making both projects suffer. Admitedly, both projects may gain more users in total over both projects than with a single project, but the number of developers on a single project will not be as high, and will suffer slightly. Odds are the people that leave a project due to some conflict of opinion are passionate developers with strong knowledge of the project--very valuable in the open source world--leaving fewer power-developers on each project.
Second, one of the projects dies. In this case, the developers from the project that dies will most likely be turned off on the idea of the project and will most likely do work elsewhere than join the other project on which development continues. Leaving fewer developers in the pool.
Now, I'm not saying that forking is a bad idea, rather it's not a win-win situation. By forking, you're choosing choice over absolute progess.
Where is that verse in Luke? (I shouldn't have bought a "slightly defective" Bible).
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
in soviet russia professors knew what they were talking about...
Herr Blockwart, bitte rufen sie die SS und fuehren sie diesen Volksschaedling der Sonderbehandlung zu.
Deutsche, kauft nicht beim Juden!
"Fear of Forking essay"a w/forkin g.html
http://linuxmafia.com/faq/Licensing_and_L
Rick Moen writes about how forking is rare, but beneficial when it occurs.
Just have to thank's someone.
You say that like it's a bad thing, but it ain't necessarily so: see The Mythical Man Month, etc. In some cases, having a smaller number of developers with a more concentrated idea of where they're going can be more effective.
Often when projects fork they don't directly compete, but rather one of them is going to be more adventurous (e.g. samba-tng) or have different priorities (e.g. OpenBSD). Doing that can produce much better outcomes than trying to hold everything under one umbrella.
Now, I'm not saying that forking is a bad idea, rather it's not a win-win situation.
You seem to be assuming that forking is something that unruly hackers do, but it's generally not. Forks happen when there are unreconcilable (not necessarily hostile) differences about how the project ought to proceed.
The only way to avoid having differences is serious groupthink by the developers, therefore probably ignoring opportunities.
In cases where the fork happened for silly reasons (typically with younger hackers), then it's no great loss, because they might not have achieved much anyhow. Probably they would have wasted a lot of time arguing if they'd stayed in.
Progress is not an absolute. It is a vector; it has direction and magnitude. Having more progress in a direction which doesn't suit some of the users or developers is not a good thing.
There is plenty enough unpredictability in commercial products and support to render his contention invalid. I have a number of stories and experiences with this myself, and I'll bet many of you do, too.
Can anyone say Zebra? Which is not maintained actively (make that at all) anymore because the main 'developer' is working on a commercial variation called ZebOS.
;)
But fortunately after almost a year of quarrelling we now have the PJ fork called Quagga or mirrored at quagga.ch. So long for official GNU projects
http://unfix.org
Thanks