pull down to refresh

I've seen lately a trend in apps that devs are hyped in the beginning, by VCs funding or grants but then when the money are fade away, they are slowly forgot to maintain the apps or add new features. Sometimes is even worse... they don't even answer support users questions and slowly the app became obsolete.

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. So what is the point in making it in the first place?

How do you think it should be a sane procedure for a dev maintaining his apps? What users should do?

100 sats \ 0 replies \ @nout 4h

This year such situation will become much more common, because in the last couple weeks the AI models got to a point that anyone can create working app (on android, iOS, web...) without understanding the programming language or technical details.

Essentially you will get the same situation as we have with cheap hardware from Temu and Ali Express made by no-name or no longer existing companies. But for software.

reply

besides the money running out and maybe just loosing interest. i think the biggest problem in todays world is complexity, technical debt. especially with the hype around ai and vibe coding, it will get worse

a dev should keep it simple, reduce dependencies and users should choose products/apps that are minimal, that do one thing and do it well. this is a unix philosophy, which holds true today

just my 2 sats, i know it is probably not a popular opinion

reply

What about apps that do not answer / pay attention anymore to what users are asking or not even answer support inquiries?
Why devs lose that interest ?

reply

To say it with the words of ffmpeg maintainers:

"talk is cheap, send patches"

reply

i deleted my github account — waiting until people move to alternatives

reply
175 sats \ 34 replies \ @optimism 13h

reply

memes are life and life is a meme

reply

Why do people zap you when you refuse to enable LN wallets here on SNs???

reply
499 sats \ 29 replies \ @nathanael 1h

the horse shows people who can receive right? might take that into account in my future zapping. thank you for bringing this up. didn't realize

100 sats \ 1 reply \ @nathanael 13h

hey, where is your optimism?

reply
21 sats \ 0 replies \ @optimism 13h

I didn't like the slash in @optimism/s lol

reply
21 sats \ 1 reply \ @jivan 8h

Do it LKML style, just email them the patch files.

reply

i sometimes do, but people think email is dead and don't provide one...

reply

the only thing you can do is move on. maybe keep a mental note about the company/developer behind it and if they launch something else in the future keep that in mind

multiple reasons for moving on. could be (as you correctly said in your op) that no money flows and if the dev doesn't use it personally anymore, he has no incentive to develop it further or fix bugs. maybe just part of life, something that interested me years ago, might not be that interesting to me anymore today

reply
171 sats \ 1 reply \ @optimism 21h

I largely agree with you on the first point. The second, I disagree with that if it's built for end-users. I think feature-rich apps are okay, as long as the quantity of features doesn't reduce the quality of the whole (and there is of course a limit to what you can implement.)

reply
100 sats \ 0 replies \ @nathanael 21h

i kinda agree with you. maybe it is more about the mission in the context of a company. does this feature support our mission or not? i personally still prefer simple apps that do one thing well, that doesn't mean they don't have useful features, as long as it supports doing that one thing well. hope that makes it clearer what i meant

reply
210 sats \ 3 replies \ @Scoresby 14h

"Tailwind is growing faster than it ever has and is bigger than it ever has been, and our revenue is down close to 80%."

source

reply

wow

reply

I will never zap you because you cannot be fucked enabling your LN wallets here on SNs.

reply
173 sats \ 9 replies \ @optimism 21h
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.

reply
100 sats \ 4 replies \ @k00b 18h
too much breakage right now

👀 what's broken?

reply
100 sats \ 3 replies \ @optimism 18h

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 17h

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 17h
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 14h

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
support your developers.

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

reply
  • 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

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 20h

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
121 sats \ 5 replies \ @Scoresby 20h

I have never created nor maintained an app, so the following is probably not worth much, but I'm curious about it anyway:

I once suggested to a FOSS wallet app that they charge for the binaries of each release. Still make the source code freely available, but with each new release offer compiled binaries for a paid download. Each time you do a release, users buy the app again.

Now this sounds bonkers, and it probably is, but if the price was at the right level it would be more like users paying for new features than it would be like paying for the app over and over.

The problem is what to do about patches / vulnerability fixes. If a user buys 3.0 and then time goes by and the project releases 4.0, and later a vulnerability is discovered in 3.0, does the project release 3.1 for free?

I liked the idea because it generates a kind of stream of income for the project (as long as they have enough users and are releasing new features people actually want).

Nobody else liked the idea.

reply
102 sats \ 2 replies \ @optimism 20h

If you charge for the binaries, your liability changes.

