this post was submitted on 11 Jan 2025
-32 points (28.4% liked)

Open Source

32011 readers
104 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
Cloak@lemmy.ml
kevincox@lemmy.ml
CrypticCoffee@lemmy.ml
Lettuceeatlettuce@lemmy.ml
-32
Open source projects are too dogmatic for their own good (sh.itjust.works)
submitted 1 week ago by anticurrent@sh.itjust.works to c/opensource@lemmy.ml
35 comments fedilink hide all child comments
 

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 ??

you are viewing a single comment's thread
view the rest of the comments
[–] CameronDev@programming.dev 5 points 6 days ago (1 children)

Yup, so convincing upstream to take the changes is really the only option, which gets you back to point 1.

[–] avidamoeba@lemmy.ca 2 points 6 days ago* (last edited 6 days ago) (1 children)

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.

[–] CameronDev@programming.dev 2 points 6 days ago (1 children)

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.

[–] avidamoeba@lemmy.ca 2 points 6 days ago* (last edited 6 days ago) (1 children)

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.

[–] CameronDev@programming.dev 1 points 5 days ago (1 children)

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

[–] avidamoeba@lemmy.ca 2 points 5 days ago* (last edited 5 days ago)

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.