I gave a talk about MQTT V5 today at EclipseCon France, and at the end I gave the usual spiel about ways that people could help. After the talk, Cyrille Francois tweeted a great pictorial summary of the talk, as he did for other talks he attended. (Thanks Cyrille!) As part of the title of the tweet was the phrase “we need help”.
I’d like to add some more context to this. It’s of course true that we can always use more help. It’s also true that we are getting a lot of help already: issues, PRs, comments and feedback of all sorts. For example, one recent contribution to the Paho C client adds WebSocket support – thanks Keith! Paho is one of the most active Eclipse IoT projects as shown by this table extracted from an Eclipse IoT Metrics report:
Paho is also one of the most popular, in website visits:
although that metric is not definitive by any means, nor is this one:
as people obtain software from all the projects by many different means, not just downloads, but I don’t mind showing it given where Paho lies on it! At the time of writing, the Paho components have been starred 4108 times in total (up from 1766 last year) and users have forked the code 1969 times (up from 967). The number of committers now stands at 13, and the number of code authors is at least 88 (up from 50).
Paho is composed of distinct projects; client libraries and utilities, so those 13 committers are spread thinly across them. It’s an Eclipse convention that one committer doesn’t interfere in another’s repository without permission. Even without that, each committer is generally responsible for one or two specific components.
When I became project lead I read the Eclipse documents quite thoroughly to learn what was expected. About new committers, this is written:
Contributors who have the trust of the project’s committers can, through election, be promoted committer for that project. The breadth of a committer’s influence corresponds to the breadth of their contribution. A development team’s contributors and committers may (and should) come from a diverse set of organizations. A committer gains voting rights allowing them to affect the future of the project.
Becoming a committer is a privilege that is earned by contributing and showing discipline and good judgment. It is a responsibility that should be neither given nor taken lightly, nor is it a right based on employment by an Eclipse member company or any company employing existing committers.
I have taken these words quite seriously, maybe too seriously. Should I lighten up a bit?
If anyone would like to become a committer then you definitely let me know and we can start talking. Whether that’s for a particular component, or a wider remit such as helping with the website, or release process, it isn’t just coding. There’s process development, design, documentation, tests for continuous integration, release packaging and distribution for example.
Of course you don’t need to be a committer to help by opening issues, responding to issues you didn’t open, raising PRs, or answering questions on mailing lists or forums. If you haven’t done any of that already, you should start there. There are many reasons to contribute to open source projects too. Here’s what looks like a pretty helpful <a href=”https://opensource.guide/how-to-contribute/”>guide</a>.
At EclipseCon today, Simon Phipps gave a great talk about <a href=”https://www.eclipsecon.org/france2018/session/third-decade-open-source-why-it-worked-and-whats-next”>Open Source</a>, where it came from, where it’s going and why you should think about contributing if you use open source projects. I expect that the slides will be up soon and you should take a look. Seeing such talks in person is of course one of the benefits of attending conferences such as EclipseCon – you should do that too!