Blogs

RedMonk

Skip to content

OSDL + FSG = The Linux Foundation: The Q&A

Apparently the good folks from the FSG and the OSDL didn’t get the memo that I’d be traveling when they announced their merger, so I’m a bit late with my coverage. Fortunately for me, far more timely (not to mention sharper) folks like Andy have broken down the news for you. I’ve got a couple of concerns I haven’t seen discussed elsewhere, however, so I’ll still do my usual Q&A.

Q: As always, let’s get the disclaimers out of the way up front.
A: Aren’t too many. Neither the FSG nor the OSDL were RedMonk clients, although I’ve met and been briefed by the likes of Ian Murdock (FSG), Jim Zemlin (FSG), Stuart Cohen (ex-OSDL). I think that’s about it.

Q: How about some quick background – what was the OSDL and why was it important?
A: Well its primary importance, to my mind, was the employment of Linus’ Torvalds, Andrew Morton, and company. But in general, it worked to further the goals of the Linux operating system via sponsorships, working groups, and so on. It was funded primarily by corporations and educational institutions with significant commercial and non-commercial interests in Linux.

Q: And the Free Standards Group?
A: An organization created with the express purposes of driving open standards. The group was behind a number of different standards efforts – including one of the ones I’m most interested in, packaging – but is probably best known for its work advocating the Linux Standards Base. It was likewise sponsored generally speaking by corporations and non-profit institutions with interets around Linux.

Q: So these two Linux centered organizations have come together to form the Linux Foundation. Why take that step?
A: Well, the press release talks about the need to further the goals of Linux and so on, but I see this as simple operational consolidation. Generally speaking, I’m in agreement with Matt Asay, who commented on the move as follows:

There has been precisely zero value in having the two organizations functioning separately. OSDL was little more than the big vendors’ attempt to remain front-and-center with Linux, and FSG was always more relevant to developers, though a bit hampered by its lack of connection to the big vendors.

It’s also worth noting that the OSDL had begun to rethink its role and purpose already, as Stephen Shankland explains. In short, the merger made sense on several levels: shared vision, pooled resources, and – although I hate to use the word – synergies.

If I had to guess, and I have no inside knowledge here, some of the larger sponsors of both organizations might have “suggested” this path.

Q: Given the somewhat different purposes of the organizations, what does the combined entity view its purpose as?
A: Looks like three main areas. First, the continued employment of key personnel – Torvalds et al. Second, ongoing efforts to standardize Linux, making it easier for ISVs and developers alike to build on top of the platform. Last, serving as a neutral meeting ground for competitive organizations and developers to collaborate together on common challenges, obstacles and so on.

Q: What do you think of the decision?
A: I’m a bit torn. On the one hand, I think it’s the logical decision and will be nothing but beneficial for the Linux operating system. That benefits me personally, of course, but putting my analyst hat on it’s a good thing for all customers of Linux.

Q: How do you see it being beneficial?
A: Well, consider the example of package management. When exploring the question two summers ago, it was unclear to me where a solution might come from – the FSG’s LSB, or the OSDL, or both. Here’s what I said:

For macro level conversations, however, I’d imagine some combination of the LSB and OSDL would have to be involved. When I spoke with them, the OSDL recommended the LSB. Irrespective of whether Linux addresses this on a cross-distro level, however, the advantage is still one that should be pressed.

As it turns out, the FSG began to tackle the problem a few months back, but now there’s no question which organization the effort should be associated with – there’s only one. So that’s good.

Q: What don’t you like about the decision?
A: Well, I’d hoped that the resulting organization would be more inclusive than it appears that it will be. The explicit Linux branding of the organization is both acceptable and understandable, given the history, sponsor interests and raison d’etre of the new entity. But at least in the standards arena, I think it would be potentially beneficial to extend olive branches to other operating systems with similar issues and interests, notably Solaris but also FreeBSD. The benefits to standardizing a package implementation API across FreeBSD, Linux, and Solaris would be potentially immense, from both the ISV and developer standpoints.

Unfortunately, with the rhetoric I’ve seen from the organization following the announcement, such coopetition is probably not going to happen. In the NY Times article on the merger, Jim – whom I’ve met and respect – was quoted as saying:

“It’s really a two-horse race now, with computing dominated by two operating-system platforms, Linux and Windows,” said James Zemlin, executive director of the Linux Foundation.

Whether you agree or disagree with that contention, and I could build a case either way, it’s clearly unhelpful if you harbor any ambitions of encouraging cross-operating system collaboration and development. Ergo, my conclusion is that the Linux Foundation is not, in fact, harboring any such ambitions and that’s a shame, IMO.

Q: If you were advising the Linux Foundation on immediate priorities, what would it be?
A: I would tell them that increasing the adoption and utility of the LSB is of paramount importance. One of the problems with Jim’s “two-horse race” assertion is the current reality that Linux != Linux from the perspective of the ISVs that support it; one of the horses, in fact, is several horses. Indeed, the ISV decision making process, if anything, has gotten more difficult with the recent Oracle and Microsoft/Novell announcements. As someone who advises ISVs about the distribution landscape on an ongoing basis, I can tell you that it’s not a simple equation for any of them. Each contender has cons for every pro, and each contender is – effectively – it’s own operating system from a support and QA perspective. The best thing that the Linux Foundation could do to further Linux, IMO, would be to make writing to Debian/Ubuntu as simple as writing to Red Hat.

Q: Anything else?
A: Just that I’m hopeful that, over time, the Linux Foundation recognizes that operating systems are not in fact a zero sum game, and cooperating with competitors might have substantial benefits to it. Unless, of course, Linux wants to follow the Windows path.

Update: Stephe and I must have simultaneously posted. Here’s his take, with the benefit of his long personal history in the standards business.

Categories: M&A Announcements.

  • http://blogs.sun.com/comay/ David Comay

    Thoughtful post, as usual, Stephen. I clearly disagree with James Zemlin’s two-horse race characterization and your point about packaging is right-on. Working together on that aspect of software development benefits the end-user who wishes to install, upgrade, patch and eventually remove that software but it also benefits the developers and distributions who are working to publish the software in the first place. And in the case of open-source software which behaves pretty much the same regardless of OS platform type, providing a consistent view of it from a packaging standpoint especially makes sense for producers and consumers alike.

  • Pingback: Once More unto the Breach

  • http://www.redmonk.com/jgovernor James Governor

    great stuff stephen. you add a lot. fine signal to noise.

  • http://thunk.org/tytso Theodore Tso

    The problems with trying to extend the LSB to Solaris and FreeBSD are somewhat different. As far as FreeBSD is concerned, it’s extremely small deployed base means that it is nearly irrelevant as far as the commercial ISV market is concerned; you don’t see many ISV’s making their products available for FreeBSD. Hence, FreeBSD doesn’t have much incentive to chage its filesystem layout, its ABI, its packaging system, etc. in order to be LSB compliant. If it chooses to do so, of course a commercial distributor of FreeBSD could always try to make FreeBSD LSB compliant and then go through the LSB certification process.

    Solaris has another problem; relatively few ISV’s have ported to Solaris on Opteron, but Solaris has many, many more ISV’s shipping products on its highly expensive, Sparc platform. ABI compatibility on the Intel platform with Linux could threaten long-term ISV commitment to the Solaris platform, and at the very least would make it easier for customers to transition from Solaris to Linux, and for more ISV’s to support Linux, which is not in Sun’s long-term interest. Whether it is for these or other reasons, Sun has never been particularly interested in the LSB, and I don’t see any likelihood of that changing. Of course, if Solaris wants create a Linux compatibility layer and then try to get it certified as an LSB-compliant environment, it is welcome to do that.

    At the end of the day, I think what this article is missing is that in order for a standard to be useful, it has to define a platform which applications can target, and ship binaries that will Just Work. Posix never met that goal because (a) it was a source standard, and (b) in order to be as applicable as possible to a wide range of OS’s, it watered itself down by allowing multiple different behaviors so that no Unix flavors would “lose out”. But by being broad, it became much, much less useful to application programs, who still needed to make their applications flexible enough to support the Solaris way of doing Posix, the AIX way of implementing Posix, the Digital Unix way of implementing Posix, etc., etc. So the LSB is standardizing the Linux way of doing things. Period. That makes it much more useful than if it did the politically correct thing by saying, “Well, we like the FreeBSD and Solaris ways of doing things too; they’re OK by us!” It’s politically correct, but not very useful as a run-time ABI standard. So instead, we take a different tack: the FreeBSD and Solaris ways of doing things are just fine, but if they want to run Linux application binary from Oracle or SAP, they need to provide a compatibility layer which is LSB compliant. We’ll tell Sun and FreeBSD what they need to provide in that compatibility layer, but we’re not going to force the application to simultaneously be able to call out to via either the Linux system call interface or the Solaris system call interface. Because, you know, that would be crazy.

  • http://www.webmink.net Simon Phipps

    Ted: Actually your assertion that “relatively few ISV’s have ported to Solaris on Opteron” is wrong. Sun has around 2300 commercial applications supported on Solaris x64 – That’s more even than there are for RHEL. Solaris has come a long way since you last looked!

  • Pingback: tecosystems » Apt-get Install Ian Murdock: The Q&A