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
Tweet

More Decks by Richard Brown

Other Decks in Programming

Transcript

  1. Richard Brown
    openSUSE Chairman
    [email protected]
    Distributions are not
    Democracies...
    ...and that’s okay

    View full-size slide

  2. Does Governance Matter?

    View full-size slide

  3. CC-BY-SA Gage Skidmore

    View full-size slide

  4. CC-BY-SA WDKrause

    View full-size slide

  5. Who does your Project
    serve?

    View full-size slide

  6. Our Projects do not exist to benefit Users

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. The Curse of the
    Committee

    View full-size slide

  11. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 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 full-size slide

  15. 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 full-size slide

  16. Welcoming our Corporate
    Overlords

    View full-size slide

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

    View full-size slide

  18. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  21. 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 full-size slide

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

    View full-size slide

  23. openSUSE & SUSE?

    View full-size slide

  24. Direct Democracy

    View full-size slide

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

    View full-size slide

  26. 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 full-size slide

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

    View full-size slide

  28. Back, to the Future!

    View full-size slide

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

    View full-size slide

  30. 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 full-size slide

  31. 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 full-size slide

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

    View full-size slide

  33. 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 full-size slide

  34. “Those who do, decide”
    - openSUSE

    View full-size slide

  35. “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 full-size slide

  36. “Those who do, decide”

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

    View full-size slide

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

    View full-size slide

  38. 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 full-size slide

  39. 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 full-size slide

  40. 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 full-size slide

  41. 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?

    View full-size slide

  42. Organisational
    Checksums

    View full-size slide

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

    View full-size slide

  44. 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 full-size slide

  45. 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 full-size slide

  46. If you have a problem...

    View full-size slide

  47. 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 full-size slide

  48. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  53. In Conclusion

    View full-size slide

  54. ❤ 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!

    View full-size slide

  55. Join Us at www.opensuse.org

    View full-size slide

  56. 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/

    View full-size slide