Toward a long-term SUSE-based distribution [LWN.net]

September 2, 2009

This article was contributed by Nathan Willis

A group of SUSE Linux users put plans in motion last week to create a free, community-managed server distribution that maintains compatibility with Novell's enterprise offerings, but guarantees the long-term-support not provided by openSUSE. The result, said organizers, would be similar to the relationship between CentOS and Red Hat Enterprise Linux (RHEL), and would ultimately be beneficial to Novell. There are numerous practical difficulties to be overcome in the creation of this distribution, though, and the form that this distribution might take is not yet clear.

The idea of a free SUSE-based Linux distribution suitable for server use has cropped up more than once in the past; what spurred action this time was the August 14th announcement that openSUSE was moving from a 24-month to an 18-month maintenance period. Boyd Lynn Gerber, a consultant who works with the SUSE Linux Enterprise Server (SLES) and Desktop (SLED) products and participates in the openSUSE project, voiced concern over the change, especially for small-to-medium sized businesses (SMBs) without the financial resources to purchase SLES and SLED support contracts (which start at $799 and $120 per year, respectively). For comparison, SLES and SLED receive general updates for five years, and security patches for seven.

Gerber argued that shortening the supported lifespan of openSUSE widened the gap in the product line between openSUSE and SLES/SLED, potentially making it hard for small businesses to smoothly transition into the enterprise line. He proposed starting a group to work on a distribution in between openSUSE and SLES/SLED — one that would be available without purchasing a support contract from Novell, but would offer a longer, multi-year lifespan with which businesses would be comfortable, in particular guaranteeing backports for critical patches and security fixes.

Multiple options

Gerber's initial plan suggested three possible courses of action: create a support structure to maintain openSUSE backports for a longer period of time (a.k.a. the "OpenSUSE LTS" option), create a new distribution built from the source code releases of SLES but with Novell's trademarks removed (the "OpenSLES" option), or create a new distribution using the latter model, but for SLED instead of SLES (the "OpenSLED" option). The subsequent discussion on the opensuse-project mailing list debated the merits of each alternative, but the level of response also led Gerber to start a separate mailing list on which to further pursue the idea.

The OpenSLED option was quickly dismissed, because the product would be too similar to openSUSE itself, and because SLED does not include any server-oriented packages, so it would do little to meet additional needs for SMBs. Between the OpenSUSE LTS and OpenSLES options, opinion on the new list was evenly split. The pros of OpenSUSE LTS include the relative legal simplicity — creating a derivative of openSUSE does not require permission or even cooperation from Novell — but the cons include significantly higher investment of volunteer time. openSUSE contains more packages than either SLES or SLED, so more patches and backports would be required to maintain it over time.

Furthermore, adding LTS to openSUSE would require creating a framework for triaging, testing, and approving updates and backports well after an openSUSE release's end-of-life, whereas mimicking SLES's lifespan for an OpenSLES distribution could rely on Novell's tested patches. The down side of running an OpenSLES distribution, according to list traffic, is the risk of alienating or angering Novell if the company perceives the effort as siphoning away SLES customers. Gerber and others countered that an OpenSLES would, in reality, attract more customers to SLES by providing a lower barrier to entry, particularly for SMBs.

Supporters of the OpenSLES option compare it to CentOS, which they describe as a popular choice among SMBs either with smaller budgets or merely testing the waters before signing up for enterprise support with RHEL. CentOS, the "Community ENTerprise Operating System" is volunteer-driven, and since 2003 has built its releases from Red Hat's publicly available RHEL source code packages, with Red Hat's trademarks and branding excised. RHEL, like SLES and SLED, has a seven-year support life cycle.

Progress

Thus far, said Gerber, Novell has given the idea a chilly public reception, although he claims that in private conversation members of Novell management have been more open and expressed the view that an OpenSLES could be a tool to gain more SLES customers. "We will need to show or demonstrate to Novell and their upper management that this a good thing to support", he said.

Gerber believes that the OpenSLES option is clearly better than the OpenSUSE LTS option, and has started planning, laying down the groundwork for a non-profit entity to oversee the project, creating initial project guidelines based on the examples provided by CentOS and other derivative distributions, and looking for legal representation to assist with licensing and trademark usage concerns. Just a handful of people participated in the discussion on opensuse-project, but a dozen or so have already joined the new mailing list, and Gerber said the discussion is ongoing in the #opensuse-server IRC channel on Freenode.

