There's a theory that goes roughly: People change social media sites when they have accrued so much social baggage (friends, relatives etc that they don't want to be "connected" with, but can't delete them without losing face) that it's easier to jump ship to a new platform with a few core, in-group people.
The same seems applies to software features and preferences. [con't]
Programs slowly accrue new features that they don't necessarily need to have, but have been added because of pressure to ship more units (for proprietary software) or satisfy feature requests (for foss projects). These end up making the software buggier and harder to maintain, but they can't be removed due to business or social pressure.
So instead, someone starts scratch with a new minimal program that attempts to do just the one thing well, without all of the other bells and whistles.
The new generation of GNOME apps are a good example of this. People replacing Mailman with alternatives like Discourse is another. Mozilla Suite ⇒ Firefox and Firefox+Plugins ⇒ WebExtensions are both examples in the same lineage.
I wonder if this is inevitable of FOSS apps though? Can, with a bit of decent design up front and push-back on feature requests, an app stay both maintainable long-term and well-used long term?
@mjog I really want someone to grab the GIMP and remove all the My Web Banner Script-Fu From The Late 1990s and such. And then go extremely hard-ass on usability.
Originally it was going to be a new GTK front-end for BABL (batch image processing) and GEGL (image manipulation) libraries.
It looks now like it'll have a completely new UI toolkit and an entirely different language.
As for forks, I'm basically not going to support version 3.0 when upstream finally release it. I don't want to be on the hook for maintaining the fork side indefinitely, and 2.10.x is good enough for school/workplace deployments.
@federicomena @trechnex @glimpse @mjog we’re writing a new UI toolkit from scratch in D.
We want to avoid any and all glib/gtk based dependencies as they are a PITA to work with on non-Linux platforms. We’re more concerned with having it work everywhere smoothly than promoting Linux as a platform.
I’m the main person working on the code occasionally, taking it 1 step at a time.
I think if it can be delivered within a couple of years, then even if it doesn't match the GNU Image Manipulation Program comprehensively feature-for-feature, it'll still be another compelling free software choice that's easier to use for most people 🙂
@mjog What I am wondering though is that even if you manage to push back against these things and keep it maintainable, can you manage to not burn out to harvest the gains of it?
Projects have been soft dying more commonly due to lack of time and being unable to onboard new maintainers to my experience
@alatiera Yeah I dunno, FOSS projects don't seem in general to have as much ability as proprietary projects in being able to set their own agendas and otherwise generally ignore public opinion when it comes to features and direction.
I wonder if it would help avoiding taking feature requests in the first place - use a forum like Discourse to let people make suggestions, but keep the issue tracker open to the public for bugs only, or maybe even RO in general for people not actively contributing?
@alatiera I've been working on a small vala unit test library over the last week or so with an eye to release it publicly, and was toying with idea of having a policy of automatically closing any issues that were support or feature requests, unless the feature request was accompanied by a MR.
I think this would work well for a developer-oriented lib, but maybe less well for people-facing apps.
@mjog I think extensions are a good solution to this, allowing to implement less important, little-used or complicated features as optional extensions that can be maintained separately.
@LunaDragofelis Yeah, agreed, and that's the approach I'm talking with Geary.
Plugins are like regexs though, in that in using them to solve the problem you now have two problems at an optimistic minimum.
@mjog the problem is a refusal to welcome new/more maintainers, imo.
open source is great, you can contribute to anything. except you can't because nobody will actually let you. have you seen how many pull requests and patches never get merged? this actively discourages ppl from working on open source.
we need to do away with patches/pull requests IMO.
we seem to be in the middle of a really big conversation/debate going on around the fediverse about whether it's more dangerous for FOSS projects if they
1. implement features/complexity too quickly to possibly be maintainable by their "dedicated" developers, much less new "outsider" developers
2. can't respond to the needs of their potential userbase fast enough to be suitable for "regular use" and don't see use while everyone accepts much worse alternatives
@Valenoern I'm not sure that speed has much to do with it - an unmaintainable code base is just as unmaintainable if it got to that state sooner or later.
However, the expectation that maintainers must or should "respond to the needs of needs of their potential userbase" is part of the problem, for FOSS projects anyway. There's no requirement for maintainers to do anything of the sort, but people assume they have the privilege anyway, and refusal (however polite) can be taken badly.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!