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.

Show thread

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?

Show thread

@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.

@mjog @federicomena it is in the pipeline. 🙂

@trechnex is heading up the 0.x releases, which are forks of the GNU Image Manipulation Program 2.10.x

@Clipsey is heading up a separate effort to do a complete UI redesign & rewrite, and that will eventually depracate the forks.

@glimpse @mjog @federicomena @trechnex at this point it’s more an entire application rewrite. Starting from scratch lol

@Clipsey @glimpse @mjog @federicomena accurate 😅

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.

@trechnex @Clipsey @glimpse @federicomena Heh I hope that goes better than Mozilla's early fork-and-rewrite of the open-sourced Netscape codebase did! 😅

@mjog @Clipsey @glimpse @federicomena true, true. 😅

I guess the set up we have is best described as "two projects kept under the same tent"

@federicomena @Clipsey @glimpse @mjog Indeed.

My experience tells me the scope is probably too big, but I have been proved wrong by the very talented people in this project before. 🙂

@trechnex @Clipsey @glimpse @mjog I hope this is not confounding "effort to finish the port to GTK3/4" with "effort to write a new toolkit and port everything to it". Would love to know more details.

@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.

@Clipsey @trechnex @glimpse @mjog Wow, that's a lot of work. It looks like D has features which would be useful for a toolkit. Best of luck 😄

@federicomena @Clipsey @glimpse @mjog thank you.

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.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!