10

When I work on new libraries and tools I potentially would like them to get contributors and activity. However, I'm not sure what I could to in order to encourage more participation.

As a project owner, how can I make my open source project more accessible to new participants?

|improve this question

closed as too broad by Gilles 'SO- stop being evil', curiousdannii, HDE 226868, kdopen, Mnementh Jun 24 '15 at 0:28

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    When you want contributors are you looking for others to use yours to branch off and make new things or are you looking for collaborators that will work with you to develop and/or improve your idea? – Raystafarian Jun 23 '15 at 18:09
7

I can think of a few points

  • Documentation is key - Not just usage documentation, but also development documentation! How do I build your project? How do I run tests? How do the internal APIs work? Github has the wiki feature for that, although you can just create a directory with a bunch of .md files.
  • Make your directory structure predictable - Look at how other successful projects did it. Make it clear what's the source code, what are the tests, where is the entry point, etc.
  • Making an attractive website helps - With GitHub, just create a branch called gh-pages and your project's website is instantly live.
  • Make it clear how contributions are expected to arrive - Don't be afraid to ask for things before accepting a PR. If you have tests, require a successful build. If you have a coding style, ask contributors to adhere to it (some languages offer style enforcement for that). Also, make it clear that not just PRs are considered contributions, opening issues, asking (and answering) questions, writing documentations, are all equally helpful.
  • Be active - You got an issue? Respond to it! Someone asked a question? Answer! The better you respond, the better people will feel about participating.
  • Make it fun, be helpful, not annoying - Things that may seem obvious to you, as the core developer, will not be obvious to newcomers. Encourage people to contribute when they find bugs, support them on the way, make the journey fun for them.
  • Remain professional - No bad humor, no racist jokes, no annoying comments. Please.

As it turns out, many people will be willing to put the time and submit a pull request when guided and assisted properly. It makes them feel good, as well as making valuable contributions to your project.

|improve this answer
  • To your point about having a predictable directory structure, I would also add "use descriptive file names." Say I want to fix a bug loading an image file – if there's a file called ImageFile.cpp, that's the first place I'd look. – Maxpm Oct 26 '17 at 19:56
5

Well this is my personal opinion. I think there is no really perfect way for this.

I'm participating in many open source projects, often on GitHub and sometimes on "private" hosted repositories. Due to this participation, I have some things I've always check before participating.

  • Are there clean Coding Guidelines?
  • Is there a team structure behind the project? Can I see those team structure? It's very important for me, as if there is some serious issue or a bug which tends to be exploitable, I need someone who could be consulted and someone who feels responsible for it. If the project is unstructured, it may fail in a short time. If I have this feeling, I won't waste my precious time for this project.
  • Is there a good documentation of all the things which already exist? Most developer tend to leave the documentation out until a certain state is achieved. If I would like to join in the first days, this may stop me. As I don't want to spend hours or days reading through one or two classes to find their reason for being. This is just awful. If you document it right from the start, it will help you to get (fast) new participants.
  • And my last reason, and maybe the most important. Can I commit on my own in branches or forks? Or do I have to put a diff to an issue tracker. This isn't the hardest thing. But a diff in an issue tracker tends to lie around for days or maybe months. After some months the patch may be obsolete and needs to be refactored at all. This means, my work was just for the garbage can. If I could push it to an fork or a seperate branch and generate a pull-request, it will be collected and may be merged faster. No one loves to waste his work. :-)

Hopefully this will help you.

|improve this answer
  • 1
    How are any of those "personal opinion"? All of them sound like they objectively help with the issue. – Benjamin Gruenbaum Jun 23 '15 at 18:11
  • Thanks. Well I marked them as personal opinion, as all of them are things which make me believe in an project. :-) – Ionic Jun 23 '15 at 18:18
4

Where are some points you can do:

Create a website

This is a no-brainer: a website can inform about your project and can be the gathering point. You haven't host a website yourself, if you have the information in the web on some point (for instance on the main site for your project on a project hosting site like github), then it works too.

Have a public readable version control

This way it is easy to access your source code and therefore makes it easier for others to join.

Have a clear policy on submits

This makes it easy for possible contributors to understand what to do to participate. This could include stuff on how the code has to be formatted, which quality you expects and many other things.

Create good documentation

As you look for contributors, this primarily means developer-doc. That includes source-code-documentation, but also some documentation with entry-points for beginning contributors.

Have automatic build-scripts and automated tests

An automated build-script makes it easier to get from source to a running program. Document which tools (compiler for instance) are expected for the buildscript to work.

Having automated tests makes it easier for potential contributors to check, if they break anything with their changes.

Have a clear goal

Define a goal of your software, so contributors can check if they want to go in the same direction.

Provide communication channels

That not only includes communication channels to you, but to each other in the forming community around your project. So this includes mailinglist, forum, irc-channel, ...

|improve this answer
  • Well, nearly the same as mine. :-D But the website isn't that important for me. I'm working on many libraries which are just relevant for specialists. This means the userbase is very small and a website would just waste time. I tend to read the documentation on github for example and everything is fine for me. :-) – Ionic Jun 23 '15 at 18:04
  • I'm not saying all of this is needed, but it would be helpful in most cases to attract possible contributors. And with github you can create something like an website, it doesn't mean you have to host one yourself. – Mnementh Jun 23 '15 at 18:06
  • This wasn't a critic. I just mentioned my opinion. :-) – Ionic Jun 23 '15 at 18:07
  • 1
    I take it not as personal critic, I explained only that a site on github also counts as website in my books (and edited it into the answer). Your opinion is welcome. – Mnementh Jun 23 '15 at 18:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.