Open Source hot take: A software project is allowed to be *done*.
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante I can't imagine ever being done with software I actually use in day-to-day life. I will always spot something that can be better or smoother or some additional functionality that would make it more useful. (This is, of course, a big "if" - talking about software "for me".)
In software in the public/open source/product sphere, I imagine there will always be feature requests from the userbase as well. If something comes in that is worthwhile (and truly additive to the value of the software)... why ignore it?
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante I've been thinking about this a lot with a particular client. They keep building out new features, and while they're not bad features, I'm not sure it's actually helping the product.
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante this essentially applies to all sorts of things. Not everything always needs to be constantly in search of more.
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante I wish corporations would realize this also!
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
THANK YOU!Drupal should have stopped at 7… maybe 9 and then forked to whatever it is now. they're two completely different products and i’ve resented it ever since. Backdrop (the fork from D7-8) is great, but it doesn't get the money and support Drupal gets.
-
@tante ANY software project that is never "done" was badly defined in the first place and suffers from scope creep.
@marshalla99 @tante oof! SAY THAT!
-
@tante "Maintenance mode" is actually good because it stops devs from changing the damn UI every month just to have "kept the project alive"
@howtophil @blogdiva @tante I believe the reason devs/companies make unwanted, unnecessary changes to software and services all the time is to justify charging a subscription fee for those things instead of letting you pay one time to own a copy, like in the old days. The move to subscription billing has created this perverse incentive.
-
Or, better, make it easy to add features without needing a fork. Provide clear and stable APIs and hooks for plugging in scripting languages.
No single program can capture 100% of all users' requirements. The goal for a Free Software project should always be:
- Implement the 90% of requirements that are common to most users.
- Make it easy for users to add the remaining 10% themselves.
- Make it easy for users who have the same 10%s to share their changes.
- Make it easy for users who have overlapping 10%s to share the common parts with other people, including overlapping sets of people.
Once you reach this point, you're done.
@david_chisnall@infosec.exchange @webbop@tech.lgbt @tante@tldr.nettime.org the problem here is, most projects are not designed as an Open Source project, but as a problem to be solved for the one person, which in turn maybe gets published and used for other things.
Adding a plugin system or API afterwards is such a big and annoying hassle. So I disagree, that everything should get an plugin system or API after the program is done, because that is (again) a new feature.
-
The mantra of the last 25+ years has been that desktop computing is easy and ubiquitous and all programs should be easy.
Because they are easy, they do not require manuals or good documentation and most importantly, do not require training and education.
The reality is that every field of endeavor is complex and messy and has lots of stuff to learn. Management gravitates to "it looks easier, so it must work better" and this is almost always incorrect.
Meanwhile, many people have adopted the idea that they "aren't good at computers" when in reality they have never been taught and don't even realize what there is to learn.
@dashdsrdash @ArneBab @tante It’s possible (but difficult) to design software to be intuitive and easy to use. It’s easier to write good documentation but nobody wants to do it. This is why so many projects give the documentation work to AI now even though it’s not very good. They kind of understand that they are supposed to have documentation but don’t want to do it and don’t *really* understand what the purpose/goal of documentation is.
-
@dashdsrdash @ArneBab @tante It’s possible (but difficult) to design software to be intuitive and easy to use. It’s easier to write good documentation but nobody wants to do it. This is why so many projects give the documentation work to AI now even though it’s not very good. They kind of understand that they are supposed to have documentation but don’t want to do it and don’t *really* understand what the purpose/goal of documentation is.
@MisuseCase @dashdsrdash @ArneBab @tante
The only thing worse than no documentation is stale documentation.
-
@MisuseCase @dashdsrdash @ArneBab @tante
The only thing worse than no documentation is stale documentation.
@paninid stale documentation is still better than blatantly wrong documentation that looks correct on the outside but teaches concepts wrong.
I tried letting an LLM summarize a programming book I wrote. It looked surprisingly good, until it was just plain wrong.
@MisuseCase @dashdsrdash @tante -
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante still copy pasting script written in BASH in the early 1990ies...
-
Open Source hot take: A software project is allowed to be *done*. Not everything needs to add features or rewrite things. You can just be happy with functionality and focus on just maintainance. "Maintenance mode" is not always bad but can just show a mature product.
@tante a side problem problem for me with this is when a piece of software is done it's impossible to tell whether it's actually still in maintenance mode, or if the author silently stopped caring and maintaining it.
Obviously the author doesn't owe me anything but I would like to know whether the software is abandoned -
@tante a side problem problem for me with this is when a piece of software is done it's impossible to tell whether it's actually still in maintenance mode, or if the author silently stopped caring and maintaining it.
Obviously the author doesn't owe me anything but I would like to know whether the software is abandoned@tante for some software it doensn't matter at all, for some it's very important -
@dashdsrdash @ArneBab @tante It’s possible (but difficult) to design software to be intuitive and easy to use. It’s easier to write good documentation but nobody wants to do it. This is why so many projects give the documentation work to AI now even though it’s not very good. They kind of understand that they are supposed to have documentation but don’t want to do it and don’t *really* understand what the purpose/goal of documentation is.
@MisuseCase
it's hard to write documentation for something you already knowalso, people "good with computers" have absorbed so much of the unspoken patterns seen in computing that they mostly get by without documentation and it'a hard for them to figure out which parts may be unobvious to an average person
@dashdsrdash @ArneBab @tante -
Or, better, make it easy to add features without needing a fork. Provide clear and stable APIs and hooks for plugging in scripting languages.
No single program can capture 100% of all users' requirements. The goal for a Free Software project should always be:
- Implement the 90% of requirements that are common to most users.
- Make it easy for users to add the remaining 10% themselves.
- Make it easy for users who have the same 10%s to share their changes.
- Make it easy for users who have overlapping 10%s to share the common parts with other people, including overlapping sets of people.
Once you reach this point, you're done.
@david_chisnall @webbop @tante
Well, I do that for most of my recent personal projects, while being fully aware that I'm likely the only user of that project
I never regret it though, because designing extensible software is fun
-
@MisuseCase
it's hard to write documentation for something you already knowalso, people "good with computers" have absorbed so much of the unspoken patterns seen in computing that they mostly get by without documentation and it'a hard for them to figure out which parts may be unobvious to an average person
@dashdsrdash @ArneBab @tante@wolf480pl That may be why Stackoverflow worked so well.
Until its community got devastated by AI.
-
@MisuseCase
it's hard to write documentation for something you already knowalso, people "good with computers" have absorbed so much of the unspoken patterns seen in computing that they mostly get by without documentation and it'a hard for them to figure out which parts may be unobvious to an average person
@dashdsrdash @ArneBab @tante@wolf480pl @dashdsrdash @ArneBab @tante A few years ago I was responsible for ensuring security compliance for components of a large project. Doing this work required reviewing documentation of the components. I found that while all the documentation followed a common format, parts were often hastily copy-pasted or entered, and sometimes they were out of date.
/1
-
@wolf480pl @dashdsrdash @ArneBab @tante A few years ago I was responsible for ensuring security compliance for components of a large project. Doing this work required reviewing documentation of the components. I found that while all the documentation followed a common format, parts were often hastily copy-pasted or entered, and sometimes they were out of date.
/1
@wolf480pl @dashdsrdash @ArneBab @tante I would have to chase down someone on the team responsible for the component to get missing/current information. Sometimes the documentation about who was responsible for a component was out of date too, and the person I tried to reach was gone.
When I chased someone down for details about their project they sometimes asked me why Thing A had to be in the documentation anyway, didn’t everyone know Thing A worked like this?
/2
-
@wolf480pl @dashdsrdash @ArneBab @tante I would have to chase down someone on the team responsible for the component to get missing/current information. Sometimes the documentation about who was responsible for a component was out of date too, and the person I tried to reach was gone.
When I chased someone down for details about their project they sometimes asked me why Thing A had to be in the documentation anyway, didn’t everyone know Thing A worked like this?
/2
@wolf480pl @dashdsrdash @ArneBab @tante I would remind them that the project was a few years old and very large, different people were coming on board or leaving all the time, requirements had changed, and teams working on different things often didn’t talk directly to each other. So when documenting your feature you cannot assume prior knowledge and you need to be explicit about even the “obvious” stuff.
/3
