Growing the number of active maintainers

I think the Linux Foundation is great example both for the organisational setup and the source code maintenance.
I didn’t yet look into the details of how the Kernel is maintained. The only news I heard recently from LinuxCon is that they wish to have more Kernel maintainers. Do you have any good reference on how they organize the work?

The following links may give enough details about Linux Kernel Development Model.

1 Like

Like @steve1 mentioned, I also have limited time to help, but would be willing. I’ve made a few small contributions to insteon and zwave bindings related to my unsupported-at-the-time hardware, but I haven’t been able to do anything major.

I’m a software developer by trade and I’d be happy to lend my skills as well. After reading your other post, I looked at some of the open PRs. Maybe I made a mistake starting at the oldest, but I looked at ones that caught my eye every one I looked at had messages from @teichsta to the PR requester asking if they made any progress since the last interaction. I wanted to try and review at least one, but then that whole “limited time to help” thing caught up to me.

Not sure I have much else to add at this point, but wanted to share my experience and let @Kai know that I at least noticed his original post and attempted to do something.

1 Like

I think there are a lot of users who are like me:

  • enthusiasts for technologies for ages
  • some basic tech know-how with mainstream technologies (e.g. setting up a windows machine, installing software, configuring parameters, adapting registry entries, etc.)
  • but no real developer (maybe “some” (bad?) experiences with various programming languages (VBA, Java, C#, SQL)) but more a kind of “experimentals” no real code writing
  • using open source software only if it is strongly recommended by friends or it is the last alternative
  • being part of an open source developer community is like being the exot and without any experience in that environment I prefer to stay on the “reader-side” instead of the “(code)writer side”
  • becoming familiar with openhab due to running from one issue to the next one but always willing to accept the challenge to resolve the current and the next problem (thank you forum)
  • willing to support but have no clue how and where we can support (just donating money is someting between boring, not transparent where the money is really needed and used, no real hans-on help, no real “resolving” a technical issue (either a bug or a change request)

I’m pretty sure that there are hundreds of users who would love to support the further development if the issues could be adapted to the above described skill set. What I see today is that the break down of the backlog could be improved significantly. At least parts like “enhance/update documentation”, “providing examples”, testing and giving feedback, management tasks, etc. could be done by users like me (us). But this needs tasks which says something more than “enhance *%ç/&/( with ?=)()/ç%&” - such issues make it not clear to me what I can do there.

One more thing (no, I’m not an Apple fan):
I know that there are a lot of software engineering companies (mid-size 100-500 FTE) who are searching for NGO projects that they can support - either for participating in the success of the projects (marketing) or educating their staff (say No to more “Hello World” projects!) or for donating reasons. Since IoT is the “the next big thing” but no one has really good ideas (a smart watch is no good idea!) an automated home is not only cool - it fulfills a “need” and this is the argument how to win (money-/developer-)sponsors from the private sector.

Last but not least: thank you to all developers who have invested their private time in this project.


1 Like

Right, those people are very valuable and they build the community - they are what I consider the contributors. What I am looking for through this thread are people organizing the work, i.e. maintaining the backlog, keeping it clean, easy to understand and up to date (besides many other things). So far Thomas was the one doing this for openHAB 1, but he couldn’t cope with it anymore. I am already taking care of openHAB 2 and Eclipse SmartHome while doing major core development work there, so there is simply no chance that I could step in. Luckily, we have already found two great maintainers with @hakan and @steve1 who are both doing a tremendous job here - within a few days, we went below 400 open issues, which is a huge step forward already; thanks!

But since you were asking for “simple” jobs that people could help with, I actually asked for some of those things with not too much feedback so far, so possibly it is a good time to repeat them now:

  1. I would love if people could test openHAB 1 add-ons on openHAB 2 and give feedback, see this thread
  2. We need a wikipedia entry! Native english speakers are very much invited to help, see here.

It would be great, if we had dedicated people who would look out for such fund raising and winning sponsors for sure! This is also a very important reason for me wanting to found the charity organisation, because this is the legal entity which could then be sponsored by those companies.

This is where I have been trying as time permits, and helping those folks that I can as I learn the bindings. My latest one is here, though it may not have been seen. Enphase Energy binding works .

also many, many thanks from my side! I didn’t manage to keep the list small but you (as representatives of all the others being active) helped to gain traction in this area again.

Well done!!

there’s probably a 3.) see - this meetup thread

I just would like to publicly thank @hakan for the enormous amount of job he is doing and for the great commitment


So there are many open PR’s with the newbinding label. How can those be integrated faster?

Maybe the review process could be split into multiple phases so that it could be done by multiple people, for example:

  • stage 1: check for code cleanliness, correctness, documentation -> could be done by ‘junior’ reviewers
  • stage 2: architectural review -> could be done by ‘senior’ reviewers
  • stage 3: operational quality review -> one or two beta users confirm the binding really works

Having a staged approach would create a ‘reviewer career path’ were people could start reviewing the basics and grow into becoming a senior reviewer…

Maybe Sonar with some custom rules could also offload some of the work.

And last but not least, what can I do to help?


I very much like the idea!
So any “newbie maintainer” could pick any PR and review it (it is probably enough to leave a comment on it, so that nobody else picks it). Once he feels he is ready for step 2, he can apply for becoming a @maintainer and show his “proof of records” as a qualification.

I like that idea. From my side I’m very willing to support but I feel I lack the skills to be reviewing others bindings in a full way. In the proposed way indeed it would be easier to contribute

FTR: The stage 1 could be simply checking that the coding guidelines are fullfilled. Senior maintainers should actually help to improve those guidelines, whenever they come across common problems that are not covered by them.

So we should make it easier for people to get started. I can also imagine it could be done by two people working together in a mentor/mentee approach.

simply checking that the coding guidelines are fullfilled

Let’s try to automate what can be automated.

Why does this remind me of Lemmy Kelmister’s funeral, and the whole motorbike culture? :wink: :wink:

All joking apart, you will have people that are more comfortable in either stage, indep. of “seniority”. Me for example, after cranking out all these bindings, would like to spend more time on adding features to the core (Notification for example), knowing that I am also sometimes a lazy bum that fails at stage1 for my own work.


Why does this remind me of Lemmy Kelmister’s funeral, and the whole motorbike culture?

Honestly, I have no idea. Is there a movie I should see?

you will have people that are more comfortable in either stage, indep. of “seniority”.

Seniority may not have been the best word to use. Of course some people will feel more comfortable in stage 2 or 1 depending on their personal preference. But I do believe people need to go through the different stages. If someone doesn’t understand the value of of code cleanliness, simplicity and documentation, it will be impossible for them to do a good job on an architectural review.

knowing that I am also sometimes a lazy bum that fails at stage1 for my own work

I still have to meet the person who has never ever taken a short cut…

I back davy’s idea and it’s something we do at my work place that works well.

However from experience you can still end up with a bottle neck, inevitably we have more junior reviewers than senior reviewers, and by the nature of seniority they usually have other commitments and/or problems to solve but we ask that they endeavor to find the time to keep the system moving.

As I mentioned to Kai I’d like to help out a bit, so if this is the system agreed upon I’ll try and start looking at open issues or un-reviewed PRs over the coming weeks.

[off-topic on]
Never seen a documentary on how motorbike clubs function? it is remarkably very similar. :wink: Lemmy, of Motorhead fame, just happen to pass away.
[off-topic off]

@Kai, how can we move forward with this? Should we document a formal process? Or can people just start reviewing a PR after adding a comment ‘Stage 1 review started’ to the PR?

For a quick start, I think we can agree on this for now.
Then, we should update the maintainer manual accordingly.