I totally understand where this is coming from.  Any software project of non-trivial size has a certain kind of inertia.  The code is written a certain way, the infrastructure works a certain way, the processes and culture are a certain way, because they have evolved over time and often at great cost.  Changing them is not easy, and not to be undertaken lightly.  That doesn&#x27;t mean e.g. that moving to GitHub is absolutely verboten, but the gain in convenience for (some) users might be offset by a <i>total stoppage of development</i> during the transition.  Then there&#x27;s likely to be a general slowdown for a while as new secondary issues are found and addressed, as current developers make mistakes with the new processes, etc.  If the same users who demand that change are also demanding that their favorite features be implemented (by someone else) right away, they&#x27;re putting the developers in an impossible situation.  Nobody appreciates that.  There always seem to be some users with an overdeveloped sense of entitlement, and that can utterly ruin a project for everyone including the other users.<p>That said, I have to take serious issue with one point.<p>&gt; We write software. We don&#x27;t make packages. Talk to your package maintainer.<p>Wrong.  I have lots of friends who are active package maintainers.  Theirs is often a thankless job, especially now that so many people seem to think the whole idea of packages is outdated now that we have containers instead (BTW they&#x27;re wrong).  Developers don&#x27;t have to become experts in every packaging system or its rules, but they can&#x27;t shirk all responsibility for packaging either.  They need to work <i>with</i> package maintainers, fixing (and not re-creating) problems that make packaging difficult.  Anyone who can&#x27;t do that, or isn&#x27;t willing to, can&#x27;t claim to have &quot;learned all they can&quot; about software delivery, as I see in the first paragraph of the other Taskwarrior article posted today.  Packaging is an essential part of the process.