Upgrade to Pro — share decks privately, control downloads, hide ads and more …

FOSDEM 2018 - Distributions are not Democracies

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".

Richard Brown

February 04, 2018

More Decks by Richard Brown

Other Decks in Programming


  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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)
  8. 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)
  9. 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
  10. “In real open source, you have a right to control

    your own destiny” - Linus Torvalds
  11. 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
  12. “In real open source, you have a right to control

    your own destiny” - Linus Torvalds
  13. “It has been said that democracy is the worst form

    of government except all the others that have been tried.” - Winston Churchill
  14. 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
  15. “Democracy is the art and science of running the circus

    from the monkey cage” - H. L. Mencken
  16. 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
  17. 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
  18. 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
  19. 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
  20. “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
  21. “Those who do, decide” • Quality & Common Standards defined

    by consensus, enforced by Open Source automation overseen by willing senior Volunteers (Release Managers/Engineers)
  22. 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
  23. 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
  24. 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
  25. 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.
  26. 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?
  27. 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
  28. 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
  29. 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
  30. 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)
  31. 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
  32. 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
  33. 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
  34. 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
  35. ❤ 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!
  36. 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 [email protected] Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/