Here’s a welcome message – RabbitMQ is back at VMware! We are very excited to be back and a strategic part of open source at VMware. We are both VMware employees and the maintainers of the RabbitMQ open source project. We wear two hats, and we work to make sure that the broader community (outside of VMware) finds RabbitMQ to be a welcome place to contribute. So, we make efforts to be communicative, responsive and provide smart tooling for all contributors by default.
RabbitMQ is an open source message broker that enables applications (or services within a distributed application) to communicate asynchronously and securely. RabbitMQ has evolved over its history and today enables a great number of modern application architectures. For an excellent summary and timeline of RabbitMQ’s birth and early history as a message broker, I recommend the first chapter of RabbitMQ in Action. And for a detailed dive into a variety of current popular use cases, I recommend RabbitMQ in Depth. The home of the project is here and the code repository is here. The current version of RabbitMQ is 3.8.
I’d like to highlight some aspects of RabbitMQ that make it a special open source project in terms of community participation. For instance, top of the list is the involvement we get from code contributors from all over the community. A quick peek at the OpenHub page for RabbitMQ shows that over the last 12 months 29 different community members contributed to RabbitMQ, putting the project in the top two percent of all open source projects tracked by OpenHub data in terms of size of active contributing community.
[source: OpenHub – linked image]
How did we get here? I asked the RabbitMQ team for their opinion on why RabbitMQ attracts and retains outside contributors. The top three distinguishing characteristics are:
- Maintain open and healthy communication channels
- Be responsive to potential contributors
- Provide a straightforward contribution process
Healthy Communication Channels
The RabbitMQ team at VMware invests in community access by providing multiple communication channels for users and potential contributors, no matter their preferred programming language. The public mailing list (now 7,000 members strong) forms the primary discussion forum for RabbitMQ. The RabbitMQ public Slack channel, Stack Overflow discussion forum and Twitter (@RabbitMQ) are all great places to interact with users and contributors. Many contributions start as discussions on the public mailing list and through encouragement evolve into pull requests – and often the actual change is contributed by someone other than the original poster that started the discussion.
One example of a process change made to foster contribution took place recently within our GitHub repository. We created a new “discussions” area where we can incubate those pull requests and issues that need additional work. Rather than simply closing and rejecting, we move a given proposal from the “issues” section into the “discussion” section. Once there, the idea can be further discussed and refined into a clear actionable proposal.
The main component that drives our efforts as project maintainers around facilitating communication is a commitment to actively listen to our community—with a clear messaging system and messaging protocols in place—and encourage contributions. The user community is full of potential contributors who may be close to offering a contribution to code or documentation. When your project team invests time and effort towards building respectful communication channels for discussion of proposals, it pays off by building confidence in potential contributors and encourages them that their proposals are worthy of review and potential acceptance.
Responsiveness
We work to respond promptly to any incoming message and all potential contributions, ensuring the contributor understands why or why not a given suggestion is currently viable. Whether an idea is accepted or rejected, it’s important to respond with a quick and clear message as to why a decision was made. A quick rejection with clear reasoning allows a contributor to move on and keeps the door open to potentially reconnect in the future. Forcing someone to wait without a response to their message or contribution is a sure fire way to sour them on becoming a contributor in the future.
Consistently being responsive to contributors over time builds a positive reputation for your project as a place where contributors are respected and attracts more significant contributions. Here are two recent contributions from the community that have significant positive impact on RabbitMQ – in this instance, the RabbitMQ DotNet client.
Contributor one: GitHub user Stefán Jökull Sigurðarson (@stebet)
https://github.com/rabbitmq/rabbitmq-dotnet-client/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Astebet+
Highlights from his pull requests:
- Very significant reduction in memory allocations during normal use of the RabbitMQ .NET client. Once all of his pull requests are merged into version 7.0, the .NET client will use a constant amount of RAM.
You can see the improvements here. 2GiB of allocated objects becomes 113MiB. Amazing!
- He has contributed a lot of code cleanup. This is tedious work that needed to be done.
- He fixed a potential deadlock and improved how we’re using threads.
Contributor two: GitHub user Brandon Ording @bording
Brandon is a very active contributor to NServiceBus, which can use RabbitMQ as its messaging system.
https://github.com/rabbitmq/rabbitmq-dotnet-client/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Abording
He has provided a very keen eye with regard to backwards compatibility and ensuring the RabbitMQ .NET client is a “good player” with other software and developer platforms.
He is in the middle of cleaning up the public API so that only the necessary entities are visible to applications that use the library. This will give us more flexibility going forward to change the internals of the library without having to worry if someone is using an API feature.
A Considerate Contribution Process
If you want to create a welcoming contribution experience for your project, try this. Place yourself in the position of a new contributor and evaluate the process required to contribute to your project. Ask these questions:
- Can you get to the code repository easily?
- Can you quickly set up a build system?
- Can you easily test your changes?
- What is the pull request process like and what other acceptances are required to become a contributor?
If attracting external contributors is a priority for your project, then you must invest in making the public process for contribution as open and straightforward as possible. Additionally, you’ll need to evolve that process and toolset over time, along with trends in public preference.
RabbitMQ is old enough to have started with a homegrown build system in 2007 and the source code was stored in a self-hosted Mercurial repository (this was before GitHub). When your project uses a non-standard build system, you cannot reasonably expect potential contributors to know how to build and test their pull requests. In 2010, we began mirroring our repository to GitHub to provide easier access to code and to support GitHub pull requests. And in 2015, we formally moved our entire codebase over to GitHub. In 2016, the RabbitMQ team invested in re-architecting our proprietary build system and moved to standardized build-process tooling. Today RabbitMQ is built using the Erlang programming language (Erlang.mk) and some Rebar. Moving to well-supported standardized build components has made it easier for potential contributors to set up personal build environments and quickly and easily dig into contributing fixes and enhancements to the RabbitMQ message broker. Migrating from a proprietary build system isn’t likely to be an issue for a recently launched project, but it serves as a use case for the kind of major project renovation that we needed to undertake in order to connect with potential contributors.
We also made additions to the RabbitMQ build process specifically to benefit external contributors and to help improve the quality of their contributions, such as setting up Travis CI for key sub-projects – because some portions of the Concourse CI we use internally for automated testing are not available to the public. Travis CI is provided specifically to support external contributors’ ability to automate their testing.
In conclusion, if you’re fortunate enough to be part of an open source project and would like to see a boost in public contributions evaluate your investments in the community engagement and see if you can improve by:
- Enabling and supporting open communication via channels that your community wants to use.
- Being responsive to communications on those channels and engaging in positive conversation about how people can engage. Likewise, be responsive to pull requests and provide guidance on rejections.
- Making the process of building, testing and contributing as easy and efficient as possible.
By implementing these recommendations, your project can build a reputation as one that respects and encourages community participation. The maintainers of RabbitMQ are very grateful to the many talented individuals that have stepped over the line from user to contributor and made significant improvements in code, documentation and the RabbitMQ server, as well as those that participate by creating blogs, videos, tutorials, trainings and various other content. Thank you.
You can learn more about the RabbitMQ client and stay up-to-date on new open source projects, data and developments by queuing up our blog and following us on Twitter (@vmwopensource).
