On 7/7/24 15:47, Shawn W Dunn wrote:
Pursuant to Richard and Robert's talk at oSC 2024:
https://media.ccc.de/v/4411-we-re-all-grown-up-opensuse-is-not-suse
This is a topic that needs to be discussed as a community, especially as it's currently a request from SUSE.
I do want to be clear, this message is me posting as "Community Member SFalken" not "openSUSE Board Member SFalken"
Myself, I'm in favour of "rebranding" the community project, and making it clear that openSUSE != SUSE. Far too much of the time in our support channels is spent clearing up these misconceptions, where new users (and even some experienced users), are saying things like "SUSE Should do $x" or "Why doesn't SUSE do $x?".
I'm less certain that I agree with Richards proposal of the individual projects sort of "go their own way", at least as he's laid it out, but again, this is absolutely a topic that deserves consideration.
Thoughts?
Hi folks - TL;DR at the end. This is me posting as a community member, not as a SUSE employee. I'm not involved with the SUSE-internal rebranding discussions and don't represent that decision here. I don't usually speak up on the project list, but I've been an openSUSE member since the beginning and have been a SUSE Linux/openSUSE user since the 90s. If you were in the room for the rebranding discussion, the following should sound familiar. It's more or less what I said during the discussion but perhaps a bit more refined. Others have said that governance, rebranding, and the foundation should be handled individually and with differing priorities. I disagree. I think all three are intertwined and, if handled properly, present a unique opportunity for the project to re-establish itself. openSUSE has maintained a relatively small community compared to other popular but similar projects (e.g. Fedora, Ubuntu, Arch) since its inception. I think there are a few big reasons for that. 1. The perception that SUSE owns openSUSE and contributing to openSUSE is like working for SUSE for free Part of this is naming. Part of this is SUSE requiring the board chair to be a SUSE employee. Part of this _could_ be that openSUSE releases and SUSE products are inter-related, with Tumbleweed being periodically stabilized into enterprise releases and those enterprise releases being contributed back to the community to form the basis for Leap. The latter relationship is one that mirrored the relationship between Fedora / Red Hat / CentOS until recently. Part of this is that SUSE still owns and mandates control over the infrastructure, though that is changing. The main ongoing reason for this is for security: the openSUSE and SUSE IDP authentication systems use the same backend. That means that anyone with administrative access to those systems could obtain access to corporate credentials. As a result, those systems must be managed by SUSE employees. There's a project to decouple the authentication systems underway and, IMO, once that's complete, there should be no reason why SUSE should exclude community members from any openSUSE systems. Part of this is that, legally, openSUSE isn't a separate organization. The Geekos foundation was set up relatively recently but it's not formally attached to the project in any way other than Patrick's motivation and commitment. Those are both substantial but also not binding. This list is probably incomplete, but you get the idea. 2. The lax governance leads to inconsistent expectations This isn't to point fingers at individual board members, past or present, or as a comment on their performance. It's more about the structure. Similar projects have more structured and open governance with clear definitions and separation of roles. For example, the Ubuntu governance structure[1] ultimately puts Mark Shuttleworth at the top as a exceptionally rare veto vote and everything else is delegated to the Community Council[1] and Technical Board[2], which have very different goals and responsibilities. Those groups can, in turn, delegate[3] to other bodies. The current openSUSE board structure is a one-stop shop and I feel it's pulled in too many directions simultaneously. If we go the route of the Ubuntu-style governance, I would suggest removing the requirement for a SUSE employee to be the chair of either board and instead put that requirement in the place of the Shuttleworth role above: a very-rarely used veto or direction setting role, largely removed from the day-to-day operation of the project. The rules about limiting the number of SUSE employees on the board(s) would still apply otherwise. Moreover, the ad-hoc nature of pretty much every other team means that it's difficult to understand what the roles and responsibilities are for each one. In Robert's (other) talk about non-technical contributors, there was a discussion about how newcomers to e.g. the marketing team aren't always clear on what they can and cannot say or do while representing the project. The options were either to know who the right person to ask was or to default to asking for forgiveness instead of permission. That's not something a lot of people are comfortable with doing when they're new to a project. Delegating marketing to a specific team with well defined contacts, processes, and the authority to determine guidance for its members would be a good start. I'll get to comments about Richard's suggestion to create a simple umbrella org later, but the Ubuntu model of having Team Councils would also grant sub-projects some autonomy while still being held to the Code of Conduct. 3. The project doesn't have a clear mission The openSUSE project is largely driven by the people who do the technical work. It's a volunteer effort, so that's mostly to be expected. When there are conflicts, it's uncertain how they're resolved. Maybe it's the board. Maybe it's whomever speaks last in a drawn out discussion/argument. Maybe it's whomever gets a submit request approved first. In the Ubuntu model, the Technical Council is the tiebreaker, but it's expected to take guidance and input from the teams actually doing the work. Also from Robert's other talk was a comment about how in order to become a member of the project, one must have made contributions. Those contributions are typically considered technical ones. Documentation, marketing, design, community building, etc are vital to a successful open source project and those aren't recognized as much as technical contributions. That said, while there is some focus on user experience, the project mostly seems to be contributors scratching their own itches. And if that's the direction that we want the project to go, it should be a conscious decision. One of the main things that's a barrier to adoption by new users is the perception that the releases are full of small annoyances that other distros take more seriously. The arcane nature of snapper, performance of zypper, (historically) codec inclusion, and the relatively recent secure boot shim issue are some easy examples from a quick scan of reddit posts about this topic. If we want to grow the project, we'll need to take those more seriously as well. As for the renaming, I don't have a strong opinion on it. I was against naming it openSUSE from the beginning, but now it's a 20-year-old brand. It's recognized in some circles but it's not huge. As a SUSE employee, having a clear line between openSUSE Leap and SUSE Linux Enterprise has an advantage. As a community member, it can be a barrier to contribution. If there is a renaming, I don't think it should be the gateway to make all of the projects that make up the ecosystem to be independent of one other under one umbrella. Several people in the audience at oSC mentioned that this is the path to irrelevance, and I agree. A brand tying the projects together is the identity and, more practically, what makes it easy to get relevant results when searching. A search for "openSUSE Leap" or "openSUSE Tumbleweed" yields what I expect to see as the top hit using Google. A search for "Leap" doesn't yield anything related to openSUSE until the fourth page. Tumbleweed does a bit better -- it's the last entry on the second page. Deciding on a new name won't be an easy process. There will be many ideas and fewer good ones. It will need to be easily recognizable and searchable. (I am terrible at naming things, btw.) Rebranding is an expensive operation because it means getting the word out about the new brand, explaining why it came about, and (importantly) getting new swag out to community members. With a new name must come a new logo too. That will need to be designed. There will need to be new t-shirts with the logo and name given out at every opportunity. If the new logo lends itself to being a mascot, new plushies will need to be made. New stickers. People have stacks of stickers and drawers full of t-shirts that will need to be replaced. There will need to be a marketing campaign bigger than any the openSUSE project has ever done in the past. That's a lot of effort and expense. I will say that if the project decides to rebrand at SUSE's request, I will pursue support from within SUSE to make it successful. Lastly, if the project is to be more independent, there needs to be a legal organization backing it that isn't SUSE. It could be the Geekos foundation, but if that is to be the case, there will need to be formal governance and accountability built into it. SUSE funds some operations of openSUSE directly now, but could potentially direct that to the foundation instead. That can't happen without a formal process in place that shows how the money will be spent, what the processes are, and a clear definition of roles and responsibilities. In summary, I don't have a strong opinion on the renaming, but it could be an opportunity to revitalize the project under a new name, new governance, and new independence. That, in turn, could make the project more attractive to new contributors and users who aren't SUSE employees. With projects that used to be wildly popular on the decline, it could be the right opportunity to make a splash. Thanks, -Jeff [1] https://ubuntu.com/community/governance/community-council [2] https://ubuntu.com/community/governance/technical-board [3] https://ubuntu.com/community/governance/delegation -- Jeff Mahoney VP Engineering, Linux Systems