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?
"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
wow
https://twiiit.com/valigo/status/2009043573778346188
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
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 ?
To say it with the words of ffmpeg maintainers:
"talk is cheap, send patches"
i deleted my github account — waiting until people move to alternatives
memes are life and life is a meme
hey, where is your optimism?
I didn't like the slash in
@optimism/slolDo it LKML style, just email them the patch files.
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
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.)
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
I disagree on this as a generic thing, let me reason from apps I am or have been a user of:
APKs:
PWAs:
Try to not be locked in, support your developers.
👀 what's broken?
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)
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.
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 ..." ↩
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.
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.
what if I use an app that the dev is not responding anymore?
<insert Stallman face>lol)Whatever you do: do not whine about it. That doesn't help.
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.
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:
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.
If you charge for the binaries, your liability changes.
That would be a bit of a bummer. Getting sued is not fun.
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.
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.
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.
User support isn't "don't even". Answering questions from users is pretty high up there in the ladder of FOSS luxury
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).
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.
Short attention spans meets vibe coding meets grant giving orgs being the only customer that matters
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?
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.
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.