4 ms·
When we really think about it, what's the real fear behind 2-year vs 4-year DOSP? Is it that users will choose the 2-year OSS version over the latest version, o
by ezekg 2y ago
When we really think about it, what's the real fear behind 2-year vs 4-year DOSP? Is it that users will choose the 2-year OSS version over the latest version, or that it encourages more viable competition? The former sounds like a value problem, and the latter sounds like an adoption problem, and those share a root problem.
The BUSL with a 4-year delay has shown to work, so why wouldn't the FSL with a 2-year delay also work? I personally feel like 2 years is a good enough head start i.r.t. competition, while providing users with more viable options to recover a lost or sunken ship.
- layer8 2y agoThe longer a product/service exists, the easier it is to compete with it based on the version two years prior, in particular if the source of the current version is also available (even if you can’t use it verbatim — but you can build your own variant of newer features, possibly even with a fully compatible API).
- ezekg 2y agoSure, but the same can be said for the 4-year delay, too. I don't really see a big difference, and I'm using the FCL [0] which is also 2-year DOSP. If the author is no longer improving the product in 2-year cycles, they deserve to be usurped. [0]: https://fcl.dev https://fcl.dev
- layer8 2y agoI’m assuming that they do keep improving the product, but the longer the product exists, the lesser that improvement will be, relative to what was achieved cumulatively in the years before. A moat is built up by keeping accumulating years of improvement, not by only retaining a constantly diminishing lead.