Skip to main content
Dear open source users,

If the author of your favorite open source app has announced they stopped developing and supporting the app (because they're frustrated and possibly burned out), please don't suggest they do more free work so that you can continue using the app.
Instead, consider thanking them for their past work and let them know that you enjoyed their app.

Regards,
another open source developer

4 people reshared this

Jeff MacKinnon
I would expand that the reason is immaterial. I started building a theme that is open source for pelican, but if I stop developing it because I found a new shiny thing, that is my prerogative.

The fact that anyone develops these amazing tools because they want to do something good/cool/etc is amazing and gives me faith that there are good in people.

I miss the late web 1/early web 2 era where I felt there was more good on the web.
Kristian
Yes. And also: If the tool they built mattered to you, maybe not just move along trying to look for "another alternative" but actually trying to figure out how to keep that alive, how to revive, fork, maintain, fund, ... a process that keeps this project from fading away because the lead developer had to pull out of it? In the end, a lot of this current dispute feels much more like consumerism than real "FLOSS community". 😟
Csepp 🌢
The harsh reality is that people might depend on the software, so indeed in that case just saying "thanks" and moving on is not the best option. Someone has to pick up the mantle.
cketti
That sounds like a problem of the people depending on the software, rather than that of the original developer. You can't expect enterprise-level support for having paid 5 bucks (or nothing at all).
Csepp 🌢
Well, it has a bit more layers than that. First, the user might not be aware of the risks. The license is not enough IMHO, after a certain adoption threshold, if the readme doesn't communicate the (lack of) support or stability, then the fault partially lies with the project lead(s).

It's like feeding birds. If they get used to it and then you take away the bird feeder on a whim, it's not the bird's fault. Obviously that's an exaggeration, but hopefully you get what I mean.
cketti
Developers generally don't trick people into depending on their software. If you do depend on it, that was your choice. If you didn't foresee that the software might be abandoned at some point, that's on you. Really, that's not specific to FOSS at all.

But with open source software you at least still have the source code and can continue development (or pay someone to do it for you).
Csepp 🌢
Re:
> that's on you
I find that assigning blame is less useful than trying to figure out how to avoid the problem. 🤷
No one claimed anyone is being tricked, the point I was trying to make (maybe badly), is that it's possible to communicate issues in advance, before they pile up.

And yup, it's not specific to FOSS, all projects should be transparent about their sustainability. That only reinforces that issues should be communicated in advance, whatever their nature may be.
cketti
> That only reinforces that issues should be communicated in advance, whatever their nature may be.

You're asking for people who already basically work for free to do even more work, so that you aren't inconvenienced too much.
I'd say you can certainly hope for that, but you shouldn't expect it, much less demand it.
Csepp 🌢
Adding a simple sentence to a readme is not a lot of effort. 🤷
Nor is writing a short "hey i'm having difficulties, don't expect a new release any time soon".
And no, that's not why I'm asking. *I* understand software development. A random person who downloads [insert software name] from a repo (or even from an official project page) might not. I hoped that was clear.
Devs and users alike are not exempt from societal norms or having to communicate and listen.
Csepp 🌢
IMHO preventing contributor burnout is a more important problem than treating it after it already happened, simply because prevention is nearly always the better solution to any given problem.
If the dev feels like they are expected to do free work, they can lessen the expectation by telling their users they can't work on the project, instead of working on the project until they burn out.
Hypolite Petovan
You can armchair figure this issue out all you want, at the end of the day the work needs to be done by someone™. You don't get to choose that someone, you don't get to choose their communication strategy or eventual lack thereof, and you don't get to tell them what they should have done afterwards.

Like @cketti said, all you said is right, but it's wishful thinking in the case of open source because the work itself needs to be rewarding on its own, and if some devs don't do this kind of preventative work, it's because they don't find it rewarding in itself, no matter where it may lead them down the line.

I'm grateful # has someone like @Michael Vogel trudging along day in and day out because my own contributions have been inconsistent to keep them rewarding, and I wouldn't be able to sustain the project on my own. However, I'm not sure what kind of preventative work we could do to keep Michael trudging along, so far he's been wonderful keeping at it, but almost everything rests on his shoulders.

Does it mean Friendica is doomed if he ever quits for any reason? Absolutely, and I don't believe there's anyone that can prevent that, short of doing all the work Michael is doing by himself without any other reward than the work itself.
#Friendica @Michael Vogel @cketti
Michael Vogel
Well, I think that everyone is replaceable. I saw it in our company. Over the last years we often had situations where coworkers left and we thought: "Now we are doomed! No one know that product, the customers will kill us!". Until now this hadn't happen.

Concerning the reward: recently I received several kilograms of chocolate from a user. So that's fine :-)
A lot of different types of chocolate: Bars, Easter chocolate, muesli, ...
Kristian
... projects driven exclusively by individual volunteer enthusiasts in their spare time) and/or try to strive for actually _getting_ to a point where this sustainability is even possible. Like: What would it take to make FairEMail, Friendica, Pleroma, Diaspora, ... more "sustainable" than, in example, Twitter or Flickr that have been around for 10+ years...? 2/2