Novell did not respond to requests for comment about the project, although SLES manager Gerald Pfeifer did ask several questions about the proposal on the opensuse-project list, particularly about the suggestion that Novell was not properly serving the SMB market.

Although SUSE Linux does not have an ecosystem of derivative distributions like those surrounding Red Hat's products or Debian, there does not appear to be anything preventing such spin-offs from starting up. openSUSE has detailed trademark guidelines [PDF] explicitly covering redistribution and modification projects. SLES and SLED are not covered by that set of guidelines, but Novell has a trademark usage request system through which interested parties can ask for trademark usage approval on a case-by-case basis. As for the software itself, openSUSE is of course a fully open project, and Novell provides source code packages for SLES and SLED on its web site.

Clearly SUSE users and resellers are interested in the possibility of a free alternative to Novell's current enterprise offerings. There are no hard numbers to back up the position that CentOS has directly increased Red Hat's sales of RHEL, but the company certainly tolerates its existence, and CentOS as well several other highly-focused RHEL derivatives like Scientific Linux have continued to thrive. Proposals to build a long-term-support option for existing distributions are no guarantee of success; several efforts to add that support to Fedora have come and gone in recent years. If it is successful, creating an OpenSLES may be the first step not only towards filling the long-term-support gap, but to expanding the SUSE-based distribution family.

Index entries for this article
GuestArticles	Willis, Nathan

to post comments

Toward a long-term SUSE-based distribution

Posted Sep 2, 2009 20:23 UTC (Wed) by Baylink (guest, #755) [Link] (8 responses)

Rock, meet hard place. Hard place; this is rock.

Of *course* an open alternative to something that Novell charges money for is going to cause some people to utilize it instead of paying Novell money; that's precisely the point here.

So it's pretty disingenuous for anyone to say otherwise, whether Novell's paying them, or not.

The question is: from up here at 50,000 ft, "should" those people be paying?

A common business pattern is that a company provides a service, and charges for it, and the potential audience breaks down three ways:

1) People who need none of the aspects of the service
2) People who need only some of the aspects of the service
3) People who need all of the aspects of the service.

What a process like the one being discussed here does, is to convert people in the second category for reluctant higher-paying customers into people who patronize the competing cheaper/free service, which provides all the aspects they actually *need*, but doesn't charge them for aspects they do not need -- in the case of SuSE it's probably paid support by email and phone calls; in some analogous cases, it might be a bigger seat and free drinks on the airplane, or the ability to rebook your ticket for a different flight, or a pool at the hotel... all of these are examples of where a semi-competitor came in with fewer frills at a lower price point, and stole some business from an established player.

In this case, the situation is *slightly* different, since CentOS is using the code that Red Hat assembled into a distribution, and the SuSE project would work similarly... but that's the price those companies pay: they would not have a product line at all but for the contributions of others under the GPL, and they are, therefore, not permitted to bitch about this, without looking childish. IMHO.

Toward a long-term SUSE-based distribution

