Fabio Manganiello on Nostr: npub1a0md8…2z25h everybody loses for two reasons: Compatibility always loses when ...
npub1a0md8eksmeellvmm2qscr3uq3k2updvajyeqf40jpll6eeehhxdsn2z25h (npub1a0m…z25h) everybody loses for two reasons:
Compatibility always loses when hard forks are involved. The two versions will have to be kept in sync. That takes time, and it’s not guaranteed to work forever, nor guaranteed to work for all the features, nor it’s guaranteed that the system of incentives will always play towards maintaining mutual compatibility - see what happened with the MySQL/MariaDB fork for an example, or more recently with Gitea/Forgejo. Since Redis is used in so many applications, many applications will also have to make their code compatible with both the versions, or fork it as well - think of what may happen with widely used applications like Celery. Developers that build products on top of Redis will also have to adapt their code to support KeyDB as well, or whatever other fork may happen soon. Eventually that spreads out development resources. And distro maintainers probably will also have to update the repos if it turns out that SSPL licenses aren’t FOSS-approved and they have to go for alternatives.
The AGPL license strike a good balance. It’s a win-win with a compromise. Tech businesses can benefit from community work, but if they run it as a service or modify it they will also have to release the changes. In exchange, FOSS software doesn’t try and tell businesses what they are supposed to do with their own software if they want to use the open code. By taking a hard stance with a license like SSPL, the hard fork will happen and, if it’s based on a license like BSD/MIT, businesses won’t be compelled to contribute back to the open product at all. They will probably develop 100% closed products on top of the BSD codebase and are likely to break compatibility on purpose at some point, and there’s nothing the open product can do about it. Eventually, efforts will split as well, competition is likely to shift towards mutually exclusive features, and that’s where everyone loses.
Compatibility always loses when hard forks are involved. The two versions will have to be kept in sync. That takes time, and it’s not guaranteed to work forever, nor guaranteed to work for all the features, nor it’s guaranteed that the system of incentives will always play towards maintaining mutual compatibility - see what happened with the MySQL/MariaDB fork for an example, or more recently with Gitea/Forgejo. Since Redis is used in so many applications, many applications will also have to make their code compatible with both the versions, or fork it as well - think of what may happen with widely used applications like Celery. Developers that build products on top of Redis will also have to adapt their code to support KeyDB as well, or whatever other fork may happen soon. Eventually that spreads out development resources. And distro maintainers probably will also have to update the repos if it turns out that SSPL licenses aren’t FOSS-approved and they have to go for alternatives.
The AGPL license strike a good balance. It’s a win-win with a compromise. Tech businesses can benefit from community work, but if they run it as a service or modify it they will also have to release the changes. In exchange, FOSS software doesn’t try and tell businesses what they are supposed to do with their own software if they want to use the open code. By taking a hard stance with a license like SSPL, the hard fork will happen and, if it’s based on a license like BSD/MIT, businesses won’t be compelled to contribute back to the open product at all. They will probably develop 100% closed products on top of the BSD codebase and are likely to break compatibility on purpose at some point, and there’s nothing the open product can do about it. Eventually, efforts will split as well, competition is likely to shift towards mutually exclusive features, and that’s where everyone loses.