logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Developers-shouldnt-distribute.md (4409B)

    

  1. ---
  2. date: 2019-12-09
  3. layout: post
  4. title: Developers shouldn't distribute their own software
  5. tags: [practices]
  6. ---
  8. An oft-heard complaint about Linux is that software distribution often takes
  9. several forms: a Windows version, a macOS version, and... a Debian version, an
  10. Ubuntu version, a Fedora version, a CentOS version, an openSUSE version... but
  11. these complaints miss the point. The true distributable form for Linux software,
  12. and rather for Unix software in general, is a .tar.gz file containing the source
  13. code.
  15. **Note**: This article presumes that proprietary/nonfree software is irrelevant,
  16. and so should you.
  18. That's not to imply that end-users should take this tarball and run `./configure
  19. && make && sudo make install` themselves. Rather, the responsibility for
  20. end-user software distribution is on the distribution itself. That's why we call
  21. it a *distribution*. This relationship may feel like an unnecessary middleman to
  22. the software developer who just wants to get their code into their user's hands,
  23. but on the whole this relationship has far more benefits than drawbacks.
  25. As the old complaint would suggest, there are hundreds of variants of Linux
  26. alone, not to mention the BSD flavors and any novel new OS that comes out next
  27. week. Each of these environments has its own take on how the system as a whole
  28. should be organized and operate, and it's a fools' errand for a single team to
  29. try and make sense of it all. More often than not, software which tries to field
  30. this responsibility itself sticks out like a sore thumb on the user's operating
  31. system, totally flying in the face the conventions set out by the distribution.
  33. Thankfully, each distro includes its own set of volunteers dedicated to this
  34. specific job: packaging software for the distribution and making sure it
  35. conforms to the norms of the target environment. This model also adds a set of
  36. checks and balances to the system, in which the distro maintainers can audit
  37. each other's work for bugs and examine the software being packaged for
  38. anti-features like telemetry or advertisements, patching it out as necessary.
  39. These systems keep malware out of the repositories, handle distribution of
  40. updates, cryptographically verifying signatures, scaling the distribution out
  41. across many mirrors - it's a robust system with decades of refinement.
  43. The difference in trust between managed software repositories like Debian,
  44. Alpine Linux, Fedora, and so on; and unmanaged software repositories like PyPI,
  45. npm, Chrome extensions, the Google Play store, Flatpak, etc — is starkly
  46. obvious. Debian and its peers are full of quality software which integrates well
  47. into the host system and is free of malware. Unmanaged repositories, however,
  48. are [constant sources][pypi malware] for crapware and malware. I don't trust
  49. developers to publish software with my best interests in mind, and developers
  50. shouldn't ask for that level of trust. It's only through a partnership with
  51. distributions that we can build a mutually trustworthy system for software
  52. distribution.
  54. [pypi malware]: https://www.zdnet.com/article/two-malicious-python-libraries-removed-from-pypi/
  56. Some developers may complain that distros ship their software too slowly, but
  57. you shouldn't sweat it. End-user distros ship updates reasonably quickly, and
  58. server distros ship updates at a schedule which meets the user's needs. This
  59. inconsistent pace in release schedules among free software distributions is a
  60. feature, not a bug, and allows the system to work to the needs of its specific
  61. audience. You should use a distro that ships updates to *you* at the pace you
  62. wish, and let your users do the same.
  64. So, to developers: just don't worry about distribution! Stick a tarball on your
  65. release page and leave the rest up to distros. And to users: install packages
  66. from your distro's repositories, and learn how its packaging process works so
  67. you can get involved when you find a package missing. It's not as hard as it
  68. looks, and they could use your help. For my part, I work both as a developer,
  69. packager, and end-user, publishing my software as tarballs, packaging some of it
  70. up for my [distro of choice][pkgs], report bugs to other maintainers, and field
  71. requests from maintainers of other distros as necessary. Software distribution
  72. is a social system and it works.
  74. [pkgs]: https://pkgs.alpinelinux.org/packages?name=&branch=edge&arch=x86_64&maintainer=Drew+DeVault