
The struggles of an open source maintainer - ngaut
http://antirez.com/news/129
======
souprock
He missed a big one: you have no way to stop Linux distributions from hacking
up your software, and you'll suffer the consequences of whatever they do.

I hit this with procps. (a package with ps, top, vmstat, free, kill...) It was
horrifically demotivating, helping to end my involvement as the maintainer
from roughly 1997 to 2007. (the other big issue was real life intruding, with
me joining a start-up and having 5 kids)

I had plans for command line option letters, carefully paying attention to
compatibility with other UNIX-like systems, and then Red Hat would come along
and patch their package to block my plans. They were changing the interface
without even asking for a letter allocation. I was then sort of stuck. I could
ignore them, but then my users would have all sorts of compatibility problems
and Red Hat would likely keep patching in their own allocation. I could accept
the allocation, letting Red Hat have control over my interface.

Red Hat sometimes added major bugs. I'd get lots of complaints in my email.
These would be a mystery until I figured out that the user had a buggy Red Hat
change.

Patches would often be hoarded by Linux distributions. I used to regularly
download packages and open them up to look for new crazy patches. Sometimes I
took the patches, sometimes I ignored the patches, and sometimes a wrote my
own versions. What I could never do was reject patches. The upstream software
maintainer has no ability to do that.

The backlog of unresolved troubles of this sort kept growing, making me really
miserable. Eventually I just gave up on trying to put out a new release. That
was painful, since I'd written ps itself and being the maintainer had become
part of my identity. Letting go was not easy.

Maybe it had to happen at some point, since I now have more than twice as many
kids, but I will be forever bitter about how Red Hat didn't give a damn about
the maintainer relationship.

~~~
stickfigure
As the parent of a startup and one singular demanding child, I have to ask...
10?! Wow! Nevermind _why_ , I want to know _how do you get anything done?_ Do
you have staff? Do you have personal time to yourself, or with your wife? How
many soccer games do you attend in a given week? How many bedrooms does your
house have? How many of your kids are turning out to be programmers?

Forget maintaining software, I want to know how you maintain your existence. I
don't think I could survive.

~~~
flurdy
I also want to know how he manages to do any work with 5 or even 10 kids.

I realised I no longer had any spare time anymore once I had my first
daughter. Then we had another and I realised I must have had so much spare
time with just the one kid...

How lots of my family and friends manage time with 3 or more kids I don't know
as you are then outnumbered.

5 or more seems impossible. You must either be a drill sergeant super
efficient or the opposite, super relaxed and let the kids sort themselves out.
Or rich and delegate it to nannies/au-pair etc.

I do appreciate now that by having two kids that they mostly spend their time
at home playing with each other, as opposed to when we had just the one when
we had to always play with them. I guess that scales well with more kids.

But I still do feel guilty that I am not always joining in. And have to be
more selective of which school performance etc either one of us can attend. I
am not sure my conscience could handle missing out on lots of these with more
kids by allocating much less of my full time to each kid.

~~~
croo
From zero to one child the change in regular life is astounding. You become a
parent and in the process you lost a lot of your free time and lose all
spontaneity from your life. From one to two children you will notice that you
had some free time left with one but now you really _really_ don't have any
more. No more evening movies or hour long coffees with wife. You wonder what
childrenless people even do with the ultra metric shitton of time they have as
you cannot imagine anymore. You simply don't have enough time for two kids and
you have to learn to manage and optimize what you have to do the best you can.

From two to three children... nothing really changes anymore! You won't get
more responsibilites as you already have them and no less time as you already
don't have any :)

~~~
wbl
I got a cinematic education from my dad one movie a week on Saturday night.
Children can be involved in adult activities.

------
makecheck
People seem to have a serious lack of understanding when making requests of
others.

\- When you send an E-mail, at least _imagine_ that the recipient may have
_literally hundreds_ of other messages to dredge through and the time required
to respond (and detail of response) may reflect that. Not personal, don’t get
mad at them.

\- When you send an “instant message”, it may be instant for _you_ but for all
you know the recipient is deep in the middle of something and won’t respond
for awhile. Not personal, don’t get mad at them.

