4 ms·
The dead simple solution to this nobody is talking about is to fork it. If you want to ensure that some random stranger (our friendly FOSS maintainer) isn't goi
by indigochill 5y ago
The dead simple solution to this nobody is talking about is to fork it. If you want to ensure that some random stranger (our friendly FOSS maintainer) isn't going to sabotage your product, the only solution short of negotiating a support contract with them (which some FOSS developers are not amenable to) is to bring that software internal. You still benefit from FOSS because you get a huge head-start from all the up-front work, but software maintenance going forward should be the responsibility of the user of that software, not of some random stranger.
But commercially this is unpopular because it means that companies have to actually account for the cost of maintaining a complex software stack instead of pretending all the open source dependencies maintain themselves.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- jjav 5y agoThis is really the only correct solution. Either pay the maintainers to do the work (preferable) or in-house the work (second choice). Long ago at Sun the practice was that all code had to have an internal team maintaining it. If the code was brought in from outside that's fine, but some team internally still had to be where the buck stops for fixes. If all bugs can be fixed by bringing in updated version from open source, that's great. But if not, there's still a customer with a bug and it must be fixed by the internal team if that's what it takes. Of course, this wasn't too popular with some management, since they wanted to bring in all the free code but offload all the work to unpaid volunteers, instead of budgeting for maintenance.