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:
Independently from the platform, be it Node.js / JavaScript or .NET, new OSS projects are born, gain huge adoption - and die.

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:

• A general manager can resign itself if he doesn't want to maintain to project any longer. The project then is in a pool of projects "looking for new general manager". Other people can apply for that role and take over projects in a governed and transparent way. Community could even vote the next general manager if more persons apply as general manager for a particular project.
• A general manager can be resigned by the registry which might sound frightening at a first sight. But I think there are several advantages. For example, if a core maintainer doesn't even respond to pull requests or issues in some manner in a reasonable time, he might get warnings from the registry. After a specific number of warnings he could be resigned by the registry and the project gets in the pool as described above.
• Projects can have proxies. If the general manager is temporarily not able to maintain the project, the proxy can maintain the project during that period.

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.