The Phases of an Open Source Project Maintainer | Hacker News Reader

The Phases of an Open Source Project Maintainer

nibblestew.blogspot.com

92 pointspabs346 comments

Phase six-a: The open-source license disillusionee

Your project didn’t just scratch your own itch, but also that of a powerful large commercial entity. It copied your permissively licensed mouse trap into its moneymaking SAAS machine. You start questioning yourself using such words as fairness and attribution. You are annoyed that you’re unable to find that 2019 talk by a german Elastic guy on HN about the commercial realities of open source software.

Where are the stages for:

Realization that no one else will be contributing

Realization that programmers capable of really contributing probably think "filing a bug" was "contributing" and will bug you about timelines

Realization that people in paid jobs are pressuring you for bug fixes and feature timelines

Realization that being asked for free support from perfectly nice people has a mental cost, either in not providing it, or in providing it

Realization that open source zealots will judge you, and companies will avoid you, if you choose any other license, but at the same time, none of the problems above have solutions...

Feeling that your work provides charity to for-profit enterprises

Ennui/Abandonment: A strange game. The only winning move is not to play.

nit: "filing a bug" is definitely contributing. A well written bug report is worth its weight in gold and can get you started with the test case to write for the fix. alternatively, a one liner pull request that you have no idea what it's "fixing" is useless garbage.

edit: I amended above slightly to more accurately describe the ennui.

I must admit I found the complaints about the license on my own project, which boiled down to you didn't make it freely available so we could steal it and use it for our own much better funded project without any cost, darkly amusing.

The contradiction at the heart of open source is that people like to be used.

Be used? You mean be useful?

There's some wordplay in the comment.

The contradiction is that of course a dev doesn't want to be used (meaning: taken advantage of); yet, a dev wants their projects to be used - the dev wants to have "users".

This.

I've open-sourced a couple of tools throughout the years and all it's done is prove to me that I don't have the emotional energy to deal with it.

I still get emails that somehow both call me a piece of s&#t but still asking me to add features to a piece of software that's been irrelevant for 7+ years...

