JHipster’s Bounty System and how it saved the project.

The back story.

If you asked Julien Dubois (creator and lead developer of JHipster) about his project a few months back, things weren’t looking great. The project was getting many new users, which was awesome, but as a result there were many unanswered issues and pending pull requests, and that was becoming too big and complex for the JHipster team to manage. Things were getting worse as the project continued to grow, so something needed to be done to get back on track.

Without that system, we would very probably have stalled at some point.

I met with Julien during the Paris Open Source Summit and we had a great chat about his experience.

P: Julien, tell us a bit about JHipster and the community behind it.

J: JHipster is a development platform that generates full-stack applications, based on Spring Boot and a modern front-end (Angular, React, VueJS). The project has many options, from development to production, and as a result we have a very wide range of technology solutions. The community is quite big and diverse: as of today we have about 500 contributors, and 24 of them are part of our “core development team”. Members of the “core team” are elected by peers, and have write access to the project. We have a strong focus on welcoming and helping new contributors, and we have adopted a code of conduct very early.

P: Super curious, how does does this elected by peers system works?

J: We basically copied the way the Apache Foundation works: when someone contributes to the project, at some point, he will either ask to join the team, or get noticed by a team member who will ask him to join. Someone, usually me, will then submit a vote to the “core team” mailing list: the mailing list is publicly readable, but only “core team” members can send messages, so this process is fully transparent and public. People either vote +1 (if they agree) or -1 (if they disagree), and if there is only one -1 vote, then the person won’t be accepted to the team. Now there’s a trick: if a team member votes -1, he/she needs to explain why, and that has never happened yet! So for the moment, even if the process looks a bit strict, everybody has been warmly welcome, and had a unanimous vote for them, which is of course awesome.

P: How’s the current bounty system set up?

https://github.com/jhipster/generator-jhipster/labels/%24100

J: Our bug bounty system works for all projects under the JHipster organization in GitHub. Every month, we first assign a budget, which depends on our current sponsors and finance. Then we select issues based on several criteria: if it’s a critical problem, if it’s a good new feature, if it’s complex… That selection can be done by members of the core team, but at the end only Deepu K Sasidharan (the project co-lead) and myself have the final word: we then tag those issues with a “$100” label.

Then, people can submit pull requests to close tickets with that “$100” label: once that pull request is closed, they can them claim the bounty on Open Collective, and get their money.

It motivates people to work on the parts of the project we want to push forward, and helps critical issues to be solved quicker.

P: Has it been helpful?

J: It has been tremendously helpful! It motivates people to work on the parts of the project we want to push forward, and helps critical issues to be solved quicker. Also, this allows us to give something back in return to the hard work of contributors, and I find this wonderful.

For me, this is the “next level” for the project, in order to continue growing and keeping the level of quality we’ve had from the start. Without that system, we would very probably have stalled at some point.

P: Nice! What issues / features work better for bounties?

J:New features always work better, whether there are bug bounties on them or not. Annoying bugs always attract less people, but then that’s why we put bug bounties on them!

https://www.jhipster.tech/sponsors/

P: You have a path for sponsors to open their own bounties, right?

J: Yes, our gold sponsors have the ability to select bug bounties themselves, so they can have a premium support on what they think is the most important from them. It is very important, when you rely or benefit from an Open Source project, that you give back in terms of sponsorship, but also that you have the ability to have your issues or features handled with a higher priority.

P: Love that. Would you recommend it for other projects? Any particular insights on the maturity of the project or community needed for a program like this to succeed?

J: I would definitely recommend it, but the project needs to be large enough to attract sponsors, and also have a community of at least 20–30 people. So for me this is mostly useful for fairly large Open Source projects, as you need to attract both sponsors and contributors, and those are fairly complex tasks.

P: Makes sense. I was so happy to learn about this. Can’t wait to see how it grows!

🔥Not to be missed: JHipster is doing “bug bounty booster” for the last 10 days of 2018 all bug bounties will be $200, so 2x the normal money!🔥

*Read more about the project: https://www.jhipster.tech/ & follow twitter.com/@java_hipster

*Join their bounty system: https://github.com/jhipster

*Support them financially: https://opencollective.com/generator-jhipster

Thank you Julien and the JHipster community for experimenting with Bounties on Open Collective! ❤ ❤