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?
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.
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
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 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
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
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.
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.
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)
How is unix/linux behind Windows? The way I see it, it's way ahead of Windows in nearly all areas.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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
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
It's a dodgy analogy.. but what the hell:
Like the a**hole Galileo who wanted to go his way and say that the earth went round the sun, instead of helping fix the bugs in the current theory...
Btw, have a look at: this
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.
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.
... 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.
...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.
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.
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.
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!
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)
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.
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
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'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
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.
Pay your people writing open source code and they won't fork it (or rather, if they do, you can fire them). If you want people to work for you for free, you have to accept the fact that they might want to do their own thing with the code.
All's true that is mistrusted
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!"
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
Very true. Thats why I said "Corporate software" as opposed to "closed source". There are some open source projects that are being financed by corporations. A more appropriate title for the article would be ["Forking" Greatest Danger of Adopting Distributed Development?] Distributed development also has some advantages that compensate for this drawback that outweights the risks in my opinion. But I mostly agree with writer on this item.
The price of freedom is eternal vigilance.
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.
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.
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.
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.
...CRAP
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
The pope demanded that Galileo present the opposing argument (Copernican theory) in his treatise, as it was favored by the vatican. Galileo did this, but used the voice of a character called idiota. The pope took offense at this, and imprisoned Galileo.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
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.
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