this post was submitted on 11 Jan 2025
-33 points (28.6% liked)
Open Source
32289 readers
37 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As a developer (not affiliated with either of those projects), you have to understand a couple of points:
Adding features means increased maintenance burden. Any feature that is added must be tested and maintained, and once released, often cannot be changed without significant user push back.
Users often have no idea what they actually want. If a project just implements what every user asks for, it'll end up being a disjointed mess of a project. Developers have to draw a line somewhere.
Unless someone is paying for the work, developers have zero incentive to make changes. A democratic committee can make all the requests they like, but unless the developers are on board, nothing will happen. (Also, tying into 2, but good luck getting a committee of users to agree on anything)
The only real answer is to fork the software, make the changes and hope that either everyone switches to your fork, or the upstream accepts the changes. That is the Open Source way of doing things.
This is really important and often underemphasized. People don't reflect on why they feel they want X or Y. We don't know if it's some objective reason or a product of an arbitrary decision some other software maker taught us. Famous example for this is pinch-to-zoom. The first people who tried it on the iPhone found it seriously unintuitive and even difficult. Apple spent a lot of effort teaching people to pinch-to-zoom. Then you have the case where we don't even know what we might like if we haven't experienced it. The do-what-people-want mantra runs into these and other rrlated problems and projects that live by it often aren't the best things out there. Good projects typically do a mix of both. Human-computer interaction / UX are legitimate research disciplines for a reason and they've yielded very useful heuristics to produce better software.
Requirements gathering is really really difficult, and its why I am currently not worried about an LLM taking my job.
For my work, I had a project where the requirements were gathered for us, which stated that A was completely forbidden, but X, Y and Z were required. We developed to that spec, released it, and it turned out that the users actually needed A all along. We added A, and now A is the only feature they use... Shame, because X, Y and Z were cool features, and I was really proud of them, but a complete waste of time developing them.
Absolutely true.
Do you know how many forks of mastodon there are and how many died, because they can't compete against the network effect of the master project ?
Yup, so convincing upstream to take the changes is really the only option, which gets you back to point 1.
There's also difference in how much work the maintenance of forks is depending on how they implement new features. There are many ways and the easiest ones are typically the least maintainable. Designing those features in order to minimize maintenance work when new code drops from upstream can dramatically change the equation and therefore the fork viability. I've worked at an Android mobile OEM and dealt with code drops from Google and Qualcomm. Every OEM essentially maintains a fork of Android and deals with a massive set of changes with every Android release. Implementing stuff by straight modifying Android source files lead to huge maintenance workload. After going through a few code drop cycles we devised a set of strategies that drastically decreased the effort needed.
Are you at liberty to describe those strategies further? Or point to some other resource? Its never been a situation that affects me, so I'm curious to learn more.
It depends on the problem, language, framework and what the options are. If at all possible, write stuff without touching upstream code. If you're working in a modular, pluggable system, there's a lot you can do this way. In Android specifically, you can do a lot by writing components that plug into the Intent framework. When it comes to modifying upstream code, you use whatever facilities the programming language offers to minimize the lines of code changes. Ideally only modify upstream code by adding a single line in a module. E.g. write a separate Java module, import it into the upstream code and call it in a single new line in the appropriate block. Then do your work in your module, import and call additional things as needed. Surround the added line with consistent labels in comments. Enforce this in code review and ideally automation. When a code drop comes, git can often automerge such additions. When it can't, the merge tools make it very clear where your changes are as they aren't intermixed all over the upstream code, making the merge work easier. There were some clever tricks with branching that I don't recall. You could even write your own tooling to help with any of this. There's clever things you can do with the build systems too. None of this is too complicated that a competent software team can't figure out if given the direction and time to do it.
Still sounds like it could get quite messy if Google adds a feature, Qualcomm adds a fix to that feature and then you need to add a fix on top of that. Does it work better in practice and just needs to been seen to be understood?
Competence, Time and Direction are often quite hard to find in any professional team, let alone an open source team :D
Of course it can, the point is how difficult it is to get out of the mess. Patching upstream source directly is magnitudes worse. Unfortunately, when you want to add one button to SystemUI somewhere, going straight to the layout and adding it in is most tempting.
In practice, an upstream merge would typically be completed in a few days to several weeks at worst with little to no breakage. These days that's even easier because a lot of pieces got modularised and separated as part of the work done in Project Treble.