Why are open source projects too rigid and stuck in dogmatic position ?
take for example mastodon, its CEO recently posted a toot asking who has already considered deleting facebook / threads after the recent controversies, but on the other hand ignores that his stubbornness about certain points like not adding quotes just doesn’t make the project appealing for ordinary people, this feature has been the most request since twitter exodus two years ago. and at every surge of new users mastodon struggles to keep them using the platform, why do these projects struggle to acknowledge what people want the most and deliver on it.
another example is LibreOffice, I was trying to get acclimated to this new office suite and was happy to find that I can theme it to my liking to ease up my transition. but it wasn’t long before I found out how tiny dogmatic decision really pushes to give up on it. I found that LO doesn’t auto-capitalise first letter after line breaks but only after end of sentences, something Word has been doing as long as I can remember, LO argument is that only a . and ! characters mark the end of a sentence in “proper English”. line breaks don’t qualify as a proper end of a sentence for them.
For people coming from proprietary software that among many short comings still strive to offer the best features and smoothest user experience, it is hard to try and stick to open source projects and even contribute back.
Should big OSS project shift to more democratic structures, where decisions are made based on consensus? or do you think the actual models are fine, and I am an entitled user ??
Proprietary software is also really dogmatic. Steve Jobs famously didn’t support flash on the iPhone, there also was no direct access to files/file system in the UI for a very long time. Tim Cook told someone’s Mom to just buy an iPhone to access iMessage. There’s too many user hostile dogmatic positions from Apple.
I think this has nothing to do with open source vs proprietary, but rather specific individuals having power/control over the software to force specific decisions.
Sideloading apps to ios is still a huge difficulty. Also, not possible to access a terminal to the underlying system. No way to modify audio output. All of these are basic things on android.
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.
Users often have no idea what they actually want.
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
Still sounds like it could get quite messy if Google adds a feature
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.
-
…You are considering abandoning Libre Office because it doesn’t auto-capitalize after line breaks?
I found that LO doesn’t auto-capitalise first letter after line breaks but only after end of sentences, something Word has been doing as long as I can remember, LO argument is that only a . and ! characters mark the end of a sentence in “proper English”. line breaks don’t qualify as a proper end of a sentence for them.
Why would you even want that? It’s dangerous to change written text automatically, a lot of people will be annoyed because they wanted exactly what they wrote. Capitalizing after . or ? makes enough sense to automate it because of grammar rules, but there’s no hard-and-fast rule for capitalization after line breaks.
That’s an aucorrenct feature that has been shipped with MS Word for as long as I can remember.
MS Word is one of the most used software il the planet, I believe Microsoft has enough data on why the majority of people want that. what I don’t get is why software with smaller userbases think they know better (ie sometimes they do). Or why LibreOffice is so stubborn on keeping the menu bar default instead of the ribbon-bar, I am not inconvenienced by changing it once and for all, but I know many people who ould nope out at first sight and never give LO a second chance ever again .
It annoys me to no end whenever MS word does that.
You are just assuming, that MS actually knows and cares for what users want. In my experience its the other way round. MS will introduce a change/new behavior and user have to adjust their own behavior, because most are not willing to switch to a competitor program.
I remember very well how much my father sweared at the computer because MS changed the UI to the ribbon bar. It wasn’t at all what he wanted and MS didn’t care to ask users beforehand.
MS Word is essentially a monopoly, but that doesn’t mean that every detail of its features is worth copying - quite the opposite, actually. And again, why do you even want to automatically capitalize the first word after a line break that is not a proper sentence stop?
Or why LibreOffice is so stubborn on keeping the menu bar default instead of the ribbon-bar
AFAIK many users, especially those used to the old UI, dislike the ribbon design.
About the Ribbon: Apparently M$ has a patent (or multiple ones on) it, so they ultimately have the last say on what is and isn’t allowed. They did make a licence availiable royalty-free, but I assume that that licence didn’t cover enough of what LibreOffice needed, so they probably struck a deal with M$ about having the option, just not as the default.
I haven’t researched this all that much, so mostly speculation. Although the M$ having a patent part of someting so true. And that patent (apparently) explicitly states that use in directly competing software with M$'s is forbidden, at least for-profit.
Idk, maybe it’s a case of patent restrictions, or LibreOffice being LibreOffice.
Honestly, a really interesting rabbit-hole.
I know about Microsoft patent, I am not sure whether MS does license it to other software makers as it is very wide spread from big companies like Autodesk to smaller ones like NirSoft. I think they just made the patent to camp on it and intimidated big players with it, the opensource OnlyOffice do ship the Ribbon and they haven’t faced any trouble for it so far.
Why is open source dogmatic? Because every line of code should have a purpose. Features are inherently optional and often cloud the project from the initial objective.
Few people are paid to maintain this category of software so they want to keep things manageable. Omitting features is the easiest way to limit edge cases and keep up with your dependencies.
Mastodon can be janky and it is honestly hard to use, especially of you never used Twitter either. For me, Libreoffice does its thing and ocuppies much less space and less intrusive than Microsoft Office. Open-source projects tend to be less polished than commercial ones due to lack of funding. 98% of open-source projects are completly free, while things like Microsoft license keys cost the price of a lower-end computer
You know that Mastodon is implementing quote posts though, right?
on their website’s roadmap section it says it is planned. I don’t know how much work has been done on that. mean while Mastodon’s userbase is dwindling, and it hasn’t been able to capitalize on the many waves of exodus and twitter controversies for over two years now
it hasn’t been able to capitalize on the many waves of exodus and twitter controversies for over two years now
You’re making the assumption that it wants to.
The goals of Mastodon are very different from Twitter.
If you want quote post right now, without having to wait for mastodon to implement it, why not just use misskey or any other *key fork.
and it hasn’t been able to capitalize on the many waves of exodus and twitter controversies for over two years now
Capitalize in what way? We’re not in a competition with Xitter or anyone else for users.
Capitalize, meaning to translate those new sign-ups into monthly active user, buy doing a better job at exposing the potential of the fediverse and easing up the exploration process of interesting content.
The last release noted that quote posts were on deck for the next feature release.
GNOME.
Specifically their decisions on CSD over SSD (client and server side decorations)
I haven’t really had any other dogmatic issues with projects.
I honestly think they gave developers what they wanted with that, the CSD facilities are easy to use, well integrated and pretty uniform… But on the other hand some software demands (or it at least strongly prefers) complete customization (think WinAmp), and that is now possible.
I really like working with GNOME. Really wished I could find a job working with it again.
I get where you’re coming from but I wish apps on GNOME could look uniform even without everyone kneeling to libadwaita, and we could just get uniform theming on all DEs.
If an OSS project wants to thrive, it would behoove them to implement things that people want. I don’t think there’s a one-size-fits-all solution there, but they shouldn’t be surprised if nobody wants to use their software because it doesn’t do what they want.
The goal for OSS projects is always different. Many projects solve a problem for the developer(s) and them alone. They don’t care about it ‘thriving’ or adding features that don’t align with that problem.
I find it confusing when people complain that other people won’t spend time implementing things that they want. If you want feature A, fork the project and add it. I appreciate that’s easier said than done, but if you can’t or won’t do that, stop complaining about what other people do with their time.
Not all software is the same. Get used to them being different.