I found the same thing when I would play music publicly - I love music, I hate the audience. Writing a piece of software for other devs/SWEs to consume is often hell - we are a demanding, incredibly opinionated, pissy bunch of folks. (I say that last bit 110% self-aware that historically I'm part of the problem.)

An alternative path:

Realization that while the project is very popular, it no longer interests you

Realization that due to your technical decisions, others can't simply fork and maintain it

Realization that indulging enthusiastic amateurs costs you 10x the time than simply implementing the feature yourself

Realization that thousands of users are suffering because your project is still by far the best choice even as it rots

Realization that no matter how well you document the tool, users will still ignore it and feel entitled to your direct support

Man, even making something popular sucks.

> indulging enthusiastic amateurs costs you 10x the time than ...

That means accepting contributions? Code reviewing, giving feedback, showing how to rewrite the PR in better ways?

Wow, a lot of that is unnervingly familiar. I haven't quite experienced the last two yet, but I can see them happening.

I am starting to gestate a line of thought that is pondering what people think open source is for?

E.g. from the article:

> Once the first version exists and is found usable, the next step is to make it production ready.

Why? Why does open source ever have to get to this stage at all? What are people's expectations? Is there a - potentially unconscious - expectation that all open source projects need to end up at the scale of linux or kubernetes or firefox or whatever?

Why can't open source just be some twiddly little bit of fun that captures your imagination for a week or two, ends up on github and is then abandoned?

Don't be so hard on yourselves. Create things for the joy of it.

Even when open-sourcing code for dull work problems, there are other things to offer besides a "production quality" library. Well-organized data files in a simple format could help people. I've snatched CSVs and JSON files from plenty of GitHub repos, even if I never use the repo's primary language. Saves me days of effort.

Part of what's been happening is that your open-source project is now part of your resume. If your name is on it, prospective employers are going to see it. If they see it and decide that there isn't sufficient error handling and too many edge cases are missed, they are going to hold that against you.

It's a nutty situation we've gotten ourselves into.

Super vulnerable moment... My open source pet project is an audio plugin that I developed to use in my own music projects. For whatever reason, it has become popular among a certain niche of musicians, and now I get reports of a rare bug that blasts their headphones with a high decibel noise. It's super unnerving that it threatens to damage people's ears and equipment, and I still don't know enough about why it is happening in order to fix it, because I mostly just wrapped an existing library that I wanted to use.

What about adding a warning message in the repo about that and asking for help with fixing it, and messaging the author of the wrapped lib and see if s/he has any ideas

Maintaining an OS project definitely gives you a crash course in (and boosted respect for) non-engineering roles at tech companies.

However, I'd say if you're maintaining something and don't enjoy one or more of these hats then keep in mind that totally dominating a problem space doesn't need to be the end goal. There is such a thing as a lifestyle OS project and you can still make a success out of it, gain a loyal (perhaps modest) community, and enjoy taking it slow.

This is exactly how it's going so far for my project Dotter https://github.com/SuperCuber/dotter. As you can tell, I'm currently in the marketing stage :P

Have a look at https://github.com/twpayne/chezmoi too.

I have! At some point I will outline the differences between them in an FAQ

The most starred project I have has 45 stars[0] and my second-highest starred project has 17 stars[1].

Thankfully, maintaining them and using them has been great, user interactions have been super friendly and very pleasant.

So, despite me wanting to be popular, it is perhaps a good thing none of my projects made it big and that I can still consider myself at around stage #1

[0]: https://github.com/ldd/gatsby-source-github-api

[1]: https://github.com/ldd/vscode-jq

This resonates with me. Although a relatively small and unknown project, I’m in phase-9 for asdf version manager.

The maintainers take good care of the project and I admire the energy and consistency that maintainers like Trevor Brown have.

I try really hard to contribute sometimes by responding to issues and closing them. But that is all the energy I can spare for the project.

At this point I would rather focus on anything that pays money than work on something purely for the sake of open source.

What I wish I knew 12yrs ago:

* Money is not a bad thing to take/have. * Irrespective of whether projects are opensource or paid, they need to be sustainable.

Being active in a project is also quite useful when looking for salaried work.

If be surprised if any worth while prospective employer did not look favourably upon it. It's often the most visible past software work you have.

I’m at Stage 9, on one of my projects. Chances are good, that it will do well for many years.

Most of the rest, I’m at Stage 4, with ambivalence towards moving past that.

A couple of projects didn’t make it past Stage 2.

I keep a lot of irons in the fire.

I'm in phase 6 – Come help https://github.com/chriswalz/bit :)

I'm at Phase 3 through 5 right now with my raw photo processing software Filmulator (https://filmulator.org).

Luckily for me, I kept scope small and the project is 8 years old, so I was able to manage documentation as well as UI polish, while keeping bugs to a minimum. These days I'm still adding features and improving the onboarding experience.

Now to get people using it…

Very true! And I would argue that, at least as per the first stage, it also applies to solo founders of startups (non open source projects)

In the same way I didn't understand why people feel the need to have lots of "side projects" in this profession, I really don't understand why people feel the need for their software projects to "infinitely grow". This is not capitalism. Even the word "maintainer" seems to put you into this mindset. Software does have a point where it can be considered finished. At some point the best course of action might very well be to just frigging stop.

I actually value software that is mostly static.

Then again this website is extremely biased towards people who develop network services, which for some reason tends to require constant maintenance.

Most of my 'side projects' are at home and not public. If you were to see my github page it is empty. I personally find with most of my 'side projects' are one off and sometimes I might pluck out a function or two out of something else but that is it. They are like you said mostly static and never really revisited.

I wonder if a 'rules of the road' sort of document in repos would help? A sort of 'here is what you can expect from the maintainer of this repo'. I think some people end up taking on too much and then you find out some key bit of infrastructure is done by 1 guy in his spare time, and managing their own job. Then others come along and expect you to fix it for them when you pretty much have abandoned the project. For example many of my projects would be in a 'AS-IS' category, if I made them public. I am not going to really revisit a project from 6 years ago that did something specific I needed. Not even if you show up with a nice pull request unless I am feeling particularly charitable that day.

So why do you feel the need to document the _obvious_ fact that this a project you did in your spare time and therefore no one should expect _you_ to fix whatever issue they're having ? (irregardless of whether you are currently working on it or not)

I also have a number of opensource projects published. Some of them get picked up by the popular distros, and I know (most of them) are in the same situation so I may be inclined to help them out. However, I have to ponder what goes in the minds of the people who bombard me with "Please add support for my odd usecase no one other than me could possibly want" emails.

PS If someone sents you a patch to a 6 year abandoned project which you don't even care any longer, just apply it without even trying to check if it builds. Most likely it does.

It is 'obvious' but for some people it does not seem to be? Not that it would help. It would mean they read the docs/code. Usually that is 99% of what they need to do. Some people are 'help vampires' and know they need something but want you to kind of do it for them. I do not even think they mean to do it. I think it is just text and this form of communication creates this weird air of authority that is not really there.

For my personal case my private repos are mine and have no license/rules of the road because they are private.

Software doesn't rot.

The world rots, and software must be maintained to match it, to keep working.

That couldn't be further from the truth.

It is my common in my area (engineering/industrial) to see software that is 30-40 years old where the only maintenance required is to keep up with the ever-changing operating systems (i.e. it is software who changes more than the rest of "the world").

Because at some point DOS ain't going to run on Windows 11 anymore.

That's what I meant i.e. your software doesn't rot, other software rots (i.e. the rest of the world).

My wording didn't express what I meant.

If you like programming and think your job is boring then what are you going to do? Do another boring thing as your hobby?

Love this. There are key parallels as a junior engineer climbing the software management ladder.

In particular Phase Eight, making the flip from engineer/senior-engineer to manager causes friction when the new manager can't let go of the code.

That's me... I can't let go of the code =\ Worst still - I'm not even that good at coding.

Can anyone think of some OSS Emeriti?

I think Guido van Rossum is a prominent example, but I can't think of anyone else right now.

He is emeritus in remission though, recently hired at Microsoft:-)

Well he retired from his Benevolent Dictator for Life role at his little OSS project. I don't think the article meant you're never allowed to touch a keyboard again.

RMS

He's in exile

Does Knuth count?

What phase is benevolent dictator for life (BDFL)?

1-8. The definition of phase 9 is that you stepped away from the BDFL role.

How about ‘the angry burnout’?

Reply on news.ycombinator.com