pull down to refresh

173 sats \ 9 replies \ @optimism 9 Jan \ on: How FOSS devs maintain their apps? devs
Sometimes if you start using an app, it is uncertain if in long run it would be maintained and worth using it. Technology nowadays is advancing super fast so if you do not adjust, update, improve, your app will die fast.

I disagree on this as a generic thing, let me reason from apps I am or have been a user of:

APKs:

  • Phoenix: a really high quality end-user app that has a relatively relaxed release cycle and I love that they don't overwhelm with updates and bells and whistles.
  • Signal: releases too fast (I've reviewed releases with translation-only updates in the past), limped in on some dumb features, like wallet. They should release less often: "shippable" doesn't mean you should actually ship.
  • Amethyst: Rather slow on feature adoption, but nostr is bleeding edge so I forgive. I think this could use love.
  • Zeus: too many features, unstable for me. Could help from aligning a bit with @nathanael's point to increase reliability.
  • Blixt: also too many features, but you only feel this in UX. Release cycle is fine with me. Stability is much better than Zeus
  • Obtainium: Needs more development. It's very PoC still and it's 3y old. I've been having thoughts of forking it but reluctant to maintain it.

PWAs:

  • SN: too much breakage right now (maybe a phase?), could probably use release process improvement and/or more test coverage.
  • Cashu.me: good feature set, relatively static, could use some more devs or risks obsolescence.
  • Coracle: I had to stop using it because it didn't improve in UX or features.
How do you think it should be a sane procedure for a dev maintaining his apps?
  1. You need to remain the top superuser of your own apps. If you stop using your own stuff, either try to find a new maintainer that does use it, or wind it down. When winding down, take at least 6 months.
  2. If you're maintaining highly used apps or lower level components, spend a portion of your time getting funded. Eventually you'll need it, take it from someone that didn't do it and needs to do gig work to keep FOSS work sustainable. Even if this means maintaining a "here's my lnaddr" page somewhere, do it.
What users should do?

Try to not be locked in, support your developers.

write
preview
100 sats \ 4 replies \ @k00b 9 Jan
too much breakage right now

👀 what's broken?

reply
100 sats \ 3 replies \ @optimism 9 Jan

I mean as in release->a lot of breaks, not permanent broken.

Edit: before I left X, it had switches a couple of times (until they made "paid beta tester mode") where you could opt-in to new features. GitHub does this a lot too. "Frontier mode" sounds cool, lol. (But I can imagine it needing a lot of work)

reply
262 sats \ 2 replies \ @k00b 9 Jan

Ah, fair. That's always been our release process - a sort of communal final QA.[1]

It has been especially bad lately though. My mental map of SN got written to disk while we worked on wallets. I'm still rebuilding the index.

  1. On more than one occasion I recall @siggy47 saying to some new stacker "oh they probably broke that in the release, it'll get fixed soon" aka "these fucking guys ..." ↩

reply
100 sats \ 1 reply \ @optimism 9 Jan
It has been especially bad lately though. My mental map of SN got written to disk while we worked on wallets. I'm still rebuilding the index.

That's what I understood (hence the "maybe a phase?"). It's not criticism really - just something I noticed: basically that as you're moving fast, things get broken.

Perhaps the stacker populace is still too small to stage features through a switch; I'm not sure what scale is needed to effectively do it. There are a lot of power users on here though.

reply
100 sats \ 0 replies \ @k00b 9 Jan

I got you. I didn't mean to sound sensitive as much as I meant to be appropriately concerned. Our release process has no process so it's a good callout.

reply
100 sats \ 3 replies \ @DarthCoin OP 9 Jan
support your developers.

what if I use an app that the dev is not responding anymore?

reply
0 sats \ 2 replies \ @optimism 9 Jan
  • If it's FOSS and you're a dev and you depend on it: fork it, find other superusers, try to sustain it, get funded (even if it's just gratuity.)
  • If you're not a dev and you depend on it: find other superusers, sponsor them.
  • If it's closed source: you probably shouldn't be using this (<insert Stallman face> lol)
  • Find alternatives

Whatever you do: do not whine about it. That doesn't help.

reply
100 sats \ 1 reply \ @DarthCoin OP 9 Jan

I am not such a snowflake to whine :)
But I had in the past a nice app, foss, that was quite stable and with the features I needed for my work. Quite a niche application, so not too many alternatives.
Suddenly the dev didn't respond anymore to requests to small bugs or improvements.
I was using it for a while longer but in the end I just give up and move on to other things.

I am trying to find out why some devs (not all ofc) are losing the care at least to respond to old users with a simple: "sorry, I no longer work on this project. Stop using it." Something like that.

reply
100 sats \ 0 replies \ @optimism 9 Jan

I have quit maintaining 3 big FOSS projects in my life, the first of them I did badly, two I did well. In each case it was because I no longer used the software myself.

The bad case, I just stopped working on it. If you're a user of it, move on the moment you see it stagnates for, say, 6 months, especially nowadays.

The good cases were:

  1. Found a really good maintainer so I transferred repo and package ownership to them. This is still alive today.
  2. Gave people a much better alternative. Told users to migrate and set a deprecation date 1 year after. Had a little bit fallout but when I archived the repo after a year, there were tons of user reports in public on what to do.
reply