logo

drewdevault.com

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

A-culture-of-stability-and-reliability.md (3479B)

    

  1. ---
  2. title: Fostering a culture that values stability and reliability
  3. date: 2021-01-04
  4. outputs: [html, gemtext]
  5. ---
  7. There's an idea which encounters a bizarre level of resistance from the broader
  8. software community: that software can be completed. This resistance manifests in
  9. several forms, perhaps the most common being the notion that a git repository
  10. which doesn't receive many commits is abandoned or less worthwhile. For my part,
  11. I consider software that aims to be *completed* to be more worthwhile most of
  12. the time.
  14. There are two sources of change which projects are affected by: external and
  15. internal. An internal source of change is, for example, a planned feature, or a
  16. discovered bug. External sources of change are, say, when a dependency makes a
  17. breaking change and your software has to be updated accordingly. Some projects
  18. will necessarily have an indefinite source of external change to consider, often
  19. as part of their value proposition. [youtube-dl][0] will always evolve to add
  20. new sites and workarounds, [wlroots][1] will continue to grow to take advantage
  21. of new graphics and input hardware features, and so on.
  23. [0]: https://youtube-dl.org/
  24. [1]: https://github.com/swaywm/wlroots
  26. Any maintained program will naturally increase in stability over time as bug
  27. fixes accumulate, towards some finite maximum. However, change drives this trend
  28. in reverse. Introducing new features, coping with external change factors, even
  29. fixing bugs, all of this often introduce new problems. If you want to produce
  30. software which is reliable, robust, and stable, then managing change is an
  31. essential requirement.
  33. To this end, software projects can, and often should, draw a finish line. Or, if
  34. not a finish line, a curve for gradually backing off on feature introduction,
  35. raising the threshold of importance by which a new feature is considered.
  37. [Sway](https://github.com/swaywm/sway), for instance, was "completed" some time
  38. ago. We stopped accepting most major feature requests, preferring only to
  39. implement changes which were made necessary by external sources: notably,
  40. features implemented in i3, the project sway aimed to replace. The i3 project
  41. [announced this week][2] that it was adopting a similar policy regarding new
  42. features, and thus sway's change management is again reduced in scope to only
  43. addressing bugs and performance. Sway has completed its value proposition, and
  44. now our only goal is to become more and more stable and reliable at delivering
  45. it.
  47. [2]: https://old.reddit.com/r/i3wm/comments/kn8pa2/an_update_on_the_future_of_i3/
  49. [scdoc](https://sr.ht/~sircmpwn/scdoc) is another project which has met its
  50. stated goals. Its primary external source of change is roff — which is
  51. almost 50 years old. Therefore, it has accumulated mainly bugfixes and
  52. robustness over the past few years since its release, and users enjoy a great
  53. deal of reliability and stability from it. Becoming a tool which "just works"
  54. and can be depended on without a second thought is the only goal going forward.
  56. Next time you see a git repo which is only getting a slow trickle of commits,
  57. don't necessarily write it off as abandoned. A slow trickle of commits is the
  58. ultimate fate of software which aims to be stable and reliable. And, as a
  59. maintainer of your own projects, remember that turning a critical eye to new
  60. feature requests, and evaluating their cost in terms of complexity and
  61. stability, is another responsibility that your users are depending on you for.