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

openSUSE is what you make it

openSUSE is what you make it

How to change anything you want in the project

This talk is for openSUSE's aspiring new contributors, existing contributors, users, detractors, or just anyone curious at all about openSUSE. In other words, if you're at this conference, you should consider being at this talk ;)

The session will detail how openSUSE does what it does, and most importantly how openSUSE strives to empower ANYONE to be able to contribute to the project.

The presentation will outline examples of not only basic contributions to the distributions (Leap & Tumbleweed), but also explain through example and anecdote how anyone can influence, steer, and drive the direction of the openSUSE Project, including changing the scope of the Project by introducing new sub projects.

The session will end with a Q&A section for anyone to ask any question about contributing to the project in general, to provide feedback on any potential improvements to openSUSE's current contribution story, or to ask those first questions about that first contribution so that YOU can start making openSUSE YOURS.

Richard Brown

May 25, 2018

More Decks by Richard Brown

Other Decks in Programming


  1. Richard Brown openSUSE Chairman [email protected] How to change anything openSUSE

    is what you make it Jiri Srain Project Manager Future Technology Team [email protected]
  2. The openSUSE Project • Open Source Community Project sponsored by

    SUSE • Founded to “Promote the use of Linux everywhere” • Produced the openSUSE Distribution • Announced 9th August 2005
  3. “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
  4. “Those who do, decide” • Quality & Common Standards defined

    by consensus, enforced by Open Source automation overseen by willing senior Volunteers (Release Managers/Engineers)
  5. “Those who do, decide” 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
  6. “Those who do, decide” In Action • Contributions do the

    talking. Automated OBS checks & openQA functional testing ensure your change will work. Majority of review effort is therefore contemplating “how easy is it to carry this change ?” • No Steering Committees, Community Managers, Technical Boards, Benevolent Dictators or Project Managers
  7. 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 different direction • No major strife
  8. “Those who do, decide” - Benefits Agility – Able to

    rapidly respond to changes in upstream projects & adopt new technologies Flexibility – Every upstream is different, with different release schedules and support lifecycles, openSUSE volunteers can adapt their way of working for maximum efficiency and comfort Freedom – No restrictions on finding innovative solutions. “If it works, and you’ll support it” is the primary acceptance criteria.
  9. “Those who do, decide” - 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?
  10. Conflicts happen • Volunteers are human (mostly) • Humans have

    different ideas • Sometimes these different ideas are not compatible with each other • Compromises can be hard to find
  11. Conflicts are not technical decisions • Volunteers arguing over a

    technical difference is NOT a technical problem • Conflict resolution needs a human touch • All sides need to be heard, and feel they were heard
  12. 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
  13. openSUSE Board “Leads” the overall Project • Act as a

    central point of contact • Helps resolve conflicts • Decision makers of last resort • Communicates community interests to SUSE (and visa versa) • Initiates discussions about new project-wide initiatives
  14. Primary Communication Channels Mailing Lists – [email protected] - Development list

    [email protected] - Project related list – https://lists.opensuse.org - Index of more specific lists IRC – #opensuse-factory @ irc.freenode.net – Development chat – #opensuse-project @ irc.freenode.net – Project related chat – #opensuse-chat @ irc.freenode.net – Off Topic chat – #opensuse-* @ irc.freenode.net – Many more channels available
  15. Do your homework Understand your topic • Don’t assume, make

    sure you know what you’re talking about Research • Google, openSUSE wiki, other FOSS Projects. Where have others tried and failed? Discuss • Bounce ideas off other interested people in IRC, at openSUSE Conferences, etc
  16. Plan your solution Knowing what you want to do is

    only the beginning Plan your solution, answer “how will you do it?” Details optional – Be sure on the direction and final outcome, details can always be finalised while in progress
  17. Do you need help? If “No” – DON’T WAIT, proceed

    directly to ‘Do it’ If “Yes” – Share with Project, Listen, Respond, and then Decide how to do it
  18. Getting Help – Share with the Project Present plan –

    Avoid open ended questions – “This is what we need to do, and what I intend to do about it” – Describe findings from “Do your homework”, include proofs of concept if possible – Post on appropriate openSUSE Mailinglist It’s now the responsibility of the Project to convince you to do things differently
  19. Getting Help – Listen Listen to feedback – The openSUSE

    Project contains many experienced contributors, listen to them. – Consider their feedback. – A well informed & well reasoned proposal should illicit well reasoned & informative responses Deciding to do something different at this point is not a ‘failure’, but a learning experience
  20. Getting Help – Respond Respond to feedback – Fast feedback

    drives innovation. – Discuss why you do, or do not agree with feedback. – Explain why. These discussions are how you find colleagues to contribute with you
  21. Getting Help – Decide Decide what to do – You

    do not need to accept all, or any, of the feedback – If you remain convinced that your planned course is correct, continue on it – If something gets in the way, find compromises Two competing solutions in different directions can often be resolved by accomplishing both
  22. Do It You’re all set! Get to work. Start your

    engines! Time to inconvenience some electrons with your code!
  23. SUSE & openSUSE • openSUSE is an independent Open Source

    Project – Sponsored by SUSE, AMD, IP Exchange, B1 Systems, Heinlein & AppliedMicro • SUSE acts as primary sponsor & patron • SUSE formally contributes as peers in the community & encourages it’s staff to also contribute in their spare time
  24. SUSE & openSUSE – Working Together • Leap shares a

    common code base with all SUSE Linux Enterprise Service Packs • Tumbleweed will provide the base for all future SUSE Linux Enterprise Major Releases
  25. SUSE & openSUSE – Working Together • Complete openSUSE Toolchain

    is also used by SUSE internally, including Open Build Service, openQA & KIWI • Not just tools & technology, openSUSE processes often inspire improvements to SUSE development processes
  26. SUSE & openSUSE – Working Together Stable code & contributions

    Upstream innovations Mutual collaboration
  27. SUSE & openSUSE – Working Separately • openSUSE is free

    to set it’s own direction & all that entails • Examples – Different default desktop (KDE in openSUSE, GNOME in SLE) – Different product scope (Unified openSUSE Distros, SLES/SLED) – Different installation workflow
  28. What is YaST • Yet another Setup Tool • Installation

    and Adminitration tool of openSUSE • Mostly developed inside SUSE
  29. How can you contribute? • Write your own module •

    Fix your favorite bug • Implement your missing feature
  30. How do you provide your code? • Devel project in

    Open Build Service – https://build.opensuse.org/project/show/YaST:Head – Similar branches for older releases • Wait: What about git repo?
  31. How do you provide your code correctly? • https://github.com/yast/ •

    Find and fork the needed repository • Implement your change • Create a Pull Request • Answer the reviewer comments • Get it approved and merged
  32. Created a PR and nothing happened? • Yes, that can

    happen :-( • Contact us to get our attention • Do not take any feedback personally
  33. Anything you can help with? • YES!!! • Why not

    to try fixing a simple bug? • https://bugzilla.opensuse.org/buglist.cgi?quicksearch=yast-community
  34. In Closing • You decide what happens in openSUSE •

    No part of the project is off limits to contributors • The Project is here to help • Have a lot of fun!
  35. 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/