@heluecht @cketti @csepp
@Michael Vogel @Csepp 🌢 @cketti
Michael Vogel
Friendica is a good example. It has been created by Mike Macgirvin. But several years ago he decided to leave the project for a new one. But other people took over. Same happened with Statusnet that developed into GNU Social. Also none of the original Diaspora developers are still active. Several years ago the community took over.

With commercial systems you can't take over a project when there is the danger that it will shut down. With open source projects you can take over the project.
Kristian
Yes. But GNUSocial also is a good example for what I meant: For most people I, in example, know on Twitter or Flickr, they have had "stable" accounts and reasonable stable networks there for > 10, in cases for > 15 years. I know _very_ little (no?) people that have been active with a stable crowd for that long in any of the open networks, no matter whether identi.ca, gnusocial or Diaspora, let alone using this as their main means of communication... 😐

@hypolite @csepp @cketti
@Hypolite Petovan @Csepp 🌢 @cketti
Michael Vogel
I had an account on Google+ and on App.net. I used both very intensive and there had been a nice community. but the companies behind those two systems decided to shut the service down.
Ian Molton
@Kristian @Michael Vogel @Csepp 🩸 @cketti @Hypolite Petovan

Make a donation.

OSS will outlive CSS. Every time.
@Michael Vogel @Hypolite Petovan @Kristian @Csepp 🌢 @cketti
Kristian
GNUsocial has been pretty much on its way down with ActivityPub and Mastodon around. My instance has closed down a few years ago. Similar things seem to happen to Diaspora at the moment, for the same reason. Who should I possibly have donated to? The developer of the software? The admin running that particular instance back then? What kind of impact would my donation have made do change that (or even to prevent right that from happening)?

@heluecht @hypolite @csepp @cketti
@Michael Vogel @Hypolite Petovan @Csepp 🌢 @cketti
Hypolite Petovan
The simple answer is that it would take a particular astral alignment. FLOSS is organic, with a mostly horizontal structure that doesn't allow for central planning at all. More generally, nothing can be expected to last forever, neither corporate platforms nor FLOSS alternatives, so a better question should be "what kind of platform do I want to be on right now" and "what is my contingency plan is when the platform I'm on inevitably declines/disappears?".

The story of Google+ is a good example both of a corporate platform disappearing, and of the flexibility of its former users who found their solace again, either on the Fediverse or elsewhere. Your home on the Social Internet may move, but at the end of the day you're still you.
Kristian
How did we manage to get things such as Wikipedia, Debian or larger GNU/Linux distributions to "fly"? Of course at least Linux, too, is suffering from fragmentation and having way too many different "just because" - reimplementations of virtually everything, but maybe in the last couple of years we just unlearnt how to focus on shared goals? I'm not sure here, and maybe this sounds more harsh than it is intended to, yet still it feels quite ... weird.

@heluecht @csepp @cketti
@Michael Vogel @Csepp 🌢 @cketti
Hypolite Petovan
That's an obvious question, but I'd like to ask you another one to provide some perspective. For each stable project like Wikipedia or main Linux distributions, how many other projects didn't make it? We weren't better at focusing on shared goals before, it just that only the memory of surviving projects remains from that time. It's called survivor bias and it often leads to the wrong conclusions regarding the success of any endeavor.

I get your need for stability, but so much of success is about being at the right time in the right place that individual behavior matters very little in the long run, so the best you can do is cheer on the projects you like and plan for a move if they fall apart.
Admin
that's a total passive view of social change/challenge

Are you a fan of # am cureuse about people who think like this - it's very # while often seemingly being radical.

It's kinda why we are in such a mess I think, what do you think?
Hypolite Petovan
I don’t know what POMO means (post-modernism? I’m still not familiar with the concept) but what I know for sure is that it isn’t “kinda why we are in such a mess”. It doesn’t even matter what kind of mess you are talking about, it is such a simplistic take it can’t be right.

What I am suggesting is to do whatever you can at your level and not worry too much about the grand scheme of things because of both the complexity to grasp (and the obvious pitfalls associated with it when biases and fallacies kick in to replace actual understanding) and the limited agency at the individual level.