\- The recipient may be on the other side of the planet. Err on the side of
extra information so you don’t wait days for a response that just has to ask
you for more.

\- When you file a bug, “thank you but do some homework”. A person dealing
with 1000 other things will _not_ have time to hand-hold you through all the
things you’re not telling them yet. Be precise and complete. Be reasonable
about when/if to expect a fix.

\- And for that matter, in retail, or traffic, or 100 other things in life,
you _don’t know as much as you think you do_ about what other people are
dealing with. Stop for a second. Imagine their situation. That person not
_instantly serving you and only you_ has a dozen other things going on.

~~~
senorjazz
> \- When you send an “instant message”, it may be instant for you but for all
> you know the recipient is deep in the middle of something and won’t respond
> for awhile. Not personal, don’t get mad at them.

People don't get it. If they said a DM / IM or any program which is considered
a "chat" app they expect instant replies.

I run a single person software company. I used to allow people to contact me
for support any and all chat programs. So for paying customers you can magnify
that "expect an instant reply" factor. People would get quite annoyed,
regardless of whether it was Sunday, or 3am in the morning for me.

For that reason, only email and forum support is no offered. Never had a
complaint since about wait times. People expect to wait after sending an
email. They expect to wait for a forum post. They do not expect to wait for a
chat / IM / DM response.

------
Sir_Cmpwn
I don't maintain anything as big as Redis, but I've faced many similar
problems all the same and I think I have an approach which makes it palatable.
I wrote about my approach at length here:

[https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-
proje...](https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-
projects.html)

But the main thing is that almost all bug reports, feature requests, and so
on, get sent to /dev/null. Users who care about a problem are expected to work
on that problem themselves. In the case of software like Redis, pretty much
everyone reporting a bug is also qualified to fix that bug, so it works
particularly well.

Then I focus only on helping new contributors get their bearings and making
regular contributors happy and comfortable with their work on the project. So
far this approach has been very successful for me - I don't get burned out,
and neither do my contributors, and we have happy, healthy communities where
people work at a pace which suits them best and aren't stressed or
overwhelmed.

Sure, lots of feature requests and bug reports get neglected, but I think the
net result is still a very positive impact on the project. The occasional
drive-by bug submitter provides far less value to the project as someone who
writes even one patch. Focusing on keeping the people who create the most
value happy makes for a more productive project and a better end result. Some
people are put out by the fact that their bug report, feature request, etc
goes unanswered, but I can quickly put the guilt out of my mind by reminding
myself that ignoring them is doing a benefit to the project. And in practice,
I generally have time to give people some words of encouragement and a nudge
in the right direction towards writing a patch without burning myself out.

~~~
outime
>In the case of software like Redis, pretty much everyone reporting a bug is
also qualified to fix that bug, so it works particularly well.

There are a good bunch of people who have never written any C and even more
people who have no idea about the internals of Redis, yet they are Redis users
and they do find bugs. I wouldn't expect those users to write a patch for
every bug they find to be honest.

~~~
Crinus
I think the idea is that given enough users, the bugs who will be encountered
by non-fixers will also be encountered by fixers so they'll be fixed,
otherwise they are so rare as to not be worth the effort of wasting time with
useless non-fixer reports to find the useful non-fixer ones.

I'm not sure how i feel about that TBH, personally i'd like to know about bugs
even if they do not come with patches but at the same time i understand not
wanting to be bothered by wading through useless reports.

