>...an article puts the abandonment rate of open source projects on Github at about 98% - meaning that there is no activity on 98% of projects after a year [0]. This has coined a phrase - abandonware.
I'm not a programmer, I'm a researcher. Let me tell you a fact: about 100% of research articles are not updated.
Somehow the link [0] cited in the article makes an indirect similar point, but what's wrong with programs which are not updated? After all there is a (small) group of people who keep telling that programs are the next level in mathematics, (ideally they are) better than proofs.
Moreover he's using the large amount of wreckage to argue that the Darwinian process of selecting "category killers" isn't working, which is completely backwards.
If "category killer" is a winner-take-all competition, then there are going to be a vast number of losers, and we do see a vast number of unmaintained projects. It's just that no one is bothering to remove them from view when they're defeated.
I'm unaware that the goal of evolution is to have one lion win the lion competition and eat all other lions.
Maybe we should stop using bad metaphors? Writing software is not a Darwinian process, neither is competition on the market place. Unless you got your OS by randomly twiddling bits in the binary file, in which case why are we even talking about open source?
> have one lion win the lion competition and eat all other lions
If that improved the chances of that lion's genes surviving, it would absolutely be selected for. Obviously it generally doesn't because there's safety in numbers, etc.
> the goal of evolution
Minor nit: evolution has no goal. It is undirected, random, capricious, etc.
Which is an important advantage to open-source. Abandoned, failed close-source software is almost never available. Talk about wasted productivity... If an abandoned github repo has any redeemable value, it will get found and used.
Constructive proofs are equivalent to programs. But until somebody writes the program, there are always details, context, style, etc which make a proof understandable by a human but not a program. A program is more rigorous than a proof, in this sense.
The concept does need some qualification. “Small software” can probably become “done.” Grep, as an example, is done. Frameworks, libraries, and applications all have a steering wheel requirement of support.
I’d suggest that a fair amount of github open source is resume padding, or at least an attempt at it rather than “scratching a developer’s itch” which the original ESR paper mentioned as a reason.
I suspect most software is overdone, I was looking at Node Express the other day and it struck me they should have stopped when promises and async/await came along and moved on to another project.
Are there any numbers on closed source projects to compare this with? Say, if closed source projects have a 99% abandonment rate, what do these numbers tell us?
I agree. There are plenty of good points to consider in the article, but this is not one of them. Lots and lots of things on Github are little experiments that someone tried out and made available so that others can benefit from what they learned or tried. That can be called 'abandonware' in order to reinforce a straw man, or it could also be called a source of community learning.
>Somehow the link [0] cited in the article makes an indirect similar point, but what's wrong with programs which are not updated?
Bit rot, for one (not keeping up with changing OSes, APIs they talk to, environments, libs they use, security concerns, etc), but also the fact that when they stopped updating they were still incomplete and more often than not half arsed.
Not to mention that abandoned github repos wind up in google searches and I have learned something from looking at them in such a context, even if untouched for years.
Don't delete your repos because they are "old". You could be doing a favor for some random person with a google search, looking at something you looked at too.
Lots of proprietary software are abandoned & unmaintained on old storage devices, the statistic about abandoned software on Github is meaningless.
On quality: quality is very suggestive. Quality changes if you factor in questions such as: Does it run well on low-end devices, does it track you, will it still open your files in 10 years, will the company still exist in 10 years, does it work well on many platforms, can it be automated, etc.
there's a lot of nits to pick about this essay, but the real punchline is that corporations have reaped the profits from open source software, far more than any developers do directly, and that claim seems hard to dispute.
I can't argue with this assertion. Can we start discussing how to correct this a bit. I have no issue with corporations reaping profits from open source software but would love to see more developers benefiting directly.
I think a lot of people have reaped the benefits of open source software. And corporations are formed of people.
It is a check and balance on proprietary software, in quality, cost, privacy and independence.
It has benefitted developers directly, in education, in transferrence of skills to other employers, and in direct customization of software for their personal needs.
The problem is with the distribution of benefits. Much like the vaulted Lebensraum the question is who gets the land and who gets to be fertilizer for the land.
So far the answer to the first is Bezos, and to the second is everyone who isn't Bezos. A distribution that leaves something to be desired of.
Utter nonsense. There are many people getting great benefit from Amazon other than bezos. Including many of people employed there and the many investors that have reaped benefit from the stock increase.
Yep, he's just torpedoing his own credibility with shit-nuggets like :
> What the world does not need is another buggy open source copy of Windows Media Player.
Is this supposed to refer to VLC ?!?
(Admittedly that one is not in in the current version of his "manifesto".)
- Somehow using GitHub as an example that Darwinian competition doesn't work.
- Retconning the term "abandonware"
- The tired (and wrong) argument equating counterfeiting to theft. (No wonder that he thinks that mindshare is unrelated to making money !)
> Instead [F(L)OSS] produced a graveyard of dead software; the largest sink of wasted human labour in history - bigger than even the Mao's Great Leap Forward or the Stalin's building of the White Sea Canal.
And after all of this, he has the gall to call F(L)OSS proponent "Zealots" !
"Why do you look at the speck of sawdust in your brother's eye and pay no attention to the plank in your own eye?"
I have like 30 projects on github, I don't expect any of them to really go anywhere, it's just where I put stuff when I'm playing with a new concept.
There are ~3 projects that I would have actually have liked to go somewhere, real projects not toys, that I have abandoned.
So that "98% of projects" statistic is fair, but I think those numbers would be looking a lot better if you accounted for the fact that github is just a place to throw stuff up. Just because something is on github doesn't mean it's an open source "project".
It seems like a silly metric. Almost all code gets abandoned, and at an alarming rate. Unless you happened to build a popular database or an operating system component, it’s likely that your code is gone in 10 years. And if not, your code is likely the future bane of some developer who despises maintaining it since it is such a bear to update to their unforeseeable requirements.
> I have like 30 projects on github, I don't expect any of them to really go anywhere, it's just where I put stuff when I'm playing with a new concept.
Then why put it there?
git works fine without github. And by putting your projects on github all you did was add to the baseline white noise that people have to filter through.
My view is different from the person you're answering to, but - on an actual open-source based website that hasn't been bought by a closed-source transnational corporation ?
The facts as presented by this article do not match the facts I remember. I'm an old fart and was actually alive and active writing software at that time.
The cathedral and the bazaar was not a book, it was an essay. They apparently later turned it into a book but I know nobody who read the book. The essay, in contrast, was read by everybody in the scene.
Here's how I remember it.
Open source has no specific meaning before esr claimed it.
And after he claimed it, crucially, open source did not mean you could not charge for the software.
I practice almost no source code was released under non-liberal licenses, but there are some notable exceptions. For example, Microsoft released the source code of the Windows kernel for research use to universities. AFAIK that technically means Windows is open source.
esr was not against releasing source code under non-liberal licenses. He was just convinced those would not stand a chance against code released under liberal licenses. Time has proven him right, I would say.
Also this article misses the point, I think. Open source was not meant to define or enshrine a methodology. It was coined because at the time people felt that the free software movement was holding itself back in the fight against Microsoft (google "halloween documents" to get more insight into esr's struggle against Microsoft) because it sounded like you could not make money with it. Also because the GNU General Public License said if you make changes to a piece of GPL code, the result must also be under the GPL. So in a sense GPL actually did impede commercial exploitation of free software.
At the time many libertarians (like esr) felt that the market would solve this if you just let it, and software is not the place to fight ideological wars about the freedom of software.
I'm just paraphrasing the arguments here as I understood them. Personally I come down on the pro-GPL side of the aisle.
Before personal computers, wasn't free/open software the default because there wasn't a mass market for software? I think I've been told something like that by someone of an older generation.
A main point of this seems to be that most projects on github are abandoned.
What a stupid comparison. That would be like listing all the commercial projects that go out of bussiness, or dont even progress far enough to get funding in the first place, and saying closed source model is a failure because most closed source projects fail.
He is the inventor of the Qi (later Shen) language (essentially a Lisp dialect with a configurable type system). He experimented with taking it open source. He was very underwhelmed by the results and has made later revisions closed source again. In particular as far as I can tell he felt he was losing creative control of the project and getting little to nothing back for it in terms of contributions and features (and in general very unimpressed with people's reaction to the language and the wider programming community's capability of understanding the language).
> This is the time when reddit made an appearance. I blessed the Shen subreddit because I thought that reddit was some polite ladies bookclub - obviously showing my ignorance of it. It is nothing of the sort of course and some of its most vicious sites like Coontown - the reddit for racists only recently closed - shows what is so often like. Reddit is a shit hole; and to a lesser degree so are SlashDot, and Hacker News.
> Unfortunately some members of the Shen group, imbibing the mindshare poison, gave much power away to the opinions on reddit.
> The OS fanatics relished their power to bully and shame and people used to mail me and say 'You need to say something because XYZ has said such and such on reddit'. I did on occasion call such people 'complete prats', but really this was whack-a-mole because the supply of arseholes was unending.
"No mathematical theorem, no enjoyable novel, no work of art of any importance, have ever been produced by a herd. I fail to see why innovative software ought to play by a different set of rules."
Nobody tell this guy about Bourbaki... He's also probably never enjoyed a movie.
A novel also is produced by a “herd”. There are a lot of people involved. People that make suggestions, corrections, the editor... It’s not a single person effort.
Naked Came the Stranger was written, not just produced, by a herd, to massive success. (It was intended to fail, and the herd writing was an element of that intention, but none of that stopped it from experiencing massive success.)
See also: Atlanta Nights, another sort of "successful failure" group-written project meant to demonstrate that an alleged "publisher" was really a vanity press with no actual standards or editorial process. You can now buy the book via various links from the official website of the "author" [1], but in case you're in need of a few giggles right this minute, the submitted manuscript was also released by one of the conspirators [2].
The single person is the one who does the conception and creation.
That proof-readers, editors, etc work on it too is inconsequential.
TFA didn't say more than one person can't contribute something or work an artistic project. It said that one or a very few people have the direction and the overall command and vision -- e.g. the opposite of "community process" or "design by committee".
However, you can still read a novel the same after someone else makes corrections or add things, even if the new things are not good.
Software can become complete broken by a bad patch.
That is seen the best at security issues. Like someone thinks it is a good idea to add a heartbeat extension to ssl. A basically pointless extension, if you have a novel with a pointless appendix from an editor, basically no one would read the appendix and it does not matter that it is there. But with software it ruins the entire server security completely
It is better to pass on 100 good patches than risking one bad patch
Well, to be fair, a textbook is not a theorem or an enjoyable novel... Also, a movie is not made by a “herd” (unless one thinks of a company as a herd.) Wikipedia would be a better example.
The Elements of Mathematics volumes weren't exactly textbooks and contained novel proofs. Also, the Bourbaki group published some papers containing novel theorems. For example:
Bourbaki were certainly made up of a collection of leading mathematicians, but the works of Bourbaki are not innovations themselves. As much as I love the books, they do not contain major new results, rather they are an excellent organisation of pre-existing knowledge, perhaps with some novel proofs.
I guess Terry Tao would be a good example of collaborative mathematics? He was mentioned in another thread and I noticed the following while reading his wiki page:
> Within the field of mathematics, Tao is known for his collaboration with Ben J. Green of Oxford University; together they proved the Green–Tao theorem. Known for his collaborative mindset, by 2006, Tao had worked with over 30 others in his discoveries,[15] reaching 68 co-authors by October 2015.
The Bible has something like 40 authors. It would probably be classified as a "work of art of importance", even if you don't classify it as anything more than that.
I would say of course, there is art to be found in it, but as a whole, it's obviously not a work of art simply because it's a bunch of unrelated and overlapping pieces, with arbitrary parts removed via historical accident, no matter how much people try to claim otherwise.
The Bible is a collection of many different texts; that is why it has many authors. While it can be evaluated as the whole collection, I think that each book of the Bible can be evaluated by its own, too. Actually, the book of Genesis does seem to come from multiple sources; also, it is believed that parts of the Gospels come from the Q Gospel, so even then there are different authors adding stuff within a single book.
First they said there was just one God, and the Bible contains "His" words. Then it turned out there were actually three, and one of them is edible and tastes just like crackers and wine. Now you're telling me there are 40? JFC, get your story straight, Christians!
Movies are also team work only in the sense of many people working under the vision of a single person: the director. But that's also true for any system designed by 1-2-3 people where 100s also work on.
Not all open source software is produced by a "herd"; many are written by one person.
My own projects I write by myself; often there are no other contributors at all (although I do accept bug reports and sometimes accept contributed code too, I am the only maintainer).
SQLite is a good open source software project (there are some proprietary extensions, but the core system is open source, and there are also open source extensions which are as good as the proprietary ones if you do not need the warranties and professional support they provide), and is written by only three people. Still, the commit history is public and I often look to see what changes they will have in the next version (and in one case, even found a bug and reported it, and they quickly corrected it).
I have heard Bourbaki before but didn't know much about that, but now I look it up and I can see what it is. I did not know that Bourbaki is actually a group of mathematicians, but I looked and now I know. I also did not know that the "dangerous bend" sign used by Knuth was invented by Bourbaki.
> In fact an article puts the abandonment rate of open source projects on Github at about 98% - meaning that there is no activity on 98% of projects after a year. This has coined a phrase - abandonware.
That's factually incorrect. The term "abandonware" dates back to the 90s (long before github) and was originally used to describe software that was predominantly proprietary. Virtually all proprietary software ever written has become abandoned or will eventually become abandoned, but I guess that fact doesn't really square with what the author wants to say.
I've put some code I wrote up on GitHub. Why did I do it?
1. As a learning experience, how does GitHub work?
2. As advertisement for myself as software developer
3. As a check on myself, is the software good
enough for others to use. When you do something
publicly "on stage" it better be good. Not
only good in terms of "code quality" but in
terms of "does it do something useful?".
So I think I've got some benefits from publishing my code as open source. Not financially, like the corporations.
I think the world is still waiting for a better monetizing model for opens source, as well as for component-software in general. As things go Cloud, I think such a model will eventually if not soon emerge.
On the article, I found this to the point:
"The truth revealed that OpenSSL was seriously underfinanced with only one full time operative working on a code base of hundreds of thousands of lines of C."
HackerNews is open source, right? We share our ideas free of charge here. I'm not even aware of the copyright if any that applies to postings here. And we do it for fun, not for profit. But does it a great book make? Does it even make a magazine?
So I think the point of the article is that while Open Source has its uses, it is not and as far as we can see never will be a wholesale replacement for commercial software.
I think he covers that a bit discussing Red Hat and other OS successes, and goes on to say "There's a larger group of not-so-harmless people than the givers who are driven by greed for free stuff and a sense of entitlement"
This article seems to leave out why open-source changed it's meaning from "source available" to "source shared". That results from the FSF, GNU, copyleft and the rise of Linux.
⌘-F show only two references to GNU or Stallman, both derogatory references to Emacs. All references to Linux are about how early versions sucked and how it was a "copy" of Unix.
This highlights a lack of understanding from the author which may explain a lot of the viewpoints.
> There's a larger group of not-so-harmless people than the givers who are driven by greed for free stuff and a sense of entitlement. We can call these the takers. Takers are generally abusive if their entitlement is challenged; because to criticise the open source model is to take away their intellectual candy and the result is a tantrum. Amongst this larger group are a smaller group of DRM crackers and pirates. In nearly all open source projects, they outnumber the givers. Michael 'Monty' Widenius, an open source advocate, acknowledges the problem.
> Help create a generation of takers that believed that all code should be open source and embraced open source as a religion. Online bullying of dissent began in forums. A large number of believers then traded 'code' for 'digitisable media' and the most active of those went in for DRM cracking and piracy.
Judging by the comments so far, I think he struck a nerve.
You can definitely filter out the worst customers by raising prices, the bottom of any market is usually a cesspit. I suspect the very top is as well although I haven't any experience of that.
Unfinished experiments that aspire(d) to be something relevant are more like vaporware, not abandonware. I'd argue the vast majority of what's on github is this or dirty hacks that never warranted any further development or maintenance.
There's actually substantial value in access to such things. Rather than repeating the experiments yourself, you can go see where they led others without investing the time and energy to repeat the effort. If you find something that mostly resembles what you would have made, can get along with the license, and still wish to move forward - huzzah, a jump starting fork is born.
Abandonware IMHO is more appropriately applied to examples like Google's ever growing list of abandoned projects that actually had users, where the world noticed the abandonment of something useful.
That is a good point. Sometimes the code is useful even if it is incomplete. (I have sometimes done such things, taking parts of other programs; more often, I write most of the code myself, but some of it will come from other sources like that. As an example, I found the source code for a JPEG encoder, and modified it to improve the compression and other things. There are many other such cases too.)
> In 1990 when you said a program was 'open source', you meant that you could read the source code; the actual code the person had written to create the program.
Citation needed. I don't think people were saying "open source" in 1990. FSF/GNU had the term "free software" for longer but they had to explain it on every first use. (Probably still do to an extent.)
It sounds like this guy has some sort of axe to grind, but he's wrong. His argument rests on the claim that "most open source code is poor or unusable."
When most people refer to Open Source Software, they're referring to serious projects like the Linux kernel, Apache, PostreSQL, Firefox, etc. They're not referring to random crap on Github.
The serious projects are actually better than their closed-source counterparts, both in quality, and in their ability to be extended and customized. Customization is not going to be cheap or easy, but it will at least be possible.
The fact that I wrote a toy renderer in Rust five years ago and haven't touched it since then doesn't change this. The fact that there are 100 or 1000 times as many toy projects as there are serious projects doesn't change this either.
Ironically, he anticipated this objection, which many people beyond the parent poster are making, and answered it in the paragraph that contains:
"... Open source users will admit that a lot of open source is buggy abandonware. However they argue that this really does not matter since some small significant fraction is really quite good and that's the stuff we should use. ..."
Finding and dissecting the paragraph that contains the above sentence is left as an exercise to the reader.
As far as I can tell, he makes a weak argument by analogy
> This lesser-known fact is masked by the isolated points fallacy. The isolated points fallacy consists in taking the high scoring points on a graph and plotting your line on the basis of them. Hence open source champions wheel out the standard examples of success - Open Office, Wordpress and Red Hat Linux (we'll look at why some of these have succeeded later) - ignoring the vast sea of floating half submerged buggy and abandoned projects (over 120,000) that litter Github. It is the sort of technique Mugabe would have used for TV. If you're accused of starving the country, wheel out a handful of well nourished kids for people to see. 'Look, our country is fine; see how healthy these kids are'. Out in the slums the less fortunate die of cholera.
I don't buy his argument and I think he's confused. Lots of people have released code on github (as have I) so that other people can use it. Lots of it isn't used, so it looks abandoned. Maybe it is. So what? Why is that considered a failure of Open Source?
I think he's applying closed source's rules. A closed source project is a failure if no one uses (ie, buys) it, since it represents a development cost that wasn't compensated. Not so with open source. I don't suffer if no one uses my project, and the existence of my repositories doesn't detract from anyone else's work.
I agree completely. I meant I expect many people have watched closed source projects die before they're released or be abandoned after release, but that is harder to measure in aggregate because it's much less likely to be seen.
So the author is wrong to compare all software on Github to closed source software he's heard about. Those "measurements" are completely different.
His point remains reasonable, though: If all you did was dump the resulting artifacts of a learning or self-edification exercise online, you didn't make a product like a Firefox or MySQL. And to the extent that people use your code, it's most likely as part of a similar journey to yours, and studying that code is not hugely different from studying books and whitepapers, even if the code is easier to leverage. But people were doing this before "open source" became a thing, and in a manner more befitting the role of such code: as part of a text file documenting the core concepts and posted on a BBS or Usenet, so that you could program the same thing. It's the kind of thing that would be a blogpost now. The actual code? Usually only the really deep, underlying algorithms need that spelled out.
It's only when you make a full system that the end user can get value out of that you get into the scenario he outlines. Somewhere in the middle in between the simple code dump and Firefox, open source tends to sink into a quagmire where it looks like a product but it's not supported like a product. And the only good answers then seem to be "go small" (impose LOC limits and hard constraints on features you ship so that maintenance drifts towards stability) or "commoditize" (become part of someone's product in a way that gets you paid).
Except he's arguing the fact that there's a bunch of useless code on Github means open source is bad. I argue that for the purpose of comparing the results of open and closed source development it's reasonable to restrict to software with a real user base.
> A closed source project is a failure if no one uses (ie, buys) it,
I don't think this is true. The vast majority of closed source programs are created in house for in house use. No one is ever offered it publicly so no one buys it either.
It's hard for people to see the scale though because there is usually no central repository.
Is there any special reason to believe that closed source is any better? If we can count the sea of abandonware on Github, then we get to count the mountain of "interesting" code that remains internal to large companies, or worse, the stuff that actually got released on unsuspecting customers.
Generally, a business pays developers to write software that it expects to be put to immediate use, which means that most of the time it functions, at least minimally. I'm sure exceptions exist, of course.
I'm not just being contrary, I've worked on a project for a year or two that got scrapped, and I think it happens a lot.
Another way to look at it, is that if you have programmers that are regular employees and not temps or something, you might as well have them work on something that's not very important, or that's risky, when you don't have something better for them to do, because you're paying them anyway.
I’m convinced if they stopped paying us all to rewrite things that work the market would fall out from under us.
Every job I’ve ever been involved with has always had some code base that was in framework X and now needs to be in framework Y, or on in house hardware and needs to move to the cloud, etc etc.
And having just interviewed every place has a project like that. “We were using PHP for the mvp but are moving to RoR”, “We were using class based react but now we’re using hooks”, etc etc.
I feel half of it is valuable migrations and half of it is to always have something on our plates.
And it always has to get done yesterday. What a world.
Most software engineers I know love to build software for the sake of itself. They are not all that interested in the business. Most businesses for which software is being produced is not personally relatable or interesting to most software engineers.
To keep engineers motivated, the work has to have sufficient amount technical accomplishments and not just churning out business features.
Luckily, due to continuous growth in market and scale of users, and improvements in hardware, there is opportunity for serious amount of technical work in any project.
Also, faster time to market is of real business value. Compromises are done in ideal perfect designs to meet timelines (or resource constraints) – hence, tech debt occurs and it is real and just as useful as financial debt to help scale a business in a competing marketplace.
And speculative/iterative market feedback based development is also real. All these things add up to one thing – things that were right for yesterday isn't right for tomorrow.
So we have to rewrite or refactor software continuously. And that's perfectly normal. It is actually one of the biggest strengths of software based solutions – that we can change things live - while it is already in use - change the engines of the rocket while it is flying - so to speak. We have to embrace this and leverage it disruptively.
Those who pine for perfect software are denying realities of the larger real-world.
My first six months of employment at my current job consisted of going from one project to another that the C-levels listed as "a top priority for the company"--like, called all-hands meetings and told everyone about this great thing and how important the people working on it were--and then decided to cancel.
Two years later, that still happens from time to time.
So, from my point of view, it looks much more like businesses pay developers to write software to be thrown away. Which I guess is fine with me, as long as my paycheck keeps coming....
Yes. But they give me a regular paycheck and extremely generous vacation and sick days, and nobody else I've interviewed with or been contacted by recruiters for can match those benefits... so I stay. At least until my RSUs vest.
Nope. I work for a major corporation that owns its own entire office building for headquarters and operates in over 30 states.
None of those projects contributed to still being around 2 years later, but one of them (if simulations based on prior years' data are assumed to be reasonably accurate) would've improved revenue on one of our sales channels by approximately 30% if it had actually been put into production....
Closed-source crap is better because it's not available to the world, so millions of developers don't waste time exploring it and finding out that it's unusable.
Those things I agree with it. The good open-source programs mostly are better than other programs in these ways.
Yes there will be many badly written programs (I think someone said that 90% of anything will be not very good), but there is good stuff too. I think it may be the case even with the closed sources, but in that case they are unavailable so we will not have any statistics about it.
The author is wrong on innovation as well usability. One of his arguments is summarized as follows:
> [Open source] did not reward innovation. The most successful products of open source are knockoffs of old ideas; Linux included.
So what about Spark? What about Python numpy, pandas, and scikit-learn? Most people don't just use them because they are open source. They are innovative solutions to difficult problems.
> The fact that I wrote a toy renderer in Rust five years ago and haven't touched it since then doesn't change this.
I ask you in good faith...if you pushed this to a public github repo that was your reasoning? If it was something I found to be of value and you'd LICENSE'd it under a promiscuous license and I took that code and made a few million dollars from your idea (and kept all the money), would you be happy with that?
Was this just a thing to show potential employers you can code and use git, how does an employer even know actually you wrote that code?
> they're referring to serious projects like the Linux kernel, Apache, PostreSQL, Firefox, etc.
I feel you're missing the point here, not all the contributors to these projects are getting paid for their efforts. See his point about Linux Torvalds comment about:
This model of using people was acknowledged right from the beginning with a sly wink to Linus Torvalds from Eric S. Raymond in The Cathedral and the Bazaar.
Eric S. Raymond: "In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: “I’m basically a very lazy person who likes to get credit for things other people actually do."
I’m saying nothing for or against the rest of the article, but this one sentence does not describe software as I know it: “But above all this is the sheer waste of human effort in terms of the production of rotting software in repositories.”
The act of writing code changes the programmer. I have written many things that didn’t turn into successful open source, nor did they act as resume-ware. But the act of writing them taught me something.
There is no waste of human effort involved when you practice your craft. This is like telling me that if I climb a cliff and then lower myself back to the ground, I haven’t gone anywhere.
Right now I’m working on implementing a subset of regular expressions that compile to finite-state recognizers. There is a zero-percent chance that my working code will be used in production.
So what? I am learning something about pattern-matching, and perhaps it will grow into a little language like SNOBOL.
> But above all this is the sheer waste of human effort in terms of the production of rotting software in repositories.
Yup, what about the amount of human effort that has been wasted in the course of producing off-the-shelf proprietary software? How much of that proprietary stuff is now entirely useless, for some reason or another? It's just so weird to make an engineering-focused argument for proprietary stuff, when the only case that's even remotely plausible is about production incentives, and everything else hugely favors FLOSS.
As an aside, I'm pretty sure that, in the medium-to-long run, we'll manage to fund FLOSS development to an entirely satisfactory extent via crowdfunding, and that while saving a lot of dough compared to what it would take to fund proprietary development in the same way.
But in fact, even his point about support revenues is misguided. Well-designed and easy-to-use software does not really draw fewer paid-support arrangements than software that's hackish, unintuitive and the like. The nees for paid support is almost entirely an organizational one, so it matters zilch how easy the software is to support in reality; it's far more important that the organization can point to that support contract if any such need should arise.
I am not really responding to the article, but to the general concept of the Cathedral and the Bazarr.
The main problem is this: in sufficiently complex programs, roughly associated with LOC, there becomes a point where there are no longer enough eyes on enough pieces of code.
Therefore, I propose that the future of FOSS in the Bazarr style is to focus on reducing code complexity and increase readability as much as possible.
“It’s not the daily increase but daily decrease. Hack away at the unessential.” - Bruce Lee
He should’ve counted the impacts of the open source software instead of the number of it.
Does he think Apache web server with million or billions usage the same as one random open source software he found on GitHub and less than hundreds usage?
Further, If he counts all of OSS on github and or sourceforge, he should’ve counted all crappy and abandoned closed software buried in any corporate office.
The article is wrong in attributing "open source" to Eric Raymond alone. As it's now used, it was apparently coined by Christine Patterson and mutually agreed to at a meeting where Eric Raymond was present in February 5, 1998. [1]
According to the release history, "The Cathedral and the Bazaar" was written in 1997, but originally used the term "free software". The term was changed to "open source" on February 9th. [2]
> There's a larger group of not-so-harmless people than the givers who are driven by greed for free stuff and a sense of entitlement. We can call these the takers. Takers are generally abusive if their entitlement is challenged; because to criticise the open source model is to take away their intellectual candy and the result is a tantrum. Amongst this larger group are a smaller group of DRM crackers and pirates. In nearly all open source projects, they outnumber the givers.
What an absurd dichotomy. Even if you work full time on open source, you probably can't be a major contributor to more than a handful of large projects, at most; many people specialize in just one. But you probably use dozens to hundreds of open source programs. So for any project with a modicum of popularity, of course the number of people who use the software without contributing dwarfs the number of contributors. That would be true even if everyone worked full time on open source.
Admittedly, the OP's definition of "takers" is not just "people who use without contributing", but tacks on some ad hominem insults to supposedly qualify it. The result has very little resemblance to reality. Sure, there will always be some people who become truly abusive if a project makes a change they don't like. But they're definitely a minority. Most people, facing such a situation, don't speak up at all; they might be annoyed, but they keep it to themselves. Others do speak up, but know how to be polite about it. Perhaps the OP assumes that people should not voice negative opinions at all, if they're not contributing to a given project. I disagree. A good default assumption is that open source maintainers are open to polite and well-reasoned negative feedback. A maintainer can always forbid such feedback in official project forums if they so choose; if they do, users should respect it, but it's is not a very gracious move.
And what the heck do DRM cracking and piracy have to do with anything? In my experience, those people – whom I respect – form communities which are oriented around piracy, and pretty separate from the open source world. In part this is because the nature of the work they do is different; reverse engineering is different from software development, and many pirates do neither of those, but just use existing tools to distribute pirated copies of whatever type of media they're fans of (e.g. anime). I'd say they're also more likely (compared to programmers as a whole) to use cracked proprietary software instead of open source. Of course, this is a massive overgeneralization, but the point is that bringing them up makes no sense.
"However the problem is that the open source user may not stumble on this magical fraction and the invisible iceberg of buggy, ill-conceived open source lies submerged ... open source uses massive amounts of user time trawling through defunct and buggy applications and posting to forums ..." Regardless of what you are looking for (open source computer programs, closed source computer programs, television shows, books, etc) some won't be so good, or might be difference what you need for your use, and so they have reviews about such thing.
"An awful lot of popular open source is inferior reverse-engineered copies of existing commercial software (Gimp, OpenOffice etc)." Is Gimp a reverse-engineered copy of existing software? Just because it is similar to some proprietary software does not necessarily mean that it is a "reverse-engineered copy" of it. OpenOffice presumably involves the reverse-engineered formats of Microsoft Office, although now there is LibreOffice. Both Microsoft Office and LibreOffice each have some features the other lacks. What is "inferior" may also depend on your opinion, because in some cases it isn't so clear, and in some cases it may be inferior in some ways but superior in others.
"If open source programmers do innovate and their innovation is good then its just as likely to be swept away from them by the corporations who have the capital to exploit it." In my experience that doesn't always happen. Many features first implemented in GNU/Linux systems are things that they did not implement similar features in Windows until much later.
"... the Linux desktop still lags behind Windows and the interface looks stuck in the 90s." Actually, I think both in Linux and Windows many programs try to be too fancy, but in Linux I can change the window manager and all of that stuff easily and still works. I uninstalled the desktop environment, and I think it works much better than Windows ever did, actually.
"Good software is properly documented, does not break and does not require hand-holding to use it." True, but that isn't the issue; the issue is customizing it.
129 comments
[ 0.24 ms ] story [ 268 ms ] threadI'm not a programmer, I'm a researcher. Let me tell you a fact: about 100% of research articles are not updated.
Somehow the link [0] cited in the article makes an indirect similar point, but what's wrong with programs which are not updated? After all there is a (small) group of people who keep telling that programs are the next level in mathematics, (ideally they are) better than proofs.
[0] https://www.techrepublic.com/article/open-source-failure-is-...
If "category killer" is a winner-take-all competition, then there are going to be a vast number of losers, and we do see a vast number of unmaintained projects. It's just that no one is bothering to remove them from view when they're defeated.
Maybe we should stop using bad metaphors? Writing software is not a Darwinian process, neither is competition on the market place. Unless you got your OS by randomly twiddling bits in the binary file, in which case why are we even talking about open source?
If that improved the chances of that lion's genes surviving, it would absolutely be selected for. Obviously it generally doesn't because there's safety in numbers, etc.
> the goal of evolution
Minor nit: evolution has no goal. It is undirected, random, capricious, etc.
I’d suggest that a fair amount of github open source is resume padding, or at least an attempt at it rather than “scratching a developer’s itch” which the original ESR paper mentioned as a reason.
Huh. "Abandonware" is a very old word as far as internet culture goes, referring to something entirely different.
The same abandonment happens within healthy corporations with proprietary source code.
Bit rot, for one (not keeping up with changing OSes, APIs they talk to, environments, libs they use, security concerns, etc), but also the fact that when they stopped updating they were still incomplete and more often than not half arsed.
Don't delete your repos because they are "old". You could be doing a favor for some random person with a google search, looking at something you looked at too.
On quality: quality is very suggestive. Quality changes if you factor in questions such as: Does it run well on low-end devices, does it track you, will it still open your files in 10 years, will the company still exist in 10 years, does it work well on many platforms, can it be automated, etc.
It is a check and balance on proprietary software, in quality, cost, privacy and independence.
It has benefitted developers directly, in education, in transferrence of skills to other employers, and in direct customization of software for their personal needs.
So was the Nazi party.
The problem is with the distribution of benefits. Much like the vaulted Lebensraum the question is who gets the land and who gets to be fertilizer for the land.
So far the answer to the first is Bezos, and to the second is everyone who isn't Bezos. A distribution that leaves something to be desired of.
https://www.google.com/search?q=amazon+warehouse+workers
> What the world does not need is another buggy open source copy of Windows Media Player.
Is this supposed to refer to VLC ?!? (Admittedly that one is not in in the current version of his "manifesto".)
- Somehow using GitHub as an example that Darwinian competition doesn't work.
- Retconning the term "abandonware"
- The tired (and wrong) argument equating counterfeiting to theft. (No wonder that he thinks that mindshare is unrelated to making money !)
> Instead [F(L)OSS] produced a graveyard of dead software; the largest sink of wasted human labour in history - bigger than even the Mao's Great Leap Forward or the Stalin's building of the White Sea Canal.
And after all of this, he has the gall to call F(L)OSS proponent "Zealots" !
"Why do you look at the speck of sawdust in your brother's eye and pay no attention to the plank in your own eye?"
There are ~3 projects that I would have actually have liked to go somewhere, real projects not toys, that I have abandoned.
So that "98% of projects" statistic is fair, but I think those numbers would be looking a lot better if you accounted for the fact that github is just a place to throw stuff up. Just because something is on github doesn't mean it's an open source "project".
Then why put it there?
git works fine without github. And by putting your projects on github all you did was add to the baseline white noise that people have to filter through.
The cathedral and the bazaar was not a book, it was an essay. They apparently later turned it into a book but I know nobody who read the book. The essay, in contrast, was read by everybody in the scene.
Here's how I remember it.
Open source has no specific meaning before esr claimed it. And after he claimed it, crucially, open source did not mean you could not charge for the software.
I practice almost no source code was released under non-liberal licenses, but there are some notable exceptions. For example, Microsoft released the source code of the Windows kernel for research use to universities. AFAIK that technically means Windows is open source.
esr was not against releasing source code under non-liberal licenses. He was just convinced those would not stand a chance against code released under liberal licenses. Time has proven him right, I would say.
Also this article misses the point, I think. Open source was not meant to define or enshrine a methodology. It was coined because at the time people felt that the free software movement was holding itself back in the fight against Microsoft (google "halloween documents" to get more insight into esr's struggle against Microsoft) because it sounded like you could not make money with it. Also because the GNU General Public License said if you make changes to a piece of GPL code, the result must also be under the GPL. So in a sense GPL actually did impede commercial exploitation of free software.
At the time many libertarians (like esr) felt that the market would solve this if you just let it, and software is not the place to fight ideological wars about the freedom of software.
I'm just paraphrasing the arguments here as I understood them. Personally I come down on the pro-GPL side of the aisle.
What a stupid comparison. That would be like listing all the commercial projects that go out of bussiness, or dont even progress far enough to get funding in the first place, and saying closed source model is a failure because most closed source projects fail.
The author is very critical of open source on the whole. He has a series of articles detailing criticisms of open source software.
http://marktarver.com/problems.html (The Problems of Open Source) http://marktarver.com/open.html (In Praise of Closed Source)
He is the inventor of the Qi (later Shen) language (essentially a Lisp dialect with a configurable type system). He experimented with taking it open source. He was very underwhelmed by the results and has made later revisions closed source again. In particular as far as I can tell he felt he was losing creative control of the project and getting little to nothing back for it in terms of contributions and features (and in general very unimpressed with people's reaction to the language and the wider programming community's capability of understanding the language).
He has also had at least one argument on Reddit about this (see the post by Mark_Tarver here https://www.reddit.com/r/programming/comments/57h33q/arguing...).
This is one article in a long series of events and thoughts for him that have played out over the past decade.
https://groups.google.com/forum/#!forum/qilang
in case you are interested in learning how bad chi will influence your dealings with Shen, or Qi, or ..
If we're going to say that X is wrong because Y said it, well Stallman is an albatross around the neck of everyone who talks about free software.
https://news.ycombinator.com/newsguidelines.html
> This is the time when reddit made an appearance. I blessed the Shen subreddit because I thought that reddit was some polite ladies bookclub - obviously showing my ignorance of it. It is nothing of the sort of course and some of its most vicious sites like Coontown - the reddit for racists only recently closed - shows what is so often like. Reddit is a shit hole; and to a lesser degree so are SlashDot, and Hacker News.
> Unfortunately some members of the Shen group, imbibing the mindshare poison, gave much power away to the opinions on reddit.
> The OS fanatics relished their power to bully and shame and people used to mail me and say 'You need to say something because XYZ has said such and such on reddit'. I did on occasion call such people 'complete prats', but really this was whack-a-mole because the supply of arseholes was unending.
Nobody tell this guy about Bourbaki... He's also probably never enjoyed a movie.
[1] http://www.travistea.com/
[2] https://web.archive.org/web/20050305143929/http://www.cs.du....
That proof-readers, editors, etc work on it too is inconsequential.
TFA didn't say more than one person can't contribute something or work an artistic project. It said that one or a very few people have the direction and the overall command and vision -- e.g. the opposite of "community process" or "design by committee".
Software can become complete broken by a bad patch.
That is seen the best at security issues. Like someone thinks it is a good idea to add a heartbeat extension to ssl. A basically pointless extension, if you have a novel with a pointless appendix from an editor, basically no one would read the appendix and it does not matter that it is there. But with software it ruins the entire server security completely
It is better to pass on 100 good patches than risking one bad patch
https://en.wikipedia.org/wiki/Bourbaki%E2%80%93Witt_theorem
It's a no true Scotsman argument.
> Within the field of mathematics, Tao is known for his collaboration with Ben J. Green of Oxford University; together they proved the Green–Tao theorem. Known for his collaborative mindset, by 2006, Tao had worked with over 30 others in his discoveries,[15] reaching 68 co-authors by October 2015.
Movies are also team work only in the sense of many people working under the vision of a single person: the director. But that's also true for any system designed by 1-2-3 people where 100s also work on.
My own projects I write by myself; often there are no other contributors at all (although I do accept bug reports and sometimes accept contributed code too, I am the only maintainer).
SQLite is a good open source software project (there are some proprietary extensions, but the core system is open source, and there are also open source extensions which are as good as the proprietary ones if you do not need the warranties and professional support they provide), and is written by only three people. Still, the commit history is public and I often look to see what changes they will have in the next version (and in one case, even found a bug and reported it, and they quickly corrected it).
I have heard Bourbaki before but didn't know much about that, but now I look it up and I can see what it is. I did not know that Bourbaki is actually a group of mathematicians, but I looked and now I know. I also did not know that the "dangerous bend" sign used by Knuth was invented by Bourbaki.
That's factually incorrect. The term "abandonware" dates back to the 90s (long before github) and was originally used to describe software that was predominantly proprietary. Virtually all proprietary software ever written has become abandoned or will eventually become abandoned, but I guess that fact doesn't really square with what the author wants to say.
1. As a learning experience, how does GitHub work?
2. As advertisement for myself as software developer
3. As a check on myself, is the software good enough for others to use. When you do something publicly "on stage" it better be good. Not only good in terms of "code quality" but in terms of "does it do something useful?".
So I think I've got some benefits from publishing my code as open source. Not financially, like the corporations.
I think the world is still waiting for a better monetizing model for opens source, as well as for component-software in general. As things go Cloud, I think such a model will eventually if not soon emerge.
On the article, I found this to the point:
"The truth revealed that OpenSSL was seriously underfinanced with only one full time operative working on a code base of hundreds of thousands of lines of C."
4. Breaking down that barrier of perfectionism that prevents you from publishing or finding worth in your creations.
So I think the point of the article is that while Open Source has its uses, it is not and as far as we can see never will be a wholesale replacement for commercial software.
⌘-F show only two references to GNU or Stallman, both derogatory references to Emacs. All references to Linux are about how early versions sucked and how it was a "copy" of Unix.
This highlights a lack of understanding from the author which may explain a lot of the viewpoints.
> Help create a generation of takers that believed that all code should be open source and embraced open source as a religion. Online bullying of dissent began in forums. A large number of believers then traded 'code' for 'digitisable media' and the most active of those went in for DRM cracking and piracy.
Judging by the comments so far, I think he struck a nerve.
There's actually substantial value in access to such things. Rather than repeating the experiments yourself, you can go see where they led others without investing the time and energy to repeat the effort. If you find something that mostly resembles what you would have made, can get along with the license, and still wish to move forward - huzzah, a jump starting fork is born.
Abandonware IMHO is more appropriately applied to examples like Google's ever growing list of abandoned projects that actually had users, where the world noticed the abandonment of something useful.
Citation needed. I don't think people were saying "open source" in 1990. FSF/GNU had the term "free software" for longer but they had to explain it on every first use. (Probably still do to an extent.)
When most people refer to Open Source Software, they're referring to serious projects like the Linux kernel, Apache, PostreSQL, Firefox, etc. They're not referring to random crap on Github.
The serious projects are actually better than their closed-source counterparts, both in quality, and in their ability to be extended and customized. Customization is not going to be cheap or easy, but it will at least be possible.
The fact that I wrote a toy renderer in Rust five years ago and haven't touched it since then doesn't change this. The fact that there are 100 or 1000 times as many toy projects as there are serious projects doesn't change this either.
"... Open source users will admit that a lot of open source is buggy abandonware. However they argue that this really does not matter since some small significant fraction is really quite good and that's the stuff we should use. ..."
Finding and dissecting the paragraph that contains the above sentence is left as an exercise to the reader.
> This lesser-known fact is masked by the isolated points fallacy. The isolated points fallacy consists in taking the high scoring points on a graph and plotting your line on the basis of them. Hence open source champions wheel out the standard examples of success - Open Office, Wordpress and Red Hat Linux (we'll look at why some of these have succeeded later) - ignoring the vast sea of floating half submerged buggy and abandoned projects (over 120,000) that litter Github. It is the sort of technique Mugabe would have used for TV. If you're accused of starving the country, wheel out a handful of well nourished kids for people to see. 'Look, our country is fine; see how healthy these kids are'. Out in the slums the less fortunate die of cholera.
I think he's applying closed source's rules. A closed source project is a failure if no one uses (ie, buys) it, since it represents a development cost that wasn't compensated. Not so with open source. I don't suffer if no one uses my project, and the existence of my repositories doesn't detract from anyone else's work.
Also, I'm sure everyone's seen a closed source project that went nowhere?
So the author is wrong to compare all software on Github to closed source software he's heard about. Those "measurements" are completely different.
It's only when you make a full system that the end user can get value out of that you get into the scenario he outlines. Somewhere in the middle in between the simple code dump and Firefox, open source tends to sink into a quagmire where it looks like a product but it's not supported like a product. And the only good answers then seem to be "go small" (impose LOC limits and hard constraints on features you ship so that maintenance drifts towards stability) or "commoditize" (become part of someone's product in a way that gets you paid).
I don't think this is true. The vast majority of closed source programs are created in house for in house use. No one is ever offered it publicly so no one buys it either.
It's hard for people to see the scale though because there is usually no central repository.
Is there any special reason to believe that closed source is any better? If we can count the sea of abandonware on Github, then we get to count the mountain of "interesting" code that remains internal to large companies, or worse, the stuff that actually got released on unsuspecting customers.
FLOSS abandonware has no such constraint.
I'm not just being contrary, I've worked on a project for a year or two that got scrapped, and I think it happens a lot.
Another way to look at it, is that if you have programmers that are regular employees and not temps or something, you might as well have them work on something that's not very important, or that's risky, when you don't have something better for them to do, because you're paying them anyway.
Every job I’ve ever been involved with has always had some code base that was in framework X and now needs to be in framework Y, or on in house hardware and needs to move to the cloud, etc etc.
And having just interviewed every place has a project like that. “We were using PHP for the mvp but are moving to RoR”, “We were using class based react but now we’re using hooks”, etc etc.
I feel half of it is valuable migrations and half of it is to always have something on our plates.
And it always has to get done yesterday. What a world.
To keep engineers motivated, the work has to have sufficient amount technical accomplishments and not just churning out business features.
Luckily, due to continuous growth in market and scale of users, and improvements in hardware, there is opportunity for serious amount of technical work in any project.
Also, faster time to market is of real business value. Compromises are done in ideal perfect designs to meet timelines (or resource constraints) – hence, tech debt occurs and it is real and just as useful as financial debt to help scale a business in a competing marketplace.
And speculative/iterative market feedback based development is also real. All these things add up to one thing – things that were right for yesterday isn't right for tomorrow.
So we have to rewrite or refactor software continuously. And that's perfectly normal. It is actually one of the biggest strengths of software based solutions – that we can change things live - while it is already in use - change the engines of the rocket while it is flying - so to speak. We have to embrace this and leverage it disruptively.
Those who pine for perfect software are denying realities of the larger real-world.
Two years later, that still happens from time to time.
So, from my point of view, it looks much more like businesses pay developers to write software to be thrown away. Which I guess is fine with me, as long as my paycheck keeps coming....
If this is the case, did any of those projects contribute to you guys still being around now, two years later?
None of those projects contributed to still being around 2 years later, but one of them (if simulations based on prior years' data are assumed to be reasonably accurate) would've improved revenue on one of our sales channels by approximately 30% if it had actually been put into production....
As many (most?) of us on HN are in some sense or another professional programmers I would think that would be an easy question to answer.
In my opinion the vast bulk of closed source code suffers from exactly the same constraints.
And most definitely there are vast quantities of quite execrable code in closed source programs. I've seen plenty and written some.
Yes there will be many badly written programs (I think someone said that 90% of anything will be not very good), but there is good stuff too. I think it may be the case even with the closed sources, but in that case they are unavailable so we will not have any statistics about it.
Theodore Sturgeon is usually credited with it but he was a little less polite and rather more definite, see: https://en.wikipedia.org/wiki/Sturgeon%27s_law
> [Open source] did not reward innovation. The most successful products of open source are knockoffs of old ideas; Linux included.
So what about Spark? What about Python numpy, pandas, and scikit-learn? Most people don't just use them because they are open source. They are innovative solutions to difficult problems.
I ask you in good faith...if you pushed this to a public github repo that was your reasoning? If it was something I found to be of value and you'd LICENSE'd it under a promiscuous license and I took that code and made a few million dollars from your idea (and kept all the money), would you be happy with that?
Was this just a thing to show potential employers you can code and use git, how does an employer even know actually you wrote that code?
> they're referring to serious projects like the Linux kernel, Apache, PostreSQL, Firefox, etc.
I feel you're missing the point here, not all the contributors to these projects are getting paid for their efforts. See his point about Linux Torvalds comment about:
This model of using people was acknowledged right from the beginning with a sly wink to Linus Torvalds from Eric S. Raymond in The Cathedral and the Bazaar.
Eric S. Raymond: "In fact, I think Linus’s cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model. When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said: “I’m basically a very lazy person who likes to get credit for things other people actually do."
The act of writing code changes the programmer. I have written many things that didn’t turn into successful open source, nor did they act as resume-ware. But the act of writing them taught me something.
There is no waste of human effort involved when you practice your craft. This is like telling me that if I climb a cliff and then lower myself back to the ground, I haven’t gone anywhere.
Right now I’m working on implementing a subset of regular expressions that compile to finite-state recognizers. There is a zero-percent chance that my working code will be used in production.
So what? I am learning something about pattern-matching, and perhaps it will grow into a little language like SNOBOL.
http://raganwald.com/2019/09/21/regular-expressions.html
If that is a waste, then most of my most enjoyable moments programming were also a waste.
Yup, what about the amount of human effort that has been wasted in the course of producing off-the-shelf proprietary software? How much of that proprietary stuff is now entirely useless, for some reason or another? It's just so weird to make an engineering-focused argument for proprietary stuff, when the only case that's even remotely plausible is about production incentives, and everything else hugely favors FLOSS.
As an aside, I'm pretty sure that, in the medium-to-long run, we'll manage to fund FLOSS development to an entirely satisfactory extent via crowdfunding, and that while saving a lot of dough compared to what it would take to fund proprietary development in the same way.
But in fact, even his point about support revenues is misguided. Well-designed and easy-to-use software does not really draw fewer paid-support arrangements than software that's hackish, unintuitive and the like. The nees for paid support is almost entirely an organizational one, so it matters zilch how easy the software is to support in reality; it's far more important that the organization can point to that support contract if any such need should arise.
The main problem is this: in sufficiently complex programs, roughly associated with LOC, there becomes a point where there are no longer enough eyes on enough pieces of code.
Therefore, I propose that the future of FOSS in the Bazarr style is to focus on reducing code complexity and increase readability as much as possible.
“It’s not the daily increase but daily decrease. Hack away at the unessential.” - Bruce Lee
According to the release history, "The Cathedral and the Bazaar" was written in 1997, but originally used the term "free software". The term was changed to "open source" on February 9th. [2]
[1] https://opensource.com/article/18/2/coining-term-open-source... [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
What an absurd dichotomy. Even if you work full time on open source, you probably can't be a major contributor to more than a handful of large projects, at most; many people specialize in just one. But you probably use dozens to hundreds of open source programs. So for any project with a modicum of popularity, of course the number of people who use the software without contributing dwarfs the number of contributors. That would be true even if everyone worked full time on open source.
Admittedly, the OP's definition of "takers" is not just "people who use without contributing", but tacks on some ad hominem insults to supposedly qualify it. The result has very little resemblance to reality. Sure, there will always be some people who become truly abusive if a project makes a change they don't like. But they're definitely a minority. Most people, facing such a situation, don't speak up at all; they might be annoyed, but they keep it to themselves. Others do speak up, but know how to be polite about it. Perhaps the OP assumes that people should not voice negative opinions at all, if they're not contributing to a given project. I disagree. A good default assumption is that open source maintainers are open to polite and well-reasoned negative feedback. A maintainer can always forbid such feedback in official project forums if they so choose; if they do, users should respect it, but it's is not a very gracious move.
And what the heck do DRM cracking and piracy have to do with anything? In my experience, those people – whom I respect – form communities which are oriented around piracy, and pretty separate from the open source world. In part this is because the nature of the work they do is different; reverse engineering is different from software development, and many pirates do neither of those, but just use existing tools to distribute pirated copies of whatever type of media they're fans of (e.g. anime). I'd say they're also more likely (compared to programmers as a whole) to use cracked proprietary software instead of open source. Of course, this is a massive overgeneralization, but the point is that bringing them up makes no sense.
"An awful lot of popular open source is inferior reverse-engineered copies of existing commercial software (Gimp, OpenOffice etc)." Is Gimp a reverse-engineered copy of existing software? Just because it is similar to some proprietary software does not necessarily mean that it is a "reverse-engineered copy" of it. OpenOffice presumably involves the reverse-engineered formats of Microsoft Office, although now there is LibreOffice. Both Microsoft Office and LibreOffice each have some features the other lacks. What is "inferior" may also depend on your opinion, because in some cases it isn't so clear, and in some cases it may be inferior in some ways but superior in others.
"If open source programmers do innovate and their innovation is good then its just as likely to be swept away from them by the corporations who have the capital to exploit it." In my experience that doesn't always happen. Many features first implemented in GNU/Linux systems are things that they did not implement similar features in Windows until much later.
"... the Linux desktop still lags behind Windows and the interface looks stuck in the 90s." Actually, I think both in Linux and Windows many programs try to be too fancy, but in Linux I can change the window manager and all of that stuff easily and still works. I uninstalled the desktop environment, and I think it works much better than Windows ever did, actually.
"Good software is properly documented, does not break and does not require hand-holding to use it." True, but that isn't the issue; the issue is customizing it.
Love of money is the root of all evil.