I joined Friendica in 2016 specifically because I could contribute code to it, and we’ve made strides in code quality and stability since thanks in part to my work. But contribution isn't limited to code, we have plenty of tasks that can be accomplished by non-devs like translating the interface, running a public node, reporting bugs, spreading the word, sending chocolate to Michael…

But I also know this project is precarious. It doesn’t prevent me from working on it though.
Csepp 🌢
re: "Do what you can"
That's pretty much what I said, just focused on the communication aspect. 🙃
Like you said, "do what you can" should also be taken to apply to non-code contributions, including writing docs, helping out on issue trackers, and keeping the community healthy. If it improves things, it's worth doing.
Hypolite Petovan
"If it improves things, it's worth doing."

My issue with this phrasing is that, especially for non-code contributions, you can't possibly know if and how it will improve things. So there's the risk of overthinking it while not doing anything like in this thread. Just do the things you like doing is plenty enough already, project stability be damned.
Csepp 🌢
That's where guidelines come in handy. In my eyes, it's not much different than adding a CoC, or using issue templates. It just makes things smoother at very little cost to the contributors.
If just jumping head first into the project and not managing expectations leads to burnout, then I don't understand the opposition to preventing that, especially if the dev's enjoyment of their work is so important.
Csepp 🌢
Like, you write a two sentence update every so often and maybe add a sentence to the readme, and it lifts the pressure from you. Worst case scenario you wasted 10 minutes writing it. 🤷
Csepp 🌢
If that much communication leads to decision paralysis, we could write some templates. It's like licenses. 99% of devs just use an existing one and there are several tools that help them choose.
This could be that simple. Think the mood setting on Deviantart updates, if you've used that. Just put an emoji in the commit message or something. 🤷
There are definitely better solutions than the status quo.
Hypolite Petovan
There's a fundamental difference between a paid job burnout and an open source burnout though. In the former case, the pressure is external, applied by the employer. In the latter case, the pressure is entirely self-applied. If someone self-assigns the mission to maintain a particular project even to the detriment of their own well-being, I don't see any guidelines/CoC that can prevent that.

Since it's entirely dependent on a developer self-awareness, external input matters very little because if a developer doesn't realize they are spending more time/emotional work than they are ready to until it's too late, what are the chances people who know them even less would?
Ian Molton
Whilst it's true that there is no *enforcement* as such, I think open source users can, and often do, put pressure upon developers.

Also, often those users are also the developers employer, which can be unhealthy.
Admin
an interesting example of the # trying to solve the geek problem. The is no way out of this mess, trust me I have been working at social technology for 20 years.

What happens when we take the "problem" out of # what would # look like?

If your interested in doing this then this book is a good step https://archive.org/stream/in.ernet.dli.2015.101521/2015.101521.The-Sciological-Imagination_djvu.txt
Hypolite Petovan
“Geek problem”? Another abstraction you didn’t stop and ask if anyone in this conversation is up to speed on your jargon.

At the moment I do not trust you for anything, so I’m going to let this down and continue doing my thing.
Kristian
... entities starting to enforce compliance with certain rules, not all out of shady reasons? Is there a risk of FLOSS "spare-time" developers burning out once they reach a point where things _have_ to be done and end up being annoying and tedious work rather than self-rewarding fun? What's the motivation of getting FLOSS across this mental line then?

@heluecht @witchescauldron @csepp @cketti
@Michael Vogel @Csepp 🌢 @Admin @cketti
Hypolite Petovan
Yes, there's always a risk for smaller projects. I believe Mastodon is compensating at least one developer full-time on the project, which I believe gives them a margin to react to external pressure like you mentioned. But any project under that threshold is susceptible to a changing requirement landscape.
Kristian
Been reading the thread and felt like having not much to add, but feel conflicted here, talking internal vs external burnout: What happens to a FLOSS developer if external forces start "pushing" you? Like, in case of FairEMail, Google demanding certain criterias to be met before an application gets approved to the store? Or F-Droid doing the same, just more transparent in a different direction? Or, in other cases (GDPR ...), external ...

@heluecht @witchescauldron @csepp @cketti
@Michael Vogel @Csepp 🌢 @Admin @cketti
Csepp 🌢
Also maybe I underestimate people, but I don't think developers have a clear perspective on how well regular folks understand how software projects are developed.
Realistically, just complaining about their lack of understanding won't make most of them understand. The most effective way to make this information reach them is via the channels where they read about updates and docs.
Csepp 🌢
This isn't an all-or-nothing problem by the way. There are a lot more options than just "enterprise level support" and "project developed for the lulz and abandoned out of the blue".

Like, if the dev is burning out, they can communicate that before they completely give up on the project.
⇧