4 ms·

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, an

by _AzMoo 7y ago

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.

Beltiras 7y ago
At that point you have that choice. If the software was proprietary you only have the migrate option.
SmallDeadGuy 7y ago
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
chme 7y ago
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.
- tmikaeld 7y ago
  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 https://github.com/WebTales/rubedo/issues/1477
arghwhat 7y ago
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.
_wldu 7y ago
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.
- chme 7y ago
  > 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.

by _AzMoo 7y ago

Beltiras 7y ago

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

SmallDeadGuy 7y ago

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

chme 7y ago

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.

tmikaeld 7y ago
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 https://github.com/WebTales/rubedo/issues/1477

arghwhat 7y ago

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.

_wldu 7y ago

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.

chme 7y ago
> 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.