reply
100 sats \ 1 reply \ @Scoresby 20h

That would be a bit of a bummer. Getting sued is not fun.

reply
102 sats \ 0 replies \ @optimism 20h

The difference is users transforming into customers, so you'll also have a compliance nightmare in many places. Then you need to start gatekeeping your users by location.. and so on.

reply

Another approach is to charge a small fee for github proposals and also other users could upvote a feature request or bug to be fixed with sats.
The items mostly voted will be taken in consideration and also get more sats / income.

I wonder why we do not have such thing in SN.
Users of an app, post requests and all sats goes to devs. Also support answers get back sats.

reply
100 sats \ 0 replies \ @Scoresby 20h

I like this idea, too. Maybe a poll for new features where a vote costs a set fee.

Maintainers of a project may not want to take it the direction that gets the most sats. But if the feature requests were posted like a bounty, with sats awarded when the feature is released, perhaps it could work.

reply
they don't even answer support users questions

User support isn't "don't even". Answering questions from users is pretty high up there in the ladder of FOSS luxury

reply
100 sats \ 1 reply \ @rblb 19h

OpenSource usually works like this: you write something either because you're paid to do so or because you need it yourself. When the incentive to maintain it is gone, the project may sit idle.

Later, when someone else needs the same thing, instead of starting from scratch and spending months or years reaching the same goals, they can build on the work that already exists and move it forward.

In the Bitcoin and adjacent ecosystem, things are a bit unusual since people often rebuild the same stuff over and over. Just look at how many javascript nostr libraries are there, we should invite people to fix/fork or adopt existing projects and use licenses that incentive doing that for profit (like MIT, BSD, CC0 etc).

reply
100 sats \ 0 replies \ @optimism 17h
we should invite people to fix/fork or adopt existing projects and use licenses that incentive doing that for profit (like MIT, BSD, CC0 etc).

Reviving poorly maintained software is a massive headache though! I've done it. Took me 1.5 year of full time work as the new maintainer and a varying set of 4-6 collaborators during that time, willing to spend some time on it too, to remove tech debt / quirks / upstream dependency API changes... The reason I did that was because this software still had a ton of active users and building from scratch and then offering migration would have been even more costly.

However, I would not do it again. Or at least not pick up something that has been shelved for nearly 2 years.

reply
67 sats \ 0 replies \ @k00b 17h

Short attention spans meets vibe coding meets grant giving orgs being the only customer that matters

reply
100 sats \ 0 replies \ @blockdyor 19h

I think devs should listen to users and have a page where they can suggest and vote new functions: the most voted/zapped functions should be implemented (or at least try to).
I ran into something similar with BlueWallet actually. I'm using it less and less because over time they just kept stripping away features. What do you think about that?

reply

There are tools like Renovate which do the upgrading of dependencies for you automatically. The different programming languages might have different tools for this, Renovate is only one example.

reply

APs die if there are not enough users.

LN is the same.

If we dont use LN it will die.

LN and its dev, nodes and wallets are fueled by us using LN.

Here on Stacker News we can all support the LN system by using LN payments.

It's not too difficult to enable your horse and gun- even I can do it and have done it- there are guides on how to get your wallet attached to your SN account.

But @DarthCoin can't be fucked enabling his LN wallet here on Stacker News because he is too fucking stingy and prefers to be a giant fucking hypocrit.

@DarthCoin boasts about how he lives on The Bitcoin Standard- but its all pure bullshit.
He can't even be fucked attaching his LN wallets here on SNs where he so often preaches about Bitcoin and how hes such a big Maxi.

Use LN and help it grow stronger- or be a lazy cunt like @DarthCoin and through negligence, cynicism and selfishness refuse to contribute to the growth of LN by refusing to use it where and when you can.

reply

In the early days of a product, both founders and investors are driven by momentum and vision. But products are not just about building they are about sustaining. And sustaining is unglamorous compared to launching.

A sane procedure for a developer or a company is to treat maintenance as a core part of the business model from day one rather than an afterthought. Plan for the cost and time of keeping the product alive before you even write the first line of code. This means making technology choices that minimize long term complexity not just optimize for rapid release. It also means saying no to features that dilute the mission.

For users the reality is that technology is a bet. When adopting a new product you are not only buying into the current experience but into the likelihood that its creators will still care about it in three years. Look for signs of discipline in updates responsiveness to feedback and transparency about roadmaps. A minimal product with a committed small team will outlast a flashy product built on shaky enthusiasm.

reply