Hacker News Reader

Comment by _AzMoo | Hacker News Reader

On the flip-side, when relying on OSS you can often find yourself in a situation where the last maintainer of a library critical to your workflow disappears, and the only options you have are to fork it and maintain it yourself (at high cost), or switch to something else if it's available (often at high cost). OSS is not a panacea for development risk.

View on HN

It isn't, but the fact that you have two options (maintain yourself or switch to another solution) instead of a single option in the case of non-OSS (only switch to another solution) is a huge benefit. And, unless you're using some very obscure OSS or very outdated OSS (probably a bad idea), the likelihood is that there is a community around the product which consists of multiple maintainers/experts who are willing to continue development even after key maintainers move on

You can always choose some well supported and active open/free source product. If that gets abandoned, then you will figure that out and there will be others in the same boat as you and share the cost.

Also you could just pay some open/free source developers if they provide mission critical software for you, so that it does not get abandoned. Free as in Freedom, not as in beer they say.

This depend entirely on the scope of the software, take the project Rubedo CMS [0] for example, which died after funding was cut.

It was simply too large for anyone to pick up where they left off.

[0] https://github.com/WebTales/rubedo/issues/1477

Use large, well-regarded open source code/projects. They are easy to find. Prefer ones with ISO standards (C, C++, etc.) where possible. Other, non iSO, projects are reputable as well (Go, Python, etc.) but may be influenced more by vendors. If you rely on open source code that only has one developer (or a small team), fork it or write your own.

> If you rely on open source code that only has one developer (or a small team), fork it or write your own.

Please no. Try to pay the developer or upstream your own changes first. There are so many different active and unmergable forks of the same project already on github. That makes finding the 'right' project for yourself just much more difficult.

To be fair, for many libraries, maintenance is not really required. Hit a bug? Don't do that, or fix that particular bug. Doesn't require daily changes.

Certain types of exposed and way too large components need constant hardening (e.g. OpenSSL, nginx) to patch CVEs, but they are the exception not the rule.

We're a bit too stuck on the idea that things need to constantly change to be healthy.

At that point you have that choice. If the software was proprietary you only have the migrate option.

Reply on news.ycombinator.com