3 ms·
You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for
by setr 4y ago
You need to incentivize codebases to be moved to the new thing, or you have to rely on incremental adoption by new projects. It’s a tragedy of the commons — for any individual codebase it’s hardly worth the trouble (My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) but it’s worth it every other codebase was already moved.
Alternatively you build a thing that every other system could be auto-migrated to, which inevitably means supporting every possible feature of everything in play and slapping an ANSI standard label on it; and then watch as everyone extends the standard arbitrarily
- aninteger 4y ago> My codebase(s) already has a standard formatter / package manager / whatever; what do I get by changing?) I guess you don't get much for yourself, but you get closer to some form of community standard. This ultimately helps your codebase "grow" when you need help from, or need to hire, other people. Other people that know those standards.
- setr 4y agoThat’s fundamentally the problem; it’s only beneficial if the whole community moves in unison. If I switch from one standard with 10% ecosystem usage to another with 25%, I’ve accomplished nothing. You need something more like at least 60-70% standard usage to be a meaningful target. Unless that 25% usage choice eventually grows to full usage… but I can’t predict the future — so I’m just betting on it. But that bet also does very little for me even on success (it’s definitely nicer to be normal, but it’s hardly critical), and I could just as well make the migration after it’s become a real standard with no risk. So why am I migrating?