everything wrong with free software

 "obedience breeds foolishness"

### the-importance-of-small-utilities *originally posted:* apr 2022 if you have learned the basics of coding, and you have an operating system, you will probably want to write some programs for it. if you dont have an operating system, and you are good at coding, you may even want to write an os. either way, as your code matures, it is likely to get larger and more complex. if it gets too complex, this threatens the likelihood of it being maintained, or even useful. this work will try to outline some reasons that small utilities are a good idea. instead of ranking these reasons, it will be taken for granted that the relative worth of each reason will depend on the needs and goals of the user or group of users. unix, bsd and even gnu, were originally designed to take advantage of small utilities. when unix was created, small utilities (by todays standards) were practically a given; the computer had few resources, and writing small utilities meant you could actually run them. today we have vastly more resources at our disposal, and we seem to gain substantially more at regular intervals. why bother with small tools then? here are some considerations: 1. bloat outruns hardware upgrades no matter how much computers get faster, bloat gets slower even faster than that. people routinely complain of their computer being "slow", even if its just one or two necessary tasks. this is a result of poor design. smaller, more lightweight tools tend to solve if not avoid this problem. 2. bloat creates more e-waste even if you could afford to get a new computer every 6 months, to try to keep up with bloat slowing things down, this is incredibly wasteful. a good computer can last many years, for starters, and some computers are still useful even when they are from 20 years ago. bloat undoes this, leading more people to throw away good machines and add to e-waste. 3. bloat takes longer to download, install, backup, copy even if your computer was always fast enough to run bloat, it still takes longer (than less bloated things) to download. it often takes longer to install. because its larger, it takes longer to copy (particulary to and from removable media) and things like this add up to more and increase the time and effort (and media) needed to do backups of your software. 4. bloat is more trouble to manage for users bloat comes with an increase of features, which sounds nice except that its often features you dont need, which can even lead to developers messing with features you rely on. sometimes these "upgrades" help and often they put the user at a disadvantage, other than all the other issues already mentioned. 5. bloat is more trouble to manage for developers part of the reason that bloat can hurt users is that it hurts development. excessive features (a category and cause of bloat) not only contribute to bloat itself, but can shift focus (in whats maintained) from features you need to features that are useless to you. and rather than simply keep ramping up useful features, what ramps up is useless features while some standards begin to disappear. not only is your software becoming slower, its actually starting to lose reasons you use it. despite the shift in focus from useful features to useless ones, as your software becomes less prone to maintenance and more prone to fashion and fads, this shift in focus rarely returns to removing bloat-- rather there is so much bloat that it starts to crowd out features you need, so developers start insisting "no one uses this" (while many users still do) and they know SOMETHING has to go, but the work never returns to the original (reasonably un-bloated) scale. yes, maybe a new version becomes "faster" or "more lightweight" but its "faster" or "more lightweight" in a different (bloated) range. this is when the viability of the project itself becomes threatened. a fork is still possible, but difficult to put together since forks of larger software require more developers, the developers and promoters have insisted that all the bloated versions are better (maybe many users believe this) so instead of getting forked, the project will move from smaller groups who know what they want the software to accomplish to larger groups who capitulate to (or even take orders from) corporations, who bloat the software further for a few years before abandoning it for newer, shinier things. at this point, there is little hope for the software. everyone interested has moved on to something else-- possibly because they had little other choice (the bloated version no longer suited their needs and they werent skilled or organised enough to fork the version they liked). the more bloated a program becomes, the less forkable it becomes. some projects are lucky-- many more are not. in real life terms, we can say that bloat is even a threat to freedom 3-- and thus a threat to free software. so its worth saying at least, that the best way to keep a project sustainable is to keep it small! unless of course, you have the broken development model of always choosing bloat over sustainability. this is popular with businesses and especially businesses with monopolistic practices, which do not benefit from sustainability but rather exploit the treadmill that keeps users subjugated and dependent. a viable free software movement would recognise this threat and work to mitigate it. the gnu project does not. => https://wrongwithfreesw.neocities.org