Not all open source projects are alike
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 have been working in open source for roughly a decade now. In that time, I even shortly worked for the FSFE. I am really happy with that and with the state of open source in general.
That said, many people do not agree. I especially found the articles "What comes after 'open source'" by Steve Klabnik and "The Cathedral and the Bizarre" by Mark Tarver extremely interesting.
However, I believe that much of the discussion would benefit from a distinction of different types of software projects. The categorization that I want to propose is about whether a software is meant to be generic and who its target audience is.
On the non-generic technical-user side of the spectrum are hobby projects. Things you do by yourself and for yourself. You get payed in fun and experience and maybe even in a piece of software that is useful for your specific usecase.
You may publish this piece of software online, e.g. on github. It is simple to do, so why not? Mark Tarver calls this "abandonware", but I think there is a lot of value to it. At least there is an off chance that someone else will find it useful. I personally really like to look at existing attempts of solving a problem. I mostly don't end up using any of these projects, but I learn a lot from them anyways.
Companies need software for their internal processes. This software must be usable for non-technical users. Developers have no intrinsic motivation to build this and will typically demand money. Actually, that is what I have been living off for the past years.
Since the software is not essential to the business model and also not really useful for anyone else there is really no downside to publishing it. Someone else might find it useful and maybe even contribute back some bug fixes. In addition, using GPL allows you to use GPL libraries. Choosing open source also tends to help with recruiting developers.
With the first two categories, publishing the code was a nice addition, but the software was not really meant to be used by anyone else. While these are already useful, open source really starts to shine once we get into reusable software.
The infrastructure category includes libraries, frameworks, developer tools and such things. Think of linux, openssl, postgres, git, vim, nginx, django, npm, react. The list goes on forever.
I cannot stress enough how much I as a developer benefit from software from this category. Just imagine all the paperwork you had to do if you had to purchase a license for every library you wanted to use. I am not even talking about the money, just the bureaucracy. I cannot imagine how I would get anything done.
Funding in this category often (but not often enough) comes from companies that build bespoke applications on top of the infrastructure. But even though many projects from this category have sufficient funding, the heartbleed bug, the recent controversy about the SSPL and many reports about maintainer burnout have made it obvious that there are gaping holes.
The question of funding is entangled with the question of governance. The more important a piece of infrastructure is, the more important it is that there is a clear governance model. If the US government provided the funding for openssl, would that have any influence on NSA backdoors?
Finally, on the generic end-user end of the spectrum we have projects such as firefox, libre office, gnome, or wordpress.
This is the category with most complexity and least intrinsic motivation for developers. But for some reason it is also the category that is most often talked about, often with the conclusion that proprietary software just has better quality. Then again, a lot of proprietary end-user applications are awful, too.
I honestly don't know where projects from this category get their funding from. I can just imagine that it is not simple. All the more reason to be impressed by the projects that do exist.
I talked a lot about the different categories of open source and their different benefits. But what about proprietary software?
Even though I no longer believe that it is ethically wrong to produce proprietary software, I still have the nagging feeling that something is wrong about it. Maybe this is best illustrated with an analogy:
Imagine a bake sale where one person gives away cookies for free and even includes a list of ingredients for people with allergies. Another person sells their cookies for 100$ apiece and tells you there is a "secret ingredient".
I would probably not read the list of ingredients, but I would still appreciate the consideration. I would also directly suspect the "secret ingredient" to be something nasty. The price tag of 100$ just seems excessive, especially when there are semen-free cookies available for free.
I understand that other people will associate secrecy and a high price with high quality. So this is totally subjective. But to me it feels shady.
Price of work
Mark Tarver criticises that there is a culture of self-exploitation in open source, where people put in much more than they get out. This is definitely not the case for me. I try to contribute where possible, but I get so much more out of this system than I could ever give back.
Note that this is not a zero sum game: A project that is uploaded once can be re-read and re-used many many times. So putting in less than you take out is not unethical. As long as you try to contribute back here and there you should be fine.
This is not saying that there is no self-exploitation in open source. There clearly is and that is a real problem. This often happens if a project is half way between side project and infrastructure. And while establishing better ways to fund small infrastructure projects is definitely helpful, the other approach to establish clear boundaries and go back to being a side project is equally valid.
I think the open source community is in a really great spot: We publish many side projects to learn from one another, we get paid to build bespoke applications for companies, and we have a truly amazing collection of infrastructure projects. Measuring open source only by its end-user applications misses out on all the good stuff.
Then again, the distinction between technical users and end-users is not set in stone. Come to think of it, the way how much proprietary software reinforces this distinction is another thing I don't like about it. Many open source tools, on the other hand, encourage hacking and learning. I would probably never have become a programmer if gnome2 had not allowed me to configure the panels. That's where everything started for me.
Currently, open source is great -- if you are a developer. I don't think we will ever get good at providing tools to end-users. But maybe we can reduce the gap between the two groups.