Posted Sep 2, 2009 20:24 UTC (Wed) by Baylink (guest, #755) [Link] (2 responses)

And the part I missed: if you don't want *other companies* to cannibalize your customer base, then you have to be prepared to do it yourself...

Toward a long-term SUSE-based distribution

Posted Sep 2, 2009 23:21 UTC (Wed) by ewan (guest, #5533) [Link] (1 responses)

It's worth noting that Redhat's support of the rebuild distributions is entirely voluntary. If you buy a supported copy of RHEL they'll give you both the binaries and the source in one go, discharging their obligations under the GPL. Plus there's the large fraction of the distro that's not licensed under the GPL, and all the stuff Redhat owns the copyright on, none of which they need release source for at all, much less in nicely packaged, easily rebuilt src.rpms freely available to everyone online.

Redhat don't support the rebuilds because they have to, they do it because they want to. We can speculate on why that is, but my guess is that the reasons would include:

- No vendor lock in. It's a point made generally in favour of Free software, but it's particularly convincing for RHEL; if you don't like the support, stop using it, and run a clone. Other than the support nothing changes.

- Community relations. Acting like openness is something that you believe in, not something that has to be dragged from you is only good PR in a community like this, and it's this community that creates quite a lot of Redhat's product for them.

- Forming habits. If I need an 'enterprise' type distribution but I've got no money, or if I just want something to learn on, or I'm not sure it's the right way to go, I'm not going to stump up for either SLES or RHEL. I might try CentOS though, and if I do, then when I do need the paid support I'm going to go to Redhat because they support the system I'm already used to, unless there's a massively compelling reason to deal with the migration somewhere else.

I can't imagine why those reasons wouldn't apply equally to Novel, but maybe they can.

Red Hat and derivative distributions

Posted Sep 3, 2009 19:32 UTC (Thu) by brugolsky (guest, #28) [Link]

I'd add that Red Hat has separated out the files that carry their trademarked items (artwork, etc.) into separate packages that are readily replaced. They could easily have made the process much more difficult by spreading their trademarked bits throughout the source rpms.

Toward a long-term SUSE-based distribution

Posted Sep 4, 2009 22:18 UTC (Fri) by giraffedata (guest, #1954) [Link] (4 responses)

A good analysis.

The basic economic ignorance in the discussion and to some extent the article covering it is the common claim that big companies can afford higher prices than small companies.

In a free market, no company, no matter how large, can afford to pay $10 for $5 worth of stuff. So SLES is already being sold at its minimum price. To make the case that small businesses need a new SUSE product, you have to show that they need less product than the big guys, not that they need a lower price.

Toward a long-term SUSE-based distribution

Posted Sep 5, 2009 0:34 UTC (Sat) by dlang (guest, #313) [Link] (3 responses)

quote:

In a free market, no company, no matter how large, can afford to pay $10 for $5 worth of stuff.

the problem is how do you determine if the stuff is worth $5, $10, or $15?

there is a LOT of equipment out there that I consider horribly overpriced that sells well and lets the companies that sell it make a LOT of money. so obviously to someone else it's not considered overpriced.

Toward a long-term SUSE-based distribution

Posted Sep 5, 2009 2:00 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

the problem is how do you determine if the stuff is worth $5, $10, or $15?

That's a problem, but I'm talking about the claim that we need a less expensive SUSE because small companies, as opposed to large ones, can't afford SLES. The problem of valuing SUSE would apply equally to large and small companies.

Another way of looking at it is that if there really is a way to give 5 years of support for less than $800 a year, big companies will be as interested as small ones.

I feel the same way about some enormously expensive computer equipment, not to mention services, but I'm humble enough to admit that I might not understand all the complexities. Companies that spend $50,000 on a router do have skilled people put a lot of time into evaluating it. And if they really can't get more than $5,000 of value out of it, their smarter competitors would drive them out of business.

Toward a long-term SUSE-based distribution

Posted Sep 5, 2009 2:39 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

so by your logic, CentOS should not exist as RHEL is already selling for exactly what it's worth.

there is however a difference here

some people want packages that are maintained for a significant time period

some people want a version that a third party will support their software on

other people want a tech support number they can call if they have problems

CentOS or OpenSLES cater to the people who want one or both of the first two, but are willing to do without the last

Toward a long-term SUSE-based distribution

Posted Sep 5, 2009 3:15 UTC (Sat) by giraffedata (guest, #1954) [Link]

CentOS or OpenSLES cater to the people who want one or both of the first two, but are willing to do without the last

Ah, so that's my point. The customers of these vs the customers for the full price versions don't differ in that one can afford to pay more than the other, but that one can use more service than the other. Assuming we're talking about businesses, "willing to do without" means "has less expensive alternatives."

Toward a long-term SUSE-based distribution

Posted Sep 3, 2009 20:29 UTC (Thu) by GeraldP (guest, #39016) [Link]

Nice article and interesting discussion. Two minor notes, if I may:

I am not a "SLES manager", but the Director of Product Management over here (though indeed I used to be SLES project manager in a previous life). My team and me are responsible for SUSE Linux Enterprise, Appliances, and last but not least openSUSE. Which makes this a heck of an interesting job. ;-)

The lifecycle document for SUSE Linux Enterprise actually is at http://support.novell.com/lifecycle/linux.html and is a bit different. I'll see whether we can make this easier to locate on the website.

Toward a long-term SUSE-based distribution, show me the patches/updates

Posted Sep 10, 2009 9:35 UTC (Thu) by kragil (guest, #34373) [Link] (1 responses)

This is great and all, but the link to the sources only provides the sources for the released DVDs. I couldn't find update/patch/security fix sources.

Isn't this whole OpenSLES idea doomed if Novell does not provide those in a timely manner?

Toward a long-term SUSE-based distribution, show me the patches/updates

Posted Sep 14, 2009 11:07 UTC (Mon) by dag- (guest, #30207) [Link]

I think Novell has the obligation to provide the source packages to their customers, so the only thing you need is one customer.

The same goes for CentOS, if Red Hat for whatever reason stops being generous, only a set of entitlements for RHEL is needed to continue CentOS.