Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

What is a reasonable minimum for making a FOSS project inviting to contributors?

+5
−0

A lot of people who maintain FOSS projects would like to get more contributions.

What can the maintainer do to ensure that potential contributors are converted into actual contributors?

There are many things you can do to encourage people to contribute to your project, up to and including paying them a full time salary to do so. But nobody would seriously claim that it's reasonable to expect every FOSS maintainer who wants more contributions to offer paid positions. That is why I am asking about a reasonable minimum - things that any maintainer can be reasonably expected to do if they care at all about encouraging people to contribute, and there's no real excuse not to do them.

To encouraged more focused answers, let's assume the project is hosted as a single repository on a code host with a web interface like Gitlab.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.

+6
−0

I don't actually know the answer to this, but I'll post a provisional one while we wait for someone wiser than me to chime in. I think this is a small subset of the real answer.

  1. Don't forget the license. Make sure it's clear that it's FOSS. Code without a license on a public repo is, by default, collectively copyrighted by the authors. It is illegal to use, redistribute or modify it (even for PRs back upstream) without the explicit permission of each author. You have to include a license to make it clear this is not the case.
  2. Lay out the process. Have a clear CONTRIBUTING.md doc. Explain exactly how people should format and submit PRs, what requirements you have (eg. tests pass, formatted with XYZ style), what turnaround they can expect for a response, and how fussy you plan to be before they get accepted. If you'll require any legal stuff like a CLA, say it clearly and link to the form.
  3. Don't be too picky. You're not Sr. Eng. Manager at FANG where people get paid 500k/year to suit your every whim. Try to require only those things which are absolutely necessary. Clean up minor things yourself, like formatting.
  4. Automate requirements. Tests, linters, format checkers... If it's automated, people can get the code up to snuff on their own, without waiting for you to check it manually and respond with feedback. Aim for zero manual review (even though it's probably unattainable) - "if tests pass, I will probably accept your PR" (and write tests accordingly).
  5. Lay out the roadmap. Make sure it's easy for people to see what features are missing, what they would look like if added, which ones you're working on and which ones are deep in the backlog. Github is now adding a lot of project management tools like tickets and project boards - use those. Populate the issue tracker with specific, well-described issues and make sure they are tagged/categorized properly.
  6. Clean out the tumbleweeds. Don't ever go too long without having some kind of action on the project. Update issues, rewrite docs, refactor, something. When someone looks at the project repo, they should be able to quickly and easily locate evidence that you are alive and kicking, and haven't passed away months ago leaving your script to auto-approve dependabot PRs and that's all. Find some excuse to publish something new every few days, to keep the momentum going.
  7. Up-to-date documentation is mandatory. It's okay if you are looking for help writing documentation (you said so in the contributor guidelines, and linked to the specific documentation tickets, right?) but you still need to provide the foundation. At a bare minimum, there should be a readme providing an overview of what the project is for, build/install instructions that work, basic usage examples. Periodically, spin up a VM or similar fresh env, and try going through the readme like a new user would, to catch any steps you forgot or that became obsolete.
  8. Avoid arcane technologies/languages/techniques (or not). Try to make the code look as normal as you can (without unduly compromising the project). Where possible, don't use obscure languages or technologies that few people will know or want to learn. Don't do things in a weird way that nobody else does. Use a standard coding style. The flipside of this is that sometimes, communities around very niche tools can have a lot more enthusiasm for contributing, so keep this in mind.
  9. If you are willing to teach, say so. Novice programmers who are just getting started have a lot of interest in and reasons for becoming FOSS contributors, but they will need to be taught. If you are able to do this, make it clear how they can get started.
  10. Advertise. Post periodic updates about your project on communities where it's appropriate: Reddit, hackernews, lobsters, soylent, hacktoberfest, forums for the language you use, here... Obviously check that it's not against the rules to do so.

As I said, this is at best a guess. I don't actually know why and I'd love to see someone post a more authoritative answer.

Also, the above is a somewhat extreme version, written from the point of view that you really do want to maximize your odds of getting contributions. Certain things (3, 4, 8) can potentially conflict with the integrity of the project. Others (2, 4, 5, 6, 7, 10) are laborious. I'd say that overall, it is reasonable to expect a serious FOSS maintainer to follow all of these, but they might use their judgement to make an occasional exception if there's good reason.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

+3
−0

Matthew's list is pretty good, although I don't think one has to do all the things on it as a "minimum." I offer one minimum and a couple nice-to-haves. Some of these I have learned as a contributor; some as a maintainer.

Must

Don't be a jerk

When people engage with your project, don't be dismissive, haughty, or mean. There is definitely bad behavior you should ignore, and sometimes posts (or people) you need to block, but rudeness is never rewarded.

There are projects I will never contribute to because I saw how someone else was treated by the maintainers.

Good

Have a scope

It is demoralizing for a contributor to make a PR that does a thing, and have it rejected because "our project doesn't do that." Save that person the work, and/or encourage opening issues to discuss it first.

Don't summarily close stale issues[1]

Subscribers to a bug report that is then locked (especially by a "needs bump or else" automation) will lose their investment and any sense of continuity. You can close issues as WONTFIX or DUPLICATE if that's the proper resolution, but otherwise leave them open.

The upvoting is important and should not be fragmented. It is also frustrating to discover years later that someone opened the same issue but without the previous context, and no one who was previously subscribed knew about it.

On the other hand: Hide "me too" comments that lack additional information, and gently suggest upvoting OP instead.

Builds should be easy

This may be implied by the previous answer, but I want it to be explicit: If people can't build your project with little-to-no effort, a large contingent are never going to contribute and won't ever tell you why.

All a contributer should need is to clone, (optionally) install dependencies, and make. Nobody downloads your source code to fuss with architecture differences or toolchain versions. If someone is sufficiently engaged to get past that, or to post an issue about a build error, great! You've found a good one! But if they decide it wasn't worth it, you may never hear from them again.

Maybe

Tag appropriate issues as "good first issue"

I am not certain that this helps, but it's low-effort and probably doesn't hurt.

In my experience, most people who want to contribute want to fix their pain point, not your pain point. However, for those genuine altruists who are just a bit intimidated by your existing codebase, it might be helpful to suggest a good, encapsulated entry-point into making a change to the system.


  1. This either a clarification or a rebuttal to Matthew's #6 "Clean out the tumbleweeds." ↩︎

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »