A while back there was an article about how Pulseaudio had one unpaid maintainer, which was crazy for such a core Linux component. Having spent a lot of time adjacent to the anime/manga translation community, I wonder if a little advertising might help - even a simple “we need maintainers!” in the README or –help of a project.
Sure it would be a little annoying, but it reminds people that a lot of these core projects need more eyes.
This article focuses on one interpretation of the question, where a person would like to contribute and knows what to do.
There is another one, where I found myself way to many times — I know what is the itch I want to scratch, and I would like to fix it. however, it is not easy to start, as the documentation is scarce, outdated, and it does make it easy for me to find the place In the repo where I would like to add/change the code. Even worse, building and running a test instance is sometimes just impossible.
And unfortunately, it can be a vicious cycle: a project isn’t easy to work with will not attract many contributors, and a project which has few or no contributors is less likely to make changes to make life easier for them (and may not actually know what the obstacles to contribution are if every potential contributor just gives up)
For real, we don’t hear “thanks” very often and expressions of gratitude are often our only reward for our work. We do appreciate it :)
I thank maintainers for maintaining the project in almost all bug reports or feature requests I file, and if I use and appreciate their project I specifically mention that. I also thank maintainers for reviewing my PRs: I’ve been on the other side of that, and I’m sometimes awful at reviewing PRs to projects I supposedly “maintain”.
I vaguely recall some advice for newbies somewhere to not thank anyone anywhere in issues and patch discussions and such - the rationale being that if you set the standard that you’re going to thank people, well now it’s rude if you didn’t thank them whereas before it was fine that you didn’t because it’s a highly technical context and it’s expected that you’re not going to waste words on non-technical aspects. I thought it was ESR but maybe not; certainly I just searched (albeit only for ~2 minutes) and couldn’t find the source.
In any case, to this day I still think about this while saying thanks and have to consciously ignore it. I really dislike this advice.
I thank maintainers for maintaining the project in almost all bug reports or feature requests I file
This can read as “thanks, and I want something from you”, which does feel a bit hollow at times. The best gratitude is delivered unconditionally, and these rare emails and comments always make my day.
I also thank maintainers for reviewing my PRs: I’ve been on the other side of that, and I’m sometimes awful at reviewing PRs to projects I supposedly “maintain”.
This is a lot better, I always thank contributors for their patch and I thank maintainers for their review - it’s more personal, they’ve done work for my sake and I’m thankful for their time.
The idea of not expressing thanks as a rule is a pretty bad idea, though.
This can read as “thanks, and I want something from you”, which does feel a bit hollow at times.
Hm, yeah, I’ve wondered a few times if this is how it was coming off. That’s not how I mean it though, it’s just that by filing the bug I’m already getting in touch with the project so it’s a good time to say it.
Is there a better way to do this so it doesn’t seem conditional or trite?
On the other hand, a lot of projects do not offer a HACKING file that contains a high level overview of the codebase and a brief tutorial (reference) on how to setup a development environment and how to start a development version (this is particularly true of a stable version is already installed on your machine).
For an example of this thing done correctly look at ansible: they have some fairly good guide on how to start hacking once you have cloned their source code repository.
One issue is with unfinished projects with no releases.
It is not possible to have a favourite bug or feature you want to deal with. I guess the point still stands though, you might just have to wait until the project progresses to a point where there is a beta release before you can really contribute.
It might be worth considering whether projects should have something like a ‘community maintainer’ whose job it is to onboard and guide everyone who offers to help. Sure you would waste a lot of time on people who end up contributing little or nothing, but if you got 2 regular contributors out of it, that should make it worthwhile. Not to mention teaching someone the basics of free software contribution is a worthy task even if they only end up contributing to other projects in the ecosystem.
With new and unfinished projects - generally, if the project’s stated goals align with something you want, and there’s enough code to see the shape of the solution, you should be able to help implement features and even core functionality. It’s a somewhat different task than contributing to established projects, but can be accomplished nonetheless.
I’ve heard several people say that they won’t start a business if the idea is taken. But if one person earns money with a hotdog stand, it does not make it a bad idea to start another?
Similarly, there is ample room for multiple open source projects. Having several types of one application can be a strength, since over time, one of them may become the most useful or popular one.
I believe there is always room for not only innovation, but also twists on existing ideas.
If there ever is to be a better wheel, people should allow themselves to experiment with wheel reinventions.
There’s no way competition isn’t accepted. Even gmail has competition. As long as you can take a slice of the market that is enough for you, you’re good to go.
There’s actually very little chance your value proposition is 100% the same as your said competition. You might be offering a very similar service, but not targeting the same population, or having a slightly different set of features, or even different Terms and Conditions.
This, as you point out, applied to open source is actually even better, because most people aren’t reaching for a market, they do what they thinks is best and the barrier of entry is very low.
In open source, I like to believe it’s no competition, it’s challenging peer projects :)
When reinventing the wheel is too difficult and would take ages.
I was excited to reinvent my own Wayland compositor, spent some time writing Rust bindings to libweston, got a little demo working, realized that I would probably never get to something full-featured with all the bells and whistles, and went on to discover Wayfire and join its development :)
A while back there was an article about how Pulseaudio had one unpaid maintainer, which was crazy for such a core Linux component. Having spent a lot of time adjacent to the anime/manga translation community, I wonder if a little advertising might help - even a simple “we need maintainers!” in the README or –help of a project. Sure it would be a little annoying, but it reminds people that a lot of these core projects need more eyes.
Perhaps they can make Pulseaudio play a “we need maintainers” .wav file every once in a while.
I somehow feel like that would not be super popular…
Yeah, that’s definitely noticeable.. my merge request didn’t get any response in months.
With the development of PipeWire, it doesn’t seem like anyone wants to maintain Pulse anymore..
This article focuses on one interpretation of the question, where a person would like to contribute and knows what to do.
There is another one, where I found myself way to many times — I know what is the itch I want to scratch, and I would like to fix it. however, it is not easy to start, as the documentation is scarce, outdated, and it does make it easy for me to find the place In the repo where I would like to add/change the code. Even worse, building and running a test instance is sometimes just impossible.
And unfortunately, it can be a vicious cycle: a project isn’t easy to work with will not attract many contributors, and a project which has few or no contributors is less likely to make changes to make life easier for them (and may not actually know what the obstacles to contribution are if every potential contributor just gives up)
I thank maintainers for maintaining the project in almost all bug reports or feature requests I file, and if I use and appreciate their project I specifically mention that. I also thank maintainers for reviewing my PRs: I’ve been on the other side of that, and I’m sometimes awful at reviewing PRs to projects I supposedly “maintain”.
I vaguely recall some advice for newbies somewhere to not thank anyone anywhere in issues and patch discussions and such - the rationale being that if you set the standard that you’re going to thank people, well now it’s rude if you didn’t thank them whereas before it was fine that you didn’t because it’s a highly technical context and it’s expected that you’re not going to waste words on non-technical aspects. I thought it was ESR but maybe not; certainly I just searched (albeit only for ~2 minutes) and couldn’t find the source.
In any case, to this day I still think about this while saying thanks and have to consciously ignore it. I really dislike this advice.
This can read as “thanks, and I want something from you”, which does feel a bit hollow at times. The best gratitude is delivered unconditionally, and these rare emails and comments always make my day.
This is a lot better, I always thank contributors for their patch and I thank maintainers for their review - it’s more personal, they’ve done work for my sake and I’m thankful for their time.
The idea of not expressing thanks as a rule is a pretty bad idea, though.
Hm, yeah, I’ve wondered a few times if this is how it was coming off. That’s not how I mean it though, it’s just that by filing the bug I’m already getting in touch with the project so it’s a good time to say it.
Is there a better way to do this so it doesn’t seem conditional or trite?
I thought I’d seen him say something to that effect too, but it looks like we were mistaken.
On the other hand, a lot of projects do not offer a HACKING file that contains a high level overview of the codebase and a brief tutorial (reference) on how to setup a development environment and how to start a development version (this is particularly true of a stable version is already installed on your machine).
For an example of this thing done correctly look at ansible: they have some fairly good guide on how to start hacking once you have cloned their source code repository.
One issue is with unfinished projects with no releases. It is not possible to have a favourite bug or feature you want to deal with. I guess the point still stands though, you might just have to wait until the project progresses to a point where there is a beta release before you can really contribute.
It might be worth considering whether projects should have something like a ‘community maintainer’ whose job it is to onboard and guide everyone who offers to help. Sure you would waste a lot of time on people who end up contributing little or nothing, but if you got 2 regular contributors out of it, that should make it worthwhile. Not to mention teaching someone the basics of free software contribution is a worthy task even if they only end up contributing to other projects in the ecosystem.
With new and unfinished projects - generally, if the project’s stated goals align with something you want, and there’s enough code to see the shape of the solution, you should be able to help implement features and even core functionality. It’s a somewhat different task than contributing to established projects, but can be accomplished nonetheless.
You might be tempted to reinvent the wheel rather than contributing to an existing project. When does it become interesting to contribute?
I’ve heard several people say that they won’t start a business if the idea is taken. But if one person earns money with a hotdog stand, it does not make it a bad idea to start another?
Similarly, there is ample room for multiple open source projects. Having several types of one application can be a strength, since over time, one of them may become the most useful or popular one.
I believe there is always room for not only innovation, but also twists on existing ideas.
If there ever is to be a better wheel, people should allow themselves to experiment with wheel reinventions.
I think it boils down to 2 things:
There’s no way competition isn’t accepted. Even gmail has competition. As long as you can take a slice of the market that is enough for you, you’re good to go.
There’s actually very little chance your value proposition is 100% the same as your said competition. You might be offering a very similar service, but not targeting the same population, or having a slightly different set of features, or even different Terms and Conditions.
This, as you point out, applied to open source is actually even better, because most people aren’t reaching for a market, they do what they thinks is best and the barrier of entry is very low.
In open source, I like to believe it’s no competition, it’s challenging peer projects :)
When reinventing the wheel is too difficult and would take ages.
I was excited to reinvent my own Wayland compositor, spent some time writing Rust bindings to libweston, got a little demo working, realized that I would probably never get to something full-featured with all the bells and whistles, and went on to discover Wayfire and join its development :)