A general look into the openSUSE Project, where we've come from, what we're working on, and what sets us apart from other similar open source projects.
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
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
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 staf to also contribute in their spare time
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
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 ofen inspire improvements to SUSE development processes
SUSE & openSUSE – Working Separately ● openSUSE is free to set it’s own direction & all that entails ● Examples – Diferent default desktop (KDE in openSUSE, GNOME in SLE) – Diferent product scope (Unified openSUSE Distros, SLES/SLED) – Diferent installation workflow
Freedom Matters ● All openSUSE Projects are OSI licensed ● Both openSUSE Distributions are GPLv2+ collective works ● Limited “NonFree” Sofware available in Additional Repo – Does not include closed source Linux kernel modules ● No CLA / Copyright Agreement Your contributions, your copyright
“Those who do, decide” ● Open Source works best when decisions are made as close as possible to the actual contribution – ie. the person doing the work ● Self-organised Teams - People working on the same thing should work together
“Those who do, decide” ● Quality & Common Standards defined by consensus, enforced by willing senior contributors (Release Managers/Engineers) ● No Steering Committees, Community Managers, Technical Boards, Benevolent Dictators or Project Managers
“Those who do, decide” - 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 contributors 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.
“Those who do, decide” - Risks Freedom – “Paradox of Choice” - too many choices can be overwhelming to newcomers Misconceptions – Established contributors may be seen as de-facto decision makers and inadvertently discourage new innovative contributors. Few newcomers want to ‘rock the boat’ even when the Project welcomes it. Deadlock – Multiple contributors may not always agree, who decides if compromises cannot be found?
openSUSE Members ● Established Contributors with a history of “Sustained and Substantial” contributions to the openSUSE Project ● Receive @opensuse.org email addresses ● Voting rights in Board Elections & Major Decisions ● Has right to recall the Board (25%+ recall vote required)
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)
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
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. ● Holds veto power. ● Elected Board Members can appeal to replace Chairperson.
openSUSE Board Composition 1 Treasurer ● Appointed by openSUSE Board ● No voting rights in Board decisions, liaison with SUSE on financial matters ● Oversees Travel Support Programme & similar initiatives
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 – Of Topic chat – #opensuse-* @ irc.freenode.net – Many more channels available
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 of other interested people in IRC, at openSUSE Conferences, etc
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
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 diferently
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 diferent at this point is not a ‘failure’, but a learning experience
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
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 diferent directions can ofen be resolved by accomplishing both
Building Linux Better ● Open Build Service started in February 2006 ● Used to reproducibly build the openSUSE® & SUSE® distributions ● Can also build packages for other distributions (Fedora/Red Hat, Ubuntu, Debian, Arch, etc) ● Also used by ownCloud, Endless Linux, Linux Foundation, VideoLAN (VLC), Dell, Cray, Intel and more. http://openbuildservice.org
Testing Linux Better ● openQA started in November 2009 ● Able to fully test Linux distributions from install to user applications ● Integral part of the openSUSE® Tumbleweed & Leap process ● Used by SUSE® to test SUSE Linux Enterprise ● Recently adopted by Red Hat to test Fedora http://open.qa
SLE 12 – SUSE’s Lessons Taking code from openSUSE is not scary ● More actively contributing SLE code back to openSUSE helps both ● Result is more stable for openSUSE users ● SLE engineers more actively engaged with ongoing upstream developments ● ‘Investing in the Future’ - Less chance of regressions for SLE 15 Such contribution encourages alignment with SLE, which aids an accelerated pace of SLE development, which furthers aid openSUSE development. Repeat ad infinitum.
With our powers combined... What if openSUSE could build something based on the SLE sources PLUS their openSUSE packages? – As stable as Enterprise Linux – As broadly featured as Community Linux – The perfect Stable Distro for Desktops & Servers?
Rolling Releases to the Rescue ● No Release Schedule ● Frequent Updates to all Packages ● Updates delivered “when they're ready” ● e.g. Arch, Gentoo, openSUSE Tumbleweed
Too Much Change - Hard to Live With? ● Always changing, always needing to adjust workflows ● The Arch Way - “Do it yourself, it’s a learning exercise” ● The Gentoo Way - “Do it yourself, and you can read the Arch wiki while everything is compiling” ● Something went wrong or changed in a way you don’t like? Too bad, good luck undoing it, you can always start again
Passive Testing is not good enough! ● Many distributions, incl. rolling releases, rely on “Passive Testing” ● Put new packages in a “Testing Branch”, wait X days then assume “it’s good enough” and ship! ● Works better or worse depending on size of developer & testing communities ● Still basically Russian Roulette
The New openSUSE Distributions ● openSUSE Tumbleweed – Rolling Release – Continuously Updated & Tested – Perfect for Developers & Power Users ● openSUSE Leap – Regular Release – Shared Core with SUSE Linux Enterprise – Perfect for SysAdmins, Enterprise Developers, and Users Tumbleweed
openSUSE is... ● One of the most open open source communities out there ● Community led & driven; while still backed by a strong corporate partner that does not, and cannot, exert excessive control ● Leading Innovators in the areas of sofware integration, testing & delivery/distribution ● Believers in the motto “Have a lot of fun!”
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/
sysrich
okaharuna
pulse1923
jxmtst
tomokusaba
psj59129
minma_curama
ivargrimstad
amixedcolor
heyitsmohit
antonicg
taikikawamura
hazumirr
sstephenson
ddemaree
rmw
kastner
zakiyama
marcelosomers
kneath
addyosmani
dougneiner
morganepeng
tammielis
jakevdp