This is pretty big news. SunGard will be providing Sakai support services to its customers. If you’re interested in Sakai, you can contract with SunGard to get help migrating, setting up integration, and training faculty, as well as ongoing hosting and support. They’ll be doing this, in part, through a partnership in which rSmart is basically subcontracted by SunGard to provide the hosting and support subscription services. This is great news for both companies, SunGard’s customers, and the Sakai community in general, the latter of which I expect to expand substantially because of this development. But this also provides a textbook case of just how well open source and open standards can work to provide better offerings in the marketplace when they are working well. People who don’t have experience with them—particularly with open source—often scratch their heads at how they can possibly work out. In fact, open source allows for the unbundling of services that are typically tied together in a private source vendor model, opening up new possibilities for business models and risk management strategies. Open standards enhance that flexibility while creating new opportunities for collaboration among even competing vendors.
Let’s take a closer look at how this deal works for each of the parties involved.
From the customers’ perspective, they can get full-service support for Sakai from one large vendor that is known to be financially stable and will be around for the long haul. One reason that schools balk at open source is the perceived risk of relying on a boutique support vendor. This deal takes that risk off the table. As far as the customer is concerned, SunGard is taking care of everything from soup to nuts. The contract is with them, and they are the ones on the hook for their customers’ success. But this security comes without the usual cost of vendor lock-in. Customers will be provided with the rSmart CLE, which is a cleaned-up but still fully open source distribution of the mainline Sakai code. If customers grow dissatisfied with the support they are getting, they can go to a competing Sakai support vendor or even choose to manage all support internally. This is typically not an option with private source software.
The benefits for SunGard are substantial, too. SunGard provides various services for a variety of LMS’s through partnerships with a variety of LMS support vendors. (They announced a services partnership with Blackboard last spring, for example.) LMS partnerships benefit them in several ways. First of all, because SIS/LMS integration is critical for most campuses these days, SunGard needs to maintain high-quality integrations in order to be competitive. Second, SunGard wants to get into retention early warning analytics, having partnered with Purdue University to productize that school’s ground-breaking Signals project. To do that, they need to get access to data in the LMS. Last but certainly not least, SunGard earns a substantial majority of its revenues from its services business. They want to be able to sell engagements to help schools with LMS migration, instructional design, and just about anything else they can manage.
It’s this last component where open source really makes sense for them. Most private source vendors bundle implementation and ongoing support services with the license of their product. This takes away revenue opportunities for a company like SunGard. In contrast, an open source platform like Sakai means that SunGard can pick up the initial implementation services, where they think they have the expertise to really shine, and subcontract the ongoing support services to a Sakai specialist. The customer will still call SunGard and still be able to hold SunGard contractually responsible, but behind the scenes SunGard will be able to rely on rSmart personnel to handle support calls that need escalation to an expert and to manage the hosting. And the development of the platform continues to be collaboratively managed by the Sakai community and then lightly massaged by rSmart with the release of their distribution. Neither company has to take on the burden of developing an entire LMS, but both companies can contribute to the development efforts where they benefit from doing so. (rSmart, for example, prefers to submit patches back to the Sakai community rather than maintaining differences in the rSmart CLE whenever the community will accept those patches.) We often talk about a best-of-breed strategy for the bits and bites of software, but open source allows the creation of a best-of-breed support strategy. That’s what the SunGard/rSmart approach aspires to be.
This is obviously a great deal for rSmart, too. First of all, they get to draft behind SunGard’s massively larger sales and marketing teams. One of the downsides of the unbundled business models that open source facilitates is that there is frequently a vacuum in sales and marketing. Open source communities themselves are usually pretty bad at marketing.1 Unless open source communities manage to attract a healthy number of support vendors, then sales and marketing will suffer. This can really matter. One of the reasons that Moodle has been so successful is that they did a good job early on of attracting and incenting a wide range of support partners who have done a great job of getting the good word out about the platform. rSmart certainly does its share of marketing for a company its size, but there’s just no comparison to what SunGard can do. A source close to this deal estimates that SunGard could increase the total sales and marketing resources of the entire Sakai community twenty-fold. That’s great for rSmart and great for the Sakai community in general. Furthermore, in addition to driving sales of their hosting and support, rSmart will get some revenues from training SunGard’s support, sales, and marketing staff on Sakai. And they get all of this without having to stretch their business model to take on pieces that SunGard can do better. They don’t have to scale up their sales and marketing teams, and they don’t have to become experts on SunGard integrations. (More on integration in a second.) The unbundling of business models enables a boutique company like rSmart to focus on what it does best. In return for this, SunGard presumably gets a cut of the deals that they land for rSmart. Both companies win.
But there’s more. The two companies obviously benefit from being able to provide their customers with strong integration between Sakai and Banner. They also benefit from having that integration be standards-based. After all, rSmart still wants to be able to sell to Oracle and Datatel customers, and SunGard still wants to be able to sell to Blackboard, Desire2Learn, and Moodle customers. Both companies benefit from being able to build one standards-based integration rather than specialized integration for each platform they integrate with. This means using the new IMS LIS standard, which went into public draft earlier this year and should go into final draft before the end of the year. Interestingly, Oracle (SunGard’s biggest competitor in the SIS software business) and Unicon (one of rSmart’s main competitors in Sakai support services) collaborated on delivery of LIS support to Sakai some time ago. The code, which Unicon contributed back to the Sakai community, provides the technical infrastructure that SunGard and rSmart intend to use for their current collaboration. But that code was developed while the LIS specification was still evolving, and it needs to be brought up-to-date with the final draft of the specification. rSmart and SunGard will be doing that work and contributing it back to the community, where competitors Oracle and Unicon—along with all Sakai schools and related vendors—can benefit from their work. The combination of open standards and open source made it possible for these vendors to collaborate where it would have been much more difficult for them to justify in a more traditional private source model. Not only that, it lowered the cost of that collaboration because the competing companies didn’t have to work directly with each other on the code.2
Money doesn’t make the world go ’round, but incentive structures do. This is a great example of how open source and open standards can create incentive structures that turn a zero-sum game into a win-win scenario. I look forward to seeing how this partnership develops.
Great analysis. This is the kind of business case where the open standards/open source combination can really shine, and start to win over companies and universities that haven’t considered their benefits. Making the abstract case for open standards can be a challenge, so showing the practical upshot is critical.
For reference, the SunGard/rSmart deal was also announced recently in the Chronicle of Higher Ed’s Wired Campus blog: http://chronicle.com/blogPost/Course-Management-Software/27265/
What incredible news. One of those things you could sit around talking about wishing it would happen but it never does. But this time it did.
Hi Michael,
As always, thank you for your insight into what is certainly a very interesting development. I am eager to see how well this multi-vendor collaboration succeeds in practice. It is fascinating to consider the partner/competitor relationships and business models in play. I believe such “co-opetition” to be indicative of the increasingly complex nature of the software industry around us.
I am, however, concerned that your post unfairly characterizes proprietary software as inherently too intrinsically linked to the business model. Sure, many vendors bundle certain aspects of their customer relationships by default, but I think you’ll find many relationships very similar to SunGard’s new relationship with rSmart flourishing in the proprietary software world and becoming increasingly common. As a former employee of IBM, I believe IBM’s partner program to provide a great example of how vendors and partners cooperate in relationships of varying flexibility with proprietary software – particularly around implementation, consulting, support, co-marketing, and outsourcing/sub-contracting. Microsoft’s partner network and even Oracle’s own partner network also offer flexibility in some of these areas. Since your post references SunGard, in their recent partnership with Blackboard, SunGard is also empowered to independently deliver (ie: in an unbundled manner) Blackboard integrations in a way that holds both organizations mutually accountable for the success of the integration and commitment to LIS.
I do see value in this type of multi-party relationship and how using open source code can “grease the gears” for such a development to emerge, but I don’t see this as inherently impossible – or necessarily more expensive to accomplish – when using proprietary software. There is also cost to collaboration even when the benefit is clear. On a related note, I’ve also seen multi-party business relationships start out with good intentions only to never fully materialize due to shifting business priorities. If, Flying Spaghetti Monster forbid, rSmart decides to exit the Sakai business, yes SunGard is still on-the-hook, but I guarantee that migration won’t be painless. Similarly, if SunGard decides to no longer support Sakai, rSmart is still there to help, but there would still be support workflows and legal contracts to work out. If a client is unhappy with the service provided by either party, migrations – even if possible – are never easy.
So – Is this development a good thing? Yes. Would it be impossible with proprietary software? Not necessarily. Does open source make it easier? I’d argue yes but believe the greater value is in collaboration around open standards than in “unbundled” business models.
-George
Some good points from George.
However, he characterizes SunGard clients having to “migrate” should SunGard or rSmart leave the Sakai business. This is exactly what these clients will NOT have to do: migrate.
By choosing Sakai—supported in this case by SunGard and rSmart—clients would never need to migrate to another learning platform just because of changing relationships with SunGard or rSmart. What these clients have the freedom to do—for any reason—is choose another Sakai vendor or take it on supporting Sakai themselves. Far from a risk, this vendor independence is a huge benefit to clients choosing the open/community source model that proprietary models can’t match.
George, while I appreciate your kind words and your thoughtful comment (as always), I’m afraid that I think you’re mostly wrong on this one. First of all, as Nate points out, there’s no reason to believe there would have to be a painful migration or even large-scale disruption to customers should SunGard or rSmart get out of the Sakai business. To the contrary, there are several competent, viable commercial entities that would be quite capable of supporting schools on their existing Sakai installations. Hosted customers might have to migrate to a new data center (or might not, depending on the details of the situation), but that could be largely transparent to the end users. The actual code that the schools use would not have to change. That would never happen with a private source product. Even in the extremely unlikely event that the vendor put its source code in escrow, nobody else would have seen that source code, never mind trained a staff in how to maintain that code. So the likelihood that some other company could swoop in and provide support for the private source software of a defunct vendor or an abandoned product is vanishingly small.
Private source vendors don’t share source code. By definition. In addition to changing that out-of-business risk, it makes certain kinds of third-party support impossible. Yes, there are great partnerships between private source vendors and third-party services firms out there, but there are certain kinds of support that simply cannot be provided without access to the source code. Think bug fixes and security patches. If the vendor who owns the code doesn’t provide them, there’s nothing the third party can do to support the customer. Not only that, the economic model makes certain kinds of partnerships unlikely in a private source model even when they are theoretically possible. If you’re a private source vendor, then you assume 100% of the cost and risk of code development. That only works if you can also maximize revenue streams. A lot of private source vendors essentially just break even on the license costs and make all their profits on maintenance contracts. They just can’t give that away. In contrast, in an open source world where development costs are distributed, revenue streams can also be distributed. This allows for new possibilities, like the partnership between rSmart and SunGard.
Obviously, private source has worked extremely well for many organizations using many different kinds of software. I would never say that private source is inherently bad. Nor is private source inherently inferior to open source. But it is inherently different, and those differences matter. You are eliding those differences here in a way that the facts don’t support.