As I have mentioned here before, the Sakai and Jasig foundations are in the process of evaluating a merger to create a kind of Apache Foundation for higher education. The new organization would be called the Apereo Foundation. The two communities will be voting on the merger some time in the next month or so. Documentation and discussion can be found here.
I'd like to tell you why I think this merger is vitally important for higher education in general and Sakai in particular.
The Economics of Community Source
"Community source" is the label for a particular brand of open source practiced by the Mellon Foundation-funded family of projects, most prominently Sakai, Jasig, and Kuali. Its meaning has always been somewhat fuzzy and has gotten more so over time as the communities associated with those projects have grown and higher education's attitudes toward open source have evolved. But fuzziness aside, I do think there is a certain attitude that infuses all of these projects and has profound implications for their sustainability models. Community source, as a movement, has stressed choice and independence for schools rather than a desire to conquer a product category. In the Sakai community, for example, there never was a strong sense that Sakai should "win" in the market by "beating" other LMSs because it's the "best." Rather, the community has tended to see itself as a group of fellow travelers who are looking to build something together and minimize their collective risk. As long as the project had enough participants to be sustainable, they never worried too much about growing market share.
The sustainability models of these communities reflect those values. Ongoing development is funded primarily through direct contribution of labor or funds from participating schools. There are dues paid, but that money goes primarily toward maintaining the community rather than the software. And you don't have to pay dues to use the software. They are strictly voluntary support for the community. There are commercial affiliates who do contribute to the code, but there is no structure binding their success and growth to the growth of resources for developing the software, the way there is in Moodle.
This model works well when the cost of the commercial entrants in the product category are high and resource pooling makes economic sense. In the early days of both Sakai and Jasig's uPortal project, the commercial entrants in the LMS and portal categories had pricing power, and there was a sense that they were holding colleges and universities hostage. It seemed worthwhile to the early investors to put more money in up front so that they could gain control of their destiny, and they could be assured that others would follow on at lower investment levels because their contributions, while significant, would be less than the license cost of the commercial alternatives. Kuali enjoys this advantage today; the cost of commercial ERP software, both in licensing and in implementation, is so high that they have a compelling economic case to make even to those schools that don't particularly care about open source.
But pricing power for both portals and LMSs has dropped in recent years as other viable open source and commodity private source candidates have come onto the market. Also, as Sakai CLE and uPortal have matured, the schools that have adopted them are more or less satisfied (or, at least, satisficed), making it harder to get them to invest in ongoing development. A commercial licensing or hosting fee is something that's easy to keep in a budget on an ongoing basis; a developer, less so. These two factors have combined to make both Sakai and Jasig sustainability brittle. While neither Sakai CLE nor Sakai OAE is in any immediate danger, the threat of erosion of support below a critical threshold is always there. These projects are not in the red zone, but neither are they in the green.
The way these respective communities tend to deal with the problem is to send their Executive Directors out to be salespeople and drum up more financial commitments. In fact, the most common concern that I hear voiced about the prospective merger is that the EDs will be "distracted" from raising vital funds. But pushing the ED to focus on squeezing out a few more commitments every quarter is a tactical approach to a strategic problem. Unless the fundamental dynamics change, the EDs will always be paddling upstream. We will never get into the green that way. All we will do is raise the risk of burning out good Executive Directors.
Affinity Marketing, the Sales Funnel, and Growing the Pie
I'd like to go back to a point I made in passing earlier in this post: Dues paid to the foundations are voluntary support for the community. I have been a Sakai Foundation Board member for several years now, and a community member for more. I have heard many, many versions of the same discussion: How can we increase the number of dues-paying members by emphasizing the value of the community? The answer is simple: Increase the value of the community. The Apereo Foundation, by creating a brand separate from the individual projects but supported by those project brands (in somewhat the same way that the Apache Foundation's brand is boosted by housing projects like Maven, Hadoop, and ActiveMQ), could become the place that first comes to mind when college and university folk think about collaborating around open source software or related practices. It could attract more participants. And it is my sense that the barrier to participate in an open source project is the highest when it's your first. Once you've had a successful experience with one, you're more likely to try another---especially if some of the same folks are involved. There is great value in building a strong community of practice around open source in higher education. That value far transcends the value of any particular project. As such, it can create a halo effect for projects that are associated with the community.
The objection I typically hear at this point is that Apache has a common audience of techies who are interested in the bottom portion of the IT stack, where Sakai and Jasig do not have that common thread with each other. In my view, that concern misses the point. The real value is in creating common and neutral ground for higher education to collaborate on open projects rather than to serve some particular set of IT functions. Take the case of Blackboard, for example. When they announced their intention of becoming more involved in the Sakai community by hiring Chuck Severence, it stirred up a lot of concern. It feels weird for Blackboard to be involved in Sakai because they are long-time competitors in the LMS category. But it would be far less weird for Blackboard (or Desire2Learn, or Instructure) to participate in an Apereo Foundation, where they could, for example, contribute to developing LTI-based teaching tools that could integrate with both LMSs. More importantly, it would be less weird for Blackboard customers to participate in Apereo on such projects. Likewise, it would be easier for the IMS to build open source reference implementations of new specifications that are housed in the Apereo Foundation than in the Sakai Foundation. Some of these new projects will have infrastructure requirements. You don't need to develop your own single sign-on software to tie a couple of ed tech applications together with SSO, but it sure is convenient to have SSO experts in your network. Apereo could be a premier place for schools to work together on solving their end-to-end academic technology problems. As such, the community could grow, both in numbers and in value. Some of the new participants would join the Sakai or Jasig projects as they got closer to them, thus boosting their sustainability without requiring us to turn the Executive Director into a traveling salesman. But even more importantly, the community itself would become valuable to a wider range of schools regardless of which projects they do or do not join. A rising tide lifts all boats.
I do not dismiss the questions I hear about the merger. There are many important tactical details to work out. And precisely since these projects are brittle (again, not under immediate threat, but not as safely sustainable as anyone would like them to be), anxieties are high. These concerns need to be addressed, and I am confident that they will be. But let me be clear: I strongly believe that this path is the most viable path to long-term sustainability for all of the projects involved. If you are a believer in the benefits of Open, then the best way to support it and prove out its value is to be open. The health and robustness of the software is a second-order effect of the health and robustness of the community.