TL;DR There's no alternative to OSS but we need to improve how we're dealing with it.
Hannes Preishuber recently wrote a blog post (in german language) about appreciation of work as well as quality and documentation of software nowadays.
While I agree with Hannes that someone's work has to be appreciated, I disagree with his assumptions that OSS is responsible for bad software quality and service / documentation in general.
Today a huge amount of the cloud infrastructure and services run on OSS and companies like MongoDb have build a business around their OSS products.
If quality and service wouldn't be warranted here, that business won't work.
On the other hand, from a developer perspective, OSS can become frustrating anyway:
The problem here is not that these projects die in general because there are several reasons for that.
One reason is, the community has decided to choose another OSS project as state of the art.
Another one is, the core maintainer has decided to no longer maintain the project and makes an official statement about that.
Some maintainers also look for a successor who maintains the project in the future so the project doesn't die at all.
The real problem in OSS are those projects which start, grow over time and then die slowly - or from an adopters perspective: they become zombies. Typical indications for a project dying slowly are unmerged pull requests, unanswered and unresolved issues and of course no further commits to at least update the projects own depedencies.
As said in the introduction, there are no (or only few alternatives) to OSS. Even typical enterprise developers use OSS these days.
All of our customers use OSS in some way and frameworks like Angular will push this trend forward.
When advising customers about using external dependencies (not only OSS) in their code base, we tell them to look for indicators of OSS zombie projects and have countermeasures on hand if a depedency is no longer maintained.
On the other hand, I came to the conclusion that OSS projects, especially the many smaller ones need to be handled in another way opposed to how they're handled nowadays.
If you look at Cassandra, Node.js or Microsoft .NET as OSS projects, they're all under the hood of a foundation which supports these projects. These foundations like Apache Foudation, Linux Foundation, or .NET Foundation provide guidance, mentoring as well as legal, technical and fincancial support.
But I think we should have another form of support or foundation in order to avoid zombie projects and respect criticism from people like Hannes.
After thinking about it for a while and talking to some fellows about it, here are my thoughts:
In general we should distinguish between the "ownership" of the project and the copyright / license for the code.
If you decide to start a new OSS project on GitHub, GitLab, BitBucket or whereever, beside selecting a license for your project, you should be able to transfer the ownership of the project to sort of a "registry".
This registry should provide these features:
The initiator of the project becomes the "general manager" of the project and can work on the project as we all used to work on OSS as before.
But in addition to that, the registry provides the following features:
Some might argue that this is way to much overhead but I'm sure I'm not the first who ran into zombie projects and the bigger your codebase is or if you're maintaining a huge number of critical projects for your customers, you don't want to kill the living deads in your code every now and then. And your customers should not have to pay for this problem.
Please let me know your thoughts about in the comments.