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. Richard Brown
    openSUSE Chairman
    [email protected]
    Distributions are not
    ...and that’s okay

    View Slide

  2. Does Governance Matter?

    View Slide

  3. CC-BY-SA Gage Skidmore

    View Slide

  4. OGL v.3

    View Slide

  5. CC-BY-SA WDKrause

    View Slide

  6. View Slide

  7. Who does your Project

    View Slide

  8. Users

    View Slide

  9. Users

    View Slide

  10. Our Projects do not exist to benefit Users

    View Slide

  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

    This collective benefit is made manifest in the Project’s
    structure, organisation, ethos, and ultimately how it practices

    View Slide

  12. Maintainers? Contributors? No, Volunteers!

    Any Open Source Sofware Project lives or dies by the actions of its’

    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

    View Slide

  13. “Linux is only free if your time has no value”
    - Jamie Zawinski

    View Slide

  14. The Curse of the

    View Slide

  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

    View Slide

  16. View Slide

  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

    View Slide

  18. Debian Technical Committee

    Decide on any matter of technical policy

    Decide any technical matter where Developers’ jurisdictions

    Make a decision when asked to do so

    Overrule a Developer

    Ofer advice

    View Slide

  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

    View Slide

  20. View Slide

  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)

    View Slide

  22. Welcoming our Corporate

    View Slide

  23. “Corporations Are People, My Friend”
    - Mitt Romney

    View Slide

  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)

    View Slide

  25. Fedora & Red Hat
    Fedora Engineering Steering Committee

    Roles: Approval/Coordination of Changes, Maintainer Dispute
    Resolution. Responsible for what sofware is ofered to end

    Currently 9 people

    7 Employed by Red Hat

    View Slide

  26. “In real open source, you have a right to
    control your own destiny”
    - Linus Torvalds

    View Slide

  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

    View Slide

  28. “In real open source, you have a right to
    control your own destiny”
    - Linus Torvalds

    View Slide

  29. openSUSE & SUSE?

    View Slide

  30. Direct Democracy

    View Slide

  31. “It has been said that democracy is the worst
    form of government except all the others that
    have been tried.”
    - Winston Churchill

    View Slide

  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

    View Slide

  33. “Democracy is the art and science of
    running the circus from the monkey cage”
    - H. L. Mencken

    View Slide

  34. Back, to the Future!

    View Slide

  35. “Every good work of software starts by
    scratching a developer’ personal itch”
    - Eric S. Raymond

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  40. “Those who do, decide”
    - openSUSE

    View Slide

  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

    View Slide

  42. “Those who do, decide”

    Quality & Common Standards defined by consensus,
    enforced by Open Source automation overseen by willing
    senior Volunteers (Release Managers/Engineers)

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  46. View Slide

  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.

    View Slide

  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
    Deadlock – Multiple volunteers may not always agree, who decides if
    compromises cannot be found?

    View Slide

  49. Organisational

    View Slide

  50. View Slide

  51. Conflicts happen

    Volunteers are human (mostly)

    Humans have diferent ideas

    Sometimes these diferent ideas are not compatible with each

    Compromises can be hard to find

    View Slide

  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

    View Slide

  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

    View Slide

  54. If you have a problem...

    View Slide

  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)

    View Slide

  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

    View Slide

  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 &

    Elected Board Members can appeal to replace Chairperson

    View Slide

  58. “Corporations Are People, My Friend”
    - Mitt Romney

    View Slide

  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

    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

    View Slide

  60. Corporations know how to do this




    Almost all open source corporations practice these principles with
    their ‘upstreams’, but many shirk doing so in their own

    View Slide

  61. In Conclusion

    View Slide

  62. ❤ your Volunteers

    Distributions, get rid of your Technical Committees and

    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!

    View Slide

  63. Join Us at www.opensuse.org

    View Slide

  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.
    Richard Brown
    [email protected]
    Design & Inspiration
    openSUSE Design Team

    View Slide