I feel rather bad answering my own answer, but according to multiple pointers - forum is not best place to discuss development issues. In this post, I am going over Governance | openHAB. Anyhow, maybe later this post could be moved to github and discussed by maintainers or AC itself if it will find it necessary.
I get that defining rules for open source project is a difficult task cause there is a little of people who can afford paying bureaucracy cost by sacrificing their own time.
Starting from its principles - Transparency, Openness and Meritocracy. One of first links which are mentioned is Sign in to GitHub · GitHub, a list of maintainers working on project which is invisible for anyone who is not a maintainer. On opposite side I can mention Apache Karaf project (used by openHAB) where all nominated committers, their names are publicly listed: Apache Karaf commiteers. I get that contributors are listed in each repository, but why not listing them in one place?
Another comparison to the transparency and oneness of Apache projects - in Apache projects there are usually three mailing lists (forums) - user, dev and private. First two are public while private is kept secret (for project members and apache members) to keep primarily two things - a committer elections/voting and security issues handling until its confirmed and fixed. In practice all major development decisions must be taken in a public discussion (at
firstname.lastname@example.org). Agreement shall be recorded so anyone can confirm it later on. Not sure how the github teams translate to that and what is the role of core and adons maintainers teams.
For comparison, the maintainer teams rules which apply to all github teams (maintainers), hence contribution criteria, are invisible to external people.
The governance page states that:
Nominations must be done on the GitHub team discussion page (as a public post) and voting is done through reactions on that post.
Which seems to not be valid since these pages are invisible for external members unless github team is a private forum for project maintainers (just like private@apache). Its unclear to me. I suppose that documentation could be improved in that matter to answer why github teams for core/addon etc. repositories are invisible for outside collaborators. If it was answered in forums or github it still doesn’t count as governance policy shall be clear and available in one place.
Going to next point - the Architecture Council - as an external contributor I don’t really see if its acting whereas (for comparison) I can go to any Apache project and see what they do in their dev@ mailing lists, what they plan or discuss to improve their project. More over, even not being an apache committer I can bring there a topic to discuss without creating an issue in the tracker.
Again, I don’t think its feasible to expect anyone to sacrifice tremendous amounts of time to keep answering any single request coming to this body, but there is no way for external contributors to ask for AC attention. Usual way with github issues belongs to maintainers, hence problem reflected in this topic and brought by @franks are invisible for AC as an institution.
Going now to openHAB Architecture Council responsibilities:
The openHAB Architecture Council (AC) serves the community by identifying and tackling any issues that hinder openHAB’s continued technological success and innovation, widespread adoption, and future growth. This involves technical architecture as well as open source processes and social aspects. Comprising the finest technical leaders from all community stake holders, it is the council’s goal to keep the project successful and healthy, the processes simple and smooth, and the communities vibrant and cohesive.
How I, as an end user or supplier or external contributor can ensure that AC is tackling for a technological success and innovation? By going over github issues the AC members are taking care of? I could, but the AC members are not indexed.
Another point on AC, again comparing to Apache projects, is that this seems to be fairly limited body with no space for more people coming into it over the time. I think that current members were established somewhat when ESH migration been done and there was no single new member, whereas in Apache this is kind of metric if project is attractive for people to join effort and take responsibility about it. With just 5 people in the AC there is in practice less than 1 person for each main OH repository (core, addons, ui, ios, android, cloud). How governance page can talk about a meritocracy, if there is a fairly limited pool of people to decide, who can’t be removed (they have to remove themselves), and no way for other people who’s involvement can superseded existing members to join? To me this sounds more similar to oligarchy. Not sure how many project maintainers are there, someone who has access to all these pages can simply do math.
I did small comparison based on Apache and other projects and ohloh.net stats:
I don’t have any strict measures here, I just try to compare scale of openHAB project to others. I don’t have any data for other smarthome related projects other than lines of code and contributors, cause I don’t follow them and their process. What’s notable - ActiveMQ and Karaf are mostly written in Java, just like openHAB.
Despite of bigger codebase than ie. Karaf, openHAB have much smaller set of people who can vote on adding new members to “AC” who can decide on project future and drive its development. From scale perspective I put for comparison Eclispe SmartHome (RIP) and Jersey, where second one was utilized by OH < 3.0 to render all web services. Jersey is one of quite popular frameworks in Java lands and its still much smaller than openHAB.
What is visible, current AC does not reflect the structure of contributions and does not give any weight to these who are committing most of the time and work to the project. More over, the form AC have been made does not leave space for that. I get that there are just 5 seats, but this limit is completely artificial.
Discussions and decisions are done on the Github team page. Decisions are taken unanimously. This is the case if no member of the AC vetos against a proposed resolution within a week of the call for votes on the topic.
Can we, as part of openess learn how many discussions AC had, how many of them got resolved unanimously, how many ended up with veto?
Overall I think that current way AC works is outdated. It does not reflect scale of the project, it does not reflect contributions to the project any more, just an earned flag. Looking at evolution of Architecture Council (or its lack) over the time, I think it might be a valid time to open a wider discussion if its form is still serving the project. AC is primary body to lead improvements of the project, so maybe its time for it to think how it can serve it better?
Looking at 12 month stats rendered by ohloh it seems that even 5 seat AC could be reshaped to reflect project activity. Yet, if we take openHAB core and each individual repository the picture will be completely different.