Perhaps there should be end user oriented bugtrackers that look more similar
to something like a hybrid between a forum and a reddit/HN post with voting
(no downvotes though, kinda like GOG's wishlists) so that developers will have
a rough idea where to focus next and "locked" (but perhaps visible, at least
for FOSS projects) traditional bugtrackers where end user entries migrate (and
linked to) once developers decide that this will be worked on.

It wont solve all issues, especially with people potentially going "why aren't
you fixing that bug-but-really-a-feature-that-requires-rearchitecting-the-
entire-thing that has 897482959204 votes and instead work on whatever-else
that Nobody Asked For(tm)?", but i guess you can't fix entitlement with
technical means.

~~~
gtirloni
All properly filled bug reports are useful.

This mentality that only writing code matters needs to stop. Open source
projects (or any project for that matter) is way more than just writing code
and the people doing the "other" work need to be recognized and encouraged to
continuing that.

The lack of such people is exactly the major cause of burnout from maintainers
who just want to code.

Not replying to all your points directly, just making a general statement
about this whole thread.

~~~
Crinus
If you aren't replying to my points why are you making a reply to my comment?

Yes, all properly filled bugs reports are useful. The important part here is
that "properly" word though and on a popular project they can be hard to find.
What is worse, this incentivizes people to file the same or similar bugs twice
(or more) since they can't find the duplicate (in which case, properly or not
doesn't matter, you already demonstrated your belief that your time is more
important than whoever will have to wade through the bugs to find your
duplicate).

Also while code isn't the only thing that matters, it is the thing that
matters the most - the software doesn't exist without code, but it can exist
without everything else - and the programmers who write the code are those who
make the final decision on what ends up in the software (assuming FOSS made by
volunteers here, of course, not FOSS or closed source software made by
employees - although even in that case, often the developer who writes the
code is the one making the decision anyway).

~~~
gtirloni
It's always an option to go the proprietary route and release your code as
shareware. It worked for a long time. Why bother to release the source if it's
such a hassle?

~~~
Crinus
Sadly it worked until users were taught to expect everything for free (see how
every single time someone posts something here or on Reddit that costs money,
there is at least one post - often more - with free "alternatives" upvoted
near the top) and other developers spreading FUD against you if you do not
release the code - even if you give your software away for free.

Of course if you are going to receive harassment either way, might as well get
paid for it.

------
mholt
Man. I can relate. Open source projects are roller coasters. It's great when
loads of people start using it... and terrible at the same time. It's
validating to see people using your work, but sometimes you just want to
submit your paper to NIPS rather than deal with what you think in the moment
(and, frankly, in hindsight too) is a dumb issue:
[https://github.com/mholt/caddy/issues/1680#issuecomment-3027...](https://github.com/mholt/caddy/issues/1680#issuecomment-302719323)

I wrote up my experience from one wave of negativity a couple years ago:
[https://caddy.community/t/the-realities-of-being-a-foss-
main...](https://caddy.community/t/the-realities-of-being-a-foss-
maintainer/2728)

It still haunts me to this day, but my attitudes are finally trending more
positive about the whole thing.

~~~
kbenson
One of the major benefits of Open Source is that the user doesn't need to get
a hold of the developer. It's always possible (or should be, if they're
leveraging open source well) to patch a problem locally and build a fixed
version their self. If they don't have the ability to do so, they really
should at least have someone they can contact and pay (probably an exorbitant
amount if it's an emergency) to do that for them. It's the open source
equivalent of an application support contract or warranty.

~~~
voltagex_
How would you go about finding someone to contract and pay for say, Firefox?

~~~
mathnmusic
Some folks I know are building polyglot.network as a FOSS-only software
development agency. Early stages but you might wanna check them out.

~~~
drieddust
They seems to be insanely Cheap at $1999 for 160 hours of Dev work.

How do the make money?

~~~
mathnmusic
They only pick up FOSS tasks for which they can find multiple customers.

------
sheetjs
We ([https://sheetjs.com](https://sheetjs.com)) maintain some reasonably
popular projects (our most popular, [https://github.com/SheetJS/js-
xlsx/](https://github.com/SheetJS/js-xlsx/), has over 15K stars and sees
millions of downloads per month).

It's important to remember why you are involved in open source. If those
circumstances change, you should ask why you continue to remain involved. As
soon as you lack a satisfactory answer, it's your cue to stop.

Many large open source projects start out as a passion project or a solution
to a specific problem that the original developers faced. Over time, other
people face similar issues and rally around your solution and it is really
easy to fall into the trap of bearing their burdens. This is a bad response.
Other people using your open source offerings do not create any sort of
obligation on your part to care or respond to their concerns.

If someone really cares enough, they will incentivize your continued effort
(like money or other considerations). It is unfortunately cultural taboo to
ask some of the more vocal critics to pay, but setting up that dialogue at
least shuts down most of the comments.

IMHO the origin of most of these issues comes from the very thing that drives
many people to open source in the first place: personal branding. If you
remove your personal identity from the equation, it's a lot easier to "turn
off notifications". Rants and criticisms are directed at this mystery
character, not you personally. Since you are not personally tied to the
project, working on open source feels like a distinct activity and is judged
on its merits. You don't feel the same sense of obligations since you don't
personally feel like you are disappointing the user base.

~~~
ralphstodomingo
Off-topic: I've used js-xlsx before, and didn't have any problems with it.
Thank you for your efforts.

~~~
skrebbel
Same! Js-xlsx is lovely, thanks for your efforts.

------
monksy
It sounds like this is similar to the harassment that he received over redis
using the terms "master"/"slave". (Even DHH jumped in and used his platform to
harass)

[http://antirez.com/news/122](http://antirez.com/news/122)

For someone that is giving parts of their life to help others, the amount of
entitlement that people expect is unbelievable.

------
peterwwillis
I think people are getting way too upset over GitHub features like issues &
PRs, and the desire to please others. If you work on an open source project
and you're not getting paid for it, you really need to divorce yourself from
the demands of users. You have to assume that literally no one will use the
software and just make it for yourself. If it becomes popular and you get
feedback and contributions, great! Hopefully you can develop relationships
that will lead to co-maintainers and such. But if it starts to feel like a
struggle, just re-focus on what _you_ want to get done, on your timeline.

~~~
thrower123
Too many people aren't aware that you can say no, and not do something if you
don't want to or if it is a bad idea. Especially if nobody is paying you.

Even for people that are paying you for a product, sometimes you really need
to say no, that is how it works, and no, we are not going to customize it for
your particular workflow.

~~~
Matumio
Just saying "no" already can cost too much effort, because it involves making
a decision that you'll want to justify. It takes effort to report an issue and
even more to make a pull-request, so you don't want to reject them without a
good reason, without really understanding it. Except for some obviously sloppy
reports that would be just rude.

The easier option is to simply not respond. Even this leaves some level of
stress, because we've all had our own bug report or pull request ignored. We
don't want to this uncaring person on the other side. But sadly, ignoring
other people's requests is the best option for involuntary maintainers to
protect themselves.

The final option is to just hand out the keys to whoever is the most active
contributor, and stop trying to control the direction of the project. This
will get the stress-level down. You may not like this option, but it's much
better than burning out.

------
smitty1e
1\. I've never upped my game enough to contribute to a project, much less put
something on github. So, to the vast swath of people who are cooler than I:
thank you.

2\. TFA really gets at the classic issue of working vs. managing. Technical
people tend toward being better at the former. Context switching between doing
the work and managing the work is hard. Punting the management and diving into
the work almost seems an escape.

3\. The code itself makes this point to us. We can define an integer, and
there it is. But when we need a list of integers? Look at how the management
required just exploded.

4\. Management sucks, but a management vacuum is a void, indeed. Let us be
thankful for managers who don't suck.

~~~
DannyBee
(I've been in the situation he describes, unfortunately)

I agree a lot of that article feels like two things (but i'm not going to
remove all nuance - there are clearly other issues):

1\. The issue of being forced to be a manager when you want to be an
individual contributor, and even worse, feels like being forced to be a TLM
when you want to be an individual contributor.

2\. Even if you take away the aspects of #1, it feels like a lack of notion
that individuals don't build software past a certain point. I mean that in the
sense that, IMHO, past a certain point, all software becomes team built (or
fails), whether you are the manager or not. High level software engineering is
a team sport, not an individual one. That is true even outside of management -
it's also about technically mentoring and growing the team that builds your
software so you can rely on them instead of you (which is not just a manager
task).

Every person you mentor into someone capable of doing the kind of work you
want done is going to increase productivity on the software a lot more than
you trying to do it yourself. Over time, they will also be able to build your
team.

Over time and scale, if you don't have a team to rely on, and actually start
relying on them, you will just feel crushed. Utterly utterly crushed.

There is no path out of it that involves getting better yourself. You simply
cannot scale past a certain point and there is no way out of it.

~~~
rectang
It's not for everyone, but there's a way out: accept existential "futility",
as Antirez puts it.

Let your project be less than it could be.

~~~
DannyBee
In my experience, this doesn't actually work. You basically have to close up
shop.

Otherwise, the negative vitriol/etc of people who won't accept that is
amazingly overwhelming.

Put another way, imagine, in a housing thread on HN, any time someone says
"yeah, but i'm just happy to have my town stay the way it is. We don't want
growth, we are happy, and we should be allowed to have that choice", what the
response is.

While different situations for sure, it's the same _type_ of response you get
when you say "yeah, i'm happy with my open source project the way it is,
sorry".

~~~
rectang
> _You basically have to close up shop._

If you can't come to peace with that possibility, this approach isn't for you.
Having to close up isn't an inevitability, but grappling with that prospect is
an essential exercise.

It's truly not easy for ordinary humans to withstand the vitriol of a furious
userbase. So, remove yourself from the channels where that vitriol gushes and
roils.

The key is avoid making promises you can't keep -- either explicitly or
implicitly. Putting a project on Github, home of "social coding", makes it
hard to tune out the din. So... maybe don't keep your project on Github.

~~~
DannyBee
"If you can't come to peace with that possibility, this approach isn't for
you."

Sure, but i mean in the sense that what you suggest is not a viable method for
a lot of projects, unless, as you say, they also disconnect completely from
the world.

That is not the same as existential futility - it is going off grid.

~~~
rectang
I vehemently disagree with this false dichotomy that either a project must
strive endlessly or exile itself. Gradations are possible, and the way you
achieve them is by strategically choosing the terms of engagement.

Embracing existential futility puts you in a state of mind to accept the
consequences of _subsequent_ concrete actions which limit future prospects of
glory.

~~~
DannyBee
You can vehemently disagree.

" Gradations are possible, and the way you achieve them is by strategically
choosing the terms of engagement."

In my experience, you are simply wrong. You don't get to actually make this
happen. You may _want_ it to happen, and i agree it would be very nice. But it
is also unrealistic, in the same way lots of polarizing things are but
shouldn't be. So you may not like that dichotomy, but in my experience, it is
the practical effect.

I'd love to see your examples of projects that are both fairly successful and
choose somewhere along the gradient you have in mind.

------
Sean-Der
I have only been doing Pion
WebRTC([https://github.com/pion/webrtc](https://github.com/pion/webrtc)) for a
year, but the hardest ones for me have been

* Relationships tied to the project

It sort of burned me out when the first contributors moved on. I have always
been on the other side though, interests change or you change jobs.

* Every user issue is urgent.

It is hard figuring out what the most important thing to work on is. If a user
takes time to file an issue it is causing them issues. I just have been on the
other side and it doesn't feel great to be ignored.

* Community members with different communication styles

People aren't so much assholes, but just communicate differently. It is really
hard to mediate, no one is at fault but I just hate seeing people leave/get
burned out from it.

~~~
cerberusss
As to hard figuring out what the most important thing to work on is:

I have some code on Github and got a change request. I just replied that I can
do it for my currently hourly rate. That makes priorities clear.

~~~
Sean-Der
I don't want to bring money into it though. It personally makes me happy that
is free of any financial pursuit.

It is nice to suspend disbelief and just all work together on making things
that make people happy :)

~~~
cerberusss
Yeah, sometimes money takes away the joy :)

------
marknadal
So very true!

I also maintain 10,000+ GitHub starred OSS database
([https://github.com/amark/gun](https://github.com/amark/gun)), and can relate
to a lot of these points.

Worse than the jerks, though, are the bike-shedders. It is emotionally much
easier to confront jerks, even though it is hurtful.

But the people who "Why isn't this written in X language?" or "Here's a PR to
turn tabs into spaces" are honestly well-intended but naive and short-sighted.

Explaining to those people why you have to reject their PR _because it
provides no additional value and is purely an arbitrary distraction_ takes
quite a bit of time trying to be delicate, but is nearly as much waste of
time.

------
sergiotapia
I own a 2.3K star Github repository
([https://github.com/sergiotapia/magnetissimo](https://github.com/sergiotapia/magnetissimo)),
that while trivial in it's implementation, it's pretty useful to a ton of
people.

There are a few core contributors to the project now and a Discord server as
well and everything in this article rings true to me.

It becomes an obligation of sorts and you definitely feel like you're letting
people down, especially when it comes to people who have taken the time to
contribute and share feedback, let alone people who actually open PRs.

What I think can help is having more core contributors with write permissions,
share the load. Or be up front in your readme and say, "I only check this once
a quarter".

~~~
simonebrunozzi
FYI, it seems that your [https://sergio.dev/](https://sergio.dev/) is down.

~~~
sergiotapia
Thanks - it's not set up yet, I'm trying to figure out a free blogging
solution that requires zero code (like Hugo and such), more like hosted
Wordpress for free.

------
tlrobinson
> Sometimes I believe that software, while great, will never be huge like
> writing a book that will survive for centuries. Note because it is not as
> great per-se, but because as a side effect it is also useful… and will be
> replaced when something more useful is around.

That's an interesting point and thought experiment: what piece of software
currently exists that will still be widely used in a century? And what's the
oldest software that's still being used currently?

~~~
jonathanberger
Unix. Email. TCP/IP. Just taking an initial stab.

~~~
kbwt
All of those will be around not because they are good, but because so many
other things are built against their interfaces.

~~~
aeorgnoieang
Ultimately, what else is 'good' other than being the foundation of further
far-flung flourishing?

------
adam1210
I have a small (2k+ stars) niche game-related project. The hardest part for me
is saying "no". If someone proposes a change that I think is out of scope, or
is not something I want to maintain (maybe the introduced complexity is
greater than the benefit of the feature) I find it difficult to explain that
in a way people understand. Often times people get offended by it and then
become angry at me, and over time it becomes very draining.

------
dullgiulio
Salvatore's feeling that he should be thinking about big ideas makes me think
of Fabrice Bellard. He drops amazing things, let's the community manage them
and concentrates on starting the next amazing thing. Maybe that's something
good for Salvatore too.

------
stupidcar
It's ironic that Git was intentionally designed to decentralise the process of
software development, so that there was no single "blessed" repository, but
instead of a network of peers, each of which could evolve at a different rate
and in a different way, with the community deciding which would "win" in terms
of popularity.

And yet, via Github, the community has reinvented the centralised model of
software development. For any project, there is a single instance that is the
"blessed" version, by virtue of having the most stars or collaborators, or
owning the associated package name. 99% of forks are nothing more than a place
where you create a feature branch that you intend to PR to the blessed
project.

I hope that, one day, somebody invents a git-based project ecosystem that
solves the problem of decentralised project management. I don't know exactly
what this would look like, but I think it would need to embed the idea of
community and contributor consensus and democracy at a fundamental level,
separating the concept of the project and project ownership from any
individual fork.

~~~
dooglius
>Git was intentionally designed to decentralise the process of software
development, so that there was no single "blessed" repository

I don't think this is true. It was developed by Torvalds to maintain the Linux
kernel, which has always had a "blessed" repository at kernel.org.

~~~
cyphar
Yes and no. The main idea of a dvcs is that you could send patches and pull
requests to other people's forks. So in principle there is technically no
blessed repository, but that doesn't mean there isn't a blessed repository
from a social perspective.

(Also, there is more than one "blessed" Linux repo that a lot of people use.
There's linux-rt, linux-stable, etc.)

------
nerdbaggy
I don’t know why so many open source users feel so entitled when they have
done nothing for the project. I believe that anybody can help a project from
code, documentation, financial, graphic design, etc.

~~~
MakeUsersWant
Most projects don't actually want help. Go and try it: report a few bugs or
point out usabilty issues. See what happens.

~~~
thethirdone
Most of my bug reports have been very well accepted. The worst response I can
remember is just not responding for like 3 months.

And on the other side as a maintainer, any bug report that demonstrates a
clear issue (crash, hang, etc) with a reproducible setup is appreciated.

What can be really frustrating are bug reports that aren't bugs and a better
understanding of the software would allow them to solve the problem. For
example, there was one issue on Slic3r that was asking for a PDF output of
config files. There is really no reason to do that.

------
Bucephalus355
IRS could help out Open Source projects and make it way easier for them to
apply for grant money. But they make it very tough to get 5013c status.

I’m for quite strict tax enforcement but that should be changed.

Also of course private companies need to start stepping up and providing the
often only small sums of money needed to fix these projects via bug bounties
and fees to the maintainers.

------
nicpottier
> Sometimes I believe that software, while great, will never be huge like
> writing a book that will survive for centuries. Note because it is not as
> great per-se, but because as a side effect it is also useful… and will be
> replaced when something more useful is around.

I once saw a sig somewhere that was something along the lines of the author's
goal being of writing some piece of software that would outlive them. That
seemed like a neat, but incredibly ambitious goal, very very few pieces of
software will meet it.

That said, Redis is probably one of them. It isn't too hard to imagine that
there will be Redis instances running somewhere in 40 years, and though I wish
antirez a long life, I think it is likely there will still be Redis instances
chugging along after he passes.

So be proud antirez! You've most certainly made a dent in the universe.

~~~
redisman
Data migration is difficult. I'm sure there are a lot of _very_ old databases
still chugging along in some dusty office corner because no one wants to touch
them since they've worked adequately for the last 30 years.

------
jancsika
This is a vicious cycle of a mentoring problem.

If the maintainer never learned and practiced "role shifting" as a part of the
developer process, they are going to have a bad time if the project gains any
traction whatsoever.

Worse, there's no easy way for a mentor to swoop in and teach them basic role
shifting tactics. Because such an attempt would likely be interpreted as just
a user giving yet another uninformed opinion. Edit: _And_ such a maintainer is
unlikely to be able to delegate to newcomers since mentoring isn't part of
their skillset. (Thus the vicious cycle.)

------
narnianal
The best thing creators should do in my eyes, and I always do it myself, is
trying to make yourself jobless. Solve that problem, find people who are good
at maintaining stuff, move on to the next problem. You don't need to sit there
looking through bugs 12 hours a day. In fact there are people who love this
continuous struggle more than you, and who therefore also have developed
skills at handling these situations without having sleepless nights.

Find these people once your project reaches a stable point from a creative
POV. Then help these people get started, not the users. Then you will see that
you need to do less and less. And when you are at about 30% load start using
your time to find the next problem that you can solve.

No reason to be ashamed of either. There are loads of people who really love
this continous lifestyle and there are few people who actually love finding a
new solution to a problem that nobody can solve. Everybody will be more happy
in the end, even the users.

PS: You can also see it in a different way. There's not just jenkins and
github and AWS to setup as a system to get your project running. People are
also part of the system. People who move the issues along these pipelines.
There is no system if people aren't part of it. And there are not just devs
and users, there are also maintainers, communicators etc.

------
jondubois
I've been maintaining my OSS project for almost 6 years. It's well used in the
industry but nowhere near as popular as Redis. But I can relate to pretty much
everything in the article even the thinking approach. It makes me think that
it takes a certain personality to be an OSS developer.

------
sdegutis
> Moreover I’m sure I’m doing less than I could because of that, but this is
> how things work.

It doesn't have to be. What if all the people who "pay" for Redis, their money
want into a collection bucket, and nobody got the money until they earned it.
Then you work on your own schedule and "earn" that money at a fixed dollar
rate per hour, and claim the money at the end. Other trusted contributors can
join this effort and claim the money after working the hours. This way, hours
are up to the contributors, and money is more like the "pledge" in Kickstarter
for example, or a check that's not yet cashed.

------
ilaksh
I guess I will be the one to complain about something that makes me look bad.
Since no one else complains about this, it makes me think I might be the only
one. However I doubt that.

The problem I have had with my open source projects so far is that most of
them seem to not be very popular and they receive very little if any feedback
at all.

It's gotten to the point where I feel like popularity and merit are not even
directly related. It seems like maybe part of it is tied to some kind of
social networking popularity contest. Certainly I have to think that way
otherwise I would never try to contribute anything again.

------
dbnotabb
We're working to address some of the issues raised in this piece, by creating
a new way of working on Open Source.

Companies post their issues on our platform and contributors are incentivised
by getting to know a company, a monetary reward and the potential of raising
their profile with the company to get hired.

We're looking for feedback so if anyone has any thoughts - [https://works-
hub.com/issues](https://works-hub.com/issues)

~~~
Crinus
Others have tried what you seem to be trying and didn't work, how are you
going to convince people who decide to use tech because it is free, to pay for
it and pay for more than insultingly low scraps? And once someone does accept
and the work is done, what happens if they are not the main developer of the
software that was worked on and the developers decide they do not want to
accept the work? Where does that leave your customers who most likely
(especially if their initial major motivation was free stuff) wont want to pay
someone fix/update the patches every time a new version is released nor be
willing to have their own fork?

I might be missing something of course since your site doesn't work. Every
time i tried to click on a link nothing happened. Firefox's dev console had
this warning:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
remote resource at [https://api.segment.io/v1/p](https://api.segment.io/v1/p).

Looks like your tracking is broken.

BTW, i'm kinda curious, how come you have "25,000+ software engineers on
WorksHub" but only 8 issues, all of them from your own company?

------
bluehatbrit
For those struggling to access the site:
[https://archive.fo/10IpE](https://archive.fo/10IpE)

------
mamcx
I don't remember if I get the idea elsewhere or what, but:

"Worse than a failed project/business, is a successfully one"

I part of "small scale" projects and one thing that some fear, very much, if
that the project GET traction. This have killed some business before.

------
bmh
It seems like there's an opportunity for a tool to help solve this (ie
something other than GitHub issues).

~~~
aeorgnoieang
I'm sure different tools could help somewhat but ultimately anything replacing
GitHub issues would still involve some kind of social, i.e. communication,
structure and that's just a hard thing to build and maintain.

------
2easy
Really great article _bows down_

------
austincheney
I encountered most of the issues described so I set out to solve this problem.
I did the horrible bad thing: I rewrote my projects from scratch. It took me
about a year, pretty much all of 2018. I could afford to do this because I was
separated from both work and family by military education and a military
deployment immediately following.

Now I have software that is stupid fast to extend and maintain. My software
now executes faster than comparable applications coming out of Facebook with
more options and at a very tiny size after accounting for dependcies. Now I
finally have time to watch all the shows I have missed and play games since my
software has fewer defects compared to similar applications and is faster to
patch.

I did get tired of the asshole factor though and even deleted my Reddit
account as a result. Now it’s harder to promote my software online but
deleting my reddit account again opened up more personal time.

------
burtonator
I'm threading the needle in a project I've been working on which is both Open
Source and has premium features around cloud sync:

[https://getpolarized.io/](https://getpolarized.io/)

... it's been interesting. I'm trying to give everyone the best of both worlds
but since I'm catering to a large user base I have to make sure to keep
everyone happy.

Some people DO NOT want to do anything cloud. Some want their own cloud.
Others want cloud and they want it easy.

I think part of what I'm learning is that in order to get the trust from users
I'm going to either have to be around for a long time or get the thumbs up
from other organizations that can vouch for my positive intentions.

For example, I want to write up a document about our commitment to Open Source
but of course that takes work and I don't have a ton of time.

~~~
analognoise
There was a pop-up that asked for money. The language of the bar at the top
gives the impression the program will go away soon unless money comes in, plus
the fact that someone was willing to inject pop-ups made it very difficult to
trust - what if it goes commercial and someone is willing to inject ads or
malware?

