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.

Transcript

1. Richard Brown openSUSE Chairman rbrown@opensuse.org How to change anything openSUSE is what you make it Jiri Srain Project Manager Future Technology Team jsrain@suse.com
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
4. Tumbleweed
6. “Every good work of software starts by scratching a developer’ personal itch”
10. “Those who do, decide”
11. “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
12. “Those who do, decide” • Quality & Common Standards defined by consensus, enforced by Open Source automation overseen by willing senior Volunteers (Release Managers/Engineers)
13. “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
14. “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
15. 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
17. “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.
18. “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?
19. Organisational Checksums
21. 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
22. 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
23. 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
24. If you have a problem...
25. 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
26. Getting Started with Contributing
27. Primary Communication Channels Mailing Lists – opensuse-factory@opensuse.org - Development list – opensuse-project@opensuse.org - 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
28. 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
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. Do It You’re all set! Get to work. Start your engines! Time to inconvenience some electrons with your code!
36. SUSE & openSUSE
37. 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
38. 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
39. 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
40. SUSE & openSUSE – Working Together Stable code & contributions Upstream innovations Mutual collaboration
41. 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
42. YaST Example
43. What is YaST • Yet another Setup Tool • Installation and Adminitration tool of openSUSE • Mostly developed inside SUSE
44. How can you contribute? • Write your own module • Fix your favorite bug • Implement your missing feature
45. 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?
46. 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
47. Need help to implement your change? • Don’t hesitate to ask! • yast-devel@opensuse.org • #yast channel on freenode.org
48. Created a PR and nothing happened? • Yes, that can happen :-( • Contact us to get our attention • Do not take any feedback personally
49. Anything you can help with? • YES!!! • Why not to try fixing a simple bug? • https://bugzilla.opensuse.org/buglist.cgi?quicksearch=yast-community
50. Where can you learn more? • https://en.opensuse.org/Portal:YaST • http://yast.opensuse.org/ • And, most importantly: Just ask if you need more :-)
51. 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!
52. Join Us at www.opensuse.org
53. 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/