proposed foss development guideline: every commit should make the project easier to fork (or at least not make it more difficult to fork)
@aparrish That feels EXTRAORDINARILY difficult, no? like especially, /every/ commit?
... hmm, in like a Release Notes listing, what might be some examples of "Forkability improvement: ..." the was release notes often have "Feature: ..." or "Bugfix: ..." or "Documentation: ..." ?
@gaditb @aparrish depends what you mean by “forking”
if you are trying to make it easier to “soft fork”, i·e fork while maintaining the ability to pull in upstream work, then this is very difficult. it means you can never refactor or really, make the software better, because this will make things harder for existing forks. but the only reason to soft fork is to ensure you continue to receive new features, and software should never add new features
if you are trying to make it easier to “hard fork”, i·e produce a new distinct software using the existing software as a base, i think this should basically always be the goal. requirements for hard‐forking software are really just maximalist expressions of requirements for developing software, and the goal of all software should be to be easy to develop
(there are caveats to this but i am for the sake of argument pretending we all participating in the white western intellectual commons, since that is implied by the term “foss”)
