💾 Archived View for station.martinrue.com › gnuserland › 327c605f243a49bc9998ce0136f459ee captured on 2024-05-10 at 13:12:08. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-03-20)

➡️ Next capture (2024-05-12)

-=-=-=-=-=-=-

👽 gnuserland

Why is the concept of "sustainable software" so underrated?

2 years ago · 👍 calpico, lykso, mntn, skyfaller

Actions

👋 Join Station

13 Replies

👽 lykso

Yeah. I don't think small software will ever be something large corporations can handle. The incentives seem all wrong. The people writing the code are usually just collecting a paycheck, and the people cutting the paychecks only care about whether the product keeps the money coming in. · 2 years ago

👽 gnuserland

I coludn't find the source but I remember an article on phoronix where an independent developer / maintainer of an exotic CPU / GPU (don't remember the details though) was helped by a couple of employees of a big Corp.; and while he was "happy" about the contribute to have his effort mainlined into the kernel he also pointed out as those two patches were almost big as the his whole code.

This is the attitude I refer too: engineers are assigned to a project, they throw 2K of lines of codes, is it working? Yes, fine! Nobody cares. Eventually you end up with million of lines of code.

This is a common pattern. Many open source projects start well crafted then cross the radar of some industry interest and become huge and unsustainable like: lxc > docker > kubernetis > {the next invention}. · 2 years ago

👽 lykso

Yeah, the ability to painlessly lock features is going to be a function of how well-defined/small the problem space is. Most of that's going to be technically oriented. The real world is messy and requires flexibility, so you're very unlikely to write, say, an ERP that can reach "complete" status. You certainly can't "complete" software on top of "incomplete" software, as @maria notes. Someone below you in the stack is liable to break your code, even if you *have* perfectly solved the problem at hand with your own code. · 2 years ago

👽 mntn

@maria I see your point and agree that business software in particular can probably never reach completion. But there's many user tools that haven't changed much in many years, yet people are often fully reinventing them or adding small features, and in the process introducing new bugs, incompatibilities, security issues, etc. I'd love to have a curated directory of carefully audited, "completed" software that only receives bugfixes! · 2 years ago

👽 maria

@mntn real life solutions don't get to be feature complete. and unix philosophy doesn't work either. just imagine how unix philosophy would work on something like haircutter's appointments that can be made via app. you need an app to show a calendar, and book something into that. added on top is the contact data. the haircutter needs to see all of the appointments and distribute them to different employees, update customers when someone is sick via phone, etc. you could lock all that, but it's unlikely that this behemoth is sustainable as is, without third party libs · 2 years ago

👽 maria

and sustainability comes from feature and state locking. however you can only lock which can be locked without side-effects. you can lock the gemini protocol, sure. you can't lock a server implementation for that protocol. why? because it may need to grow, adjust, change, it's dependent on things that can change (networking, OS, amount of requests, security upgrades, load balancers...) and when you abstract that concept into components (server + database + file types + ...), everything has its own usage contract, and you need to learn all of them... bam, sustainability dead · 2 years ago

👽 mntn

I was thinking about this earlier. More software projects need to aim for "feature complete" status, and encourage forks or plugins/extensions for people who want to add something new. The UNIX philosophy of small composable tools may be less exciting than huge behemoth projects, but it's certainly more sustainable. · 2 years ago

👽 maria

having worked in development for so long, the shift towards microservices was supposed to guarantee a sustainable ecosystem. small codebases that can be exchanged when needed and development can focus on the parts that actually need improvement and development. with that came systemic complexity, introduced by development structures (i.e. different services still need to communicate with another). software that solve real life problems are as complex as real life problems, no shortcut there · 2 years ago

👽 lykso

Okay, I understand what you're talking about. Maybe "timeless software" is a better phrase for what I was thinking of. I think the two ideas overlap, though. For software to be "timeless," I think it has to address a unit of functionality small enough that it can express that functionality in its entirety, which also tends to mean being small enough for one or two people to maintain the code.

I don't think the problem can be properly solved without addressing politics and economics, though, as these impact who has spare time to begin with, and what they will be equipped and/or inclined to do with that time. I don't *like* it, but I do think it's true. · 2 years ago

👽 gnuserland

More or less what Gemini itself is...

For sustainable I mean a software/project that can be handle by a small group of people in their spare time and do not require a huge amount of workforce.

For instance the Linux Kernel is not anymore a sustainable project anymore:

https://www.theregister.com/2020/01/06/linux_2020_kernel_systemd_code/

Hyper-trophic code makes people dependable by corporations and substantially reduce our freedom to manipulate that code. · 2 years ago

👽 lykso

I'm not sure I understand your reply. Maybe we're using the phrase "sustainable software" differently. What does that phrase mean for you? · 2 years ago

👽 gnuserland

@lykso this explains just a portion of the issue. Organisms that protect the software freedom do not recognize that making a sustainable software development is an essential part of preserving the its freedom, otherwise you become dependable by someone/something else if their product, no matter what if "GPLed", ousts all the alternatives. · 2 years ago

👽 lykso

Ask your average software company which they're prefer to receive for a product: $100 once or $10 a month indefinitely.

I am presently of the opinion that making quality, durable products which retain their usefulness for years or decades is contrary to the tendencies of capitalism. Even if consumers prefer such things, the profit motive ensures most of them will eventually be unable to afford the immediate price (even if it's more expensive long-term to buy the "cheaper" option). IMO, it's more or less inevitable under capitalism that cheap, flimsy products end up dominating the market. Applies to software just as much as to anything else. · 2 years ago