FOSDEM 2018 - Distributions are not Democracies

This session will explore many different governance and decision making models in the Distribution world.
Few projects aspire to operate under wholly democratic principles. This talk will explore some of the many flaws and problems with this approach, and how projects often struggle to operate democratically and at scale. Alternatively the session will also discuss the benefits, and weaknesses of less democratic governance models, such as Technical Committees, Governing Boards, and Benevolent Dictators for Life. Finally the talk will explore a simple, but scalable model of Distribution governance, empowering, enabling, and supporting the contributors in your project to create an environment where "Those that do, decide".

Transcript

1. Richard Brown openSUSE Chairman rbrown@opensuse.org Distributions are not Democracies... ...and that’s okay
2. Does Governance Matter?
3. CC-BY-SA Gage Skidmore
4. OGL v.3
5. CC-BY-SA WDKrause
7. Who does your Project serve?
8. Users
9. Users
10. Our Projects do not exist to benefit Users
11. Our Projects SHOULD not exist to benefit Users • Users should benefit from the ‘Products’ of our Projects, our sofware, our distributions. • But the Project exists to provide a collective benefit to our Maintainers/Contributors/Volunteers • This collective benefit is made manifest in the Project’s structure, organisation, ethos, and ultimately how it practices Governance
12. Maintainers? Contributors? No, Volunteers! • Any Open Source Sofware Project lives or dies by the actions of its’ Contributors • These people may write code, provide artwork, support users, or share ideas • They may be employed to do that work, or not • Unless they’re hired as slave labour, they’re still Volunteers • Open Source Projects shouldn’t use slave labour
13. “Linux is only free if your time has no value” - Jamie Zawinski
14. The Curse of the Committee
15. Apache httpd • All major changes must be voted on • Any Apache developer can vote (+1), abstain (0) or veto (-1) • Only “active httpd developers” have binding (+1) votes • 3x binding votes and no (-1) vetos required
17. Scale • Can only handle a specific capacity of incoming requests • Adding more members to the committee can inversely afect committees bandwidth • Raises barrier to entry (in either perception or reality) for new volunteers
18. Debian Technical Committee • Decide on any matter of technical policy • Decide any technical matter where Developers’ jurisdictions overlap • Make a decision when asked to do so • Overrule a Developer • Ofer advice
19. Debian & systemd • Technical Committee decided to support systemd by default • No decision on whether packages may depend on a specific init system • Some people don’t like systemd
21. Afer the apocalypse • Strife from Feb 2014 – Nov 2014 • Final decision “General Resolution is not required” on the topic of binding packages to an init system • Lots of upset volunteers & users on each side of the debates • Fork (Devuan)
22. Welcoming our Corporate Overlords
23. “Corporations Are People, My Friend” - Mitt Romney
24. Fedora & Red Hat Fedora Council • Primary Role: identify, organise and enable the Project’s short, medium, and long term goals • Currently 10 people • 8 Employed by Red Hat • 3 Directly appointed by Red Hat • 2 Elected by community (1 Red Hat employee)
25. Fedora & Red Hat Fedora Engineering Steering Committee • Roles: Approval/Coordination of Changes, Maintainer Dispute Resolution. Responsible for what sofware is ofered to end users. • Currently 9 people • 7 Employed by Red Hat
26. “In real open source, you have a right to control your own destiny” - Linus Torvalds
27. Ubuntu & Canonical • Self Appointed Benevolent Dictator for Life • Community Council – Appointed by SABD4L – Conflict Resolution, Non-Technical Decision Making, etc • Technical Board – Appointed by SABD4L – Responsible for all core technical decisions – Package Selection, Versions, Installation Processes, etc • Sub Teams appointed by CC or TB
28. “In real open source, you have a right to control your own destiny” - Linus Torvalds
29. openSUSE & SUSE?
30. Direct Democracy
31. “It has been said that democracy is the worst form of government except all the others that have been tried.” - Winston Churchill
32. openFATE • openSUSE equivalent to SUSE’s internal feature tracking tool • Designed to allow the community to propose features & vote on them • Hundreds of feature requests • Thousands of votes • Impact on Project’s priorities: Negligible
33. “Democracy is the art and science of running the circus from the monkey cage” - H. L. Mencken
34. Back, to the Future!
35. “Every good work of software starts by scratching a developer’ personal itch” - Eric S. Raymond
36. You don’t need to tell Volunteers what to do • They are going to know what needs to be done • They need to have the tools and environment to do it • They need to feel empowered that they can do it
37. You don’t need to tell Volunteers what to do • They are going to know what needs to be done • They need to have the tools and environment to do it • They need to feel empowered that they can do it • If you tell them what to do, they won’t listen anyway
38. Core Principles • Respect your Volunteers – They don’t have to work with you • Enable your Volunteers – They need the tools and processes to do their work • Trust your Volunteers – The best person to decide anything, is the volunteer doing that thing
39. Core Principles, Pt 2 • Respect, but Challenge – New volunteers should be able to work with, or replace, another • Enable, but Guide – The tools and processes should encourage good practices for sustainable maintainership • Trust, but Verify – When conflicts of opinion arise, you need a tie-breaking solution
40. “Those who do, decide” - openSUSE
41. “Those who do, decide” • Open Source works best when decisions are made as close as possible to the actual contribution – ie. the Volunteers doing the work • Self-organised Teams - Volunteers working on the same thing should work together
42. “Those who do, decide” • Quality & Common Standards defined by consensus, enforced by Open Source automation overseen by willing senior Volunteers (Release Managers/Engineers)
43. Do-ocracy In Action • Anyone can login to openSUSE’s OpenBuildService and submit any change to any package • No Permission Required. Existing Volunteers will be automatically notified & given the opportunity to review your change
44. Do-ocracy In Action • Contributions do the talking. Automated OBS checks & openQA functional testing ensure your change will work. Majority of review efort is therefore contemplating “how easy is it to carry this change ?” • No Steering Committees, Community Managers, Technical Boards, Benevolent Dictators or Project Managers
45. openSUSE & systemd • First major distribution to adopt systemd (July 2010) • Default since September 2012 • Changes made by volunteers who wanted it • Volunteers who didn’t want it always had the opportunity to contribute in a diferent direction • No major strife
47. Do-ocracy - Benefits Agility – Able to rapidly respond to changes in upstream projects & adopt new technologies Flexibility – Every upstream is diferent, with diferent release schedules and support lifecycles, openSUSE volunteers can adapt their way of working for maximum eficiency and comfort Freedom – No restrictions on finding innovative solutions. “If it works, and you’ll support it” is the primary acceptance criteria.
48. Do-ocracy - Risks Freedom – “Paradox of Choice” - too many choices can be overwhelming to new volunteers Misconceptions – Established volunteers may be seen as de-facto decision makers and inadvertently discourage new innovative volunteers. Few newcomers want to ‘rock the boat’ even when the Project welcomes it. Deadlock – Multiple volunteers may not always agree, who decides if compromises cannot be found?
49. Organisational Checksums
51. Conflicts happen • Volunteers are human (mostly) • Humans have diferent ideas • Sometimes these diferent ideas are not compatible with each other • Compromises can be hard to find
52. Conflicts are not technical decisions • Volunteers arguing over a technical diference is NOT a technical problem • Conflict resolution needs a human touch • All sides need to be heard, and feel they were heard
53. Conflicts are not technical decisions • Compromises can be found to the strangest problems • Decision making in conflicts must ALWAYS be a last resort • Previously conflicting volunteers ultimately will still be implementing the solution
54. If you have a problem...
55. openSUSE Board “Leads” the overall Project • Helps resolve conflicts • Central point of contact • Decision makers of last resort • Communicates community interests to SUSE (and visa versa)
56. openSUSE Board Composition 5 Board Members • Elected by established contributors (openSUSE Members) • 2 year term • 2-3 elected each year • No more than 2 Board Members can have same employer
57. openSUSE Board Composition 1 Chairperson • Appointed by SUSE • Full voting Board Member, with additional responsibility to provide continuity and to represent SUSE to the Board & Project • Elected Board Members can appeal to replace Chairperson
58. “Corporations Are People, My Friend” - Mitt Romney
59. Corporations can be people too • In a do-ocracy, a corporation must contribute as peers • No control, besides that which they share as volunteers in the project • They have to keep up with their ‘upstreams’ - other volunteers create work for them • They have to persuade the project at large to work with them • Keeps them honest
60. Corporations know how to do this • Kernel • OpenStack • Xen • Almost all open source corporations practice these principles with their ‘upstreams’, but many shirk doing so in their own distributions
61. In Conclusion
62. ❤ your Volunteers • Distributions, get rid of your Technical Committees and Dictators • Favour Do-ocracy over Democracy • Trust & Empower your Volunteers to drive your project • Have a conflict resolution/mediation body. Limit their scope. • Corporations, yield control. Treat your distribution communities like your other upstreams. • Have a lot of fun!
63. Join Us at www.opensuse.org
64. License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ General Disclaimer This document is not to be construed as a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. Credits Template Richard Brown rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/