The key is community: Why Blackboard’s changing strategy won’t change the landscape… much
There’s been quite a bit of discussion, analysis, and reaction to last week’s announcements that Blackboard had acquired Moodlerooms and Netspot, hired Dr. Chuck, and cancelled the Angel LMS’ end of life.
There are lots of questions. And much speculation about the answers. But I think we’re just going to have to watch closely to see how this all plays out. What seems clear at this point is that:
- Blackboard has bought back some of the market share they’ve lost over the past few years
- Angel users have a reprieve at the moment from the forced march to choose another LMS
- Blackboard, through Moodlerooms and Netspot, has a new ability to engage with the Moodle community
- Blackboard is more seriously evaluating how to monetize open source… if you can’t beat ‘em, join ‘em
Phil Hill has done a nice job organizing the key announcements, statements, and reactions in his April 4th post. Who knows, maybe Phil will add this one. 
From my perspective, these new announcements are mostly consistent with what we’ve seen for years. Blackboard’s core business continues to be the LMS. It is the basis for the relationship they have with their customers. And while they are quickly diversifying through acquisitions beyond the LMS, they can’t afford for their LMS base to erode as quickly as it has been eroding. Acquiring a bunch of Moodle customers buys them time. Letting Angel customers continue on Angel for now buys them time.
It’s no surprise that the open source aspects of the announcements have generated the lion’s share of reaction. But Blackboar
d’s strategy is not really about open source. It’s about customer acquisition and retention. And there just aren’t that many proprietary options with significant market share to acquire anymore. So Blackboard looks to acquire customers that have chosen Moodle or Sakai–the open source options.
Naturally many have expressed concerns about what this means for open source. Fortunately neither Sakai nor Moodle can be acquired. They will be perpetually available to anyone who wants to use, modify, or share them. The licenses guarantee it. And “the key”, as Brad Wheeler, CIO at Indiana University and Chair of the Kuali Foundation board of directors, notes is
“… to ensure that this doesn’t become a different path back into the old set of problems yet again.”
The key is community
Those of us who’ve been deeply engaged in the open / community movement know that the open license is important, but insufficient, to generate the most compelling benefits. I’ve spent nearly a decade working to establish and build open source options for education that span support for teaching, learning, research, libraries, student services, and administration. Most of my work has been through the Sakai and Kuali communities, who I believe are empowering institutions to improve education–and that’s something that I’m passionate about. Community is the key. Moodle and Sakai are first and foremost communities that have developed deep competencies that enable innovation through diverse global collaboration. One result of these communities’ effort is innovative software that helps students and educators extend and re-invent education. Community is everything. Moodle and Sakai have very different community models, but for both community is everything. Did I mention how important community is? Community brings diversity–a key ingredient for innovation. Community is resilient to change–there is no single point of failure in community. Community is the safety net that minimizes the risk of lock-in. Community promotes transparency and predictability. And so on…
And so the good news for higher education is that we have built two very durable open source communities. And it’s not up to Blackboard whether these communities continue to thrive. Hundreds of colleges, universities, and companies like rSmart, whose values and mission are aligned with the community mission and values, are investing in community developed and governed software. It is this diversity and breadth of contribution that gives me great confidence that Sakai will continue to thrive. Sakai is a path that we can count on to empower students and educators with innovative support or teaching, learning, and research.
Will Blackboard be a contributor in the Moodle and/or Sakai ecosystems? Time will tell. But as Brad put it recently…
“Blackboard now has an excellent opportunity to demonstrate its new values in openness in licensing and community,” although “time will tell” how deep its convictions are on that score.
… and aligning values and mission is very different than shifting strategy.
So despite the uncertainty that comes with announcements like these, there are a few things that I’m sure of:
The Sakai software will continue to empower students and educators. Hundreds of institutions and millions of learners and educators around the world use Sakai with great result. The current generation of LMS’s including the Sakai CLE have matured to a high level of parity. And the Sakai open academic environment (OAE) is demonstrating community innovation at its best by creating a new learning platform that isn’t shackled by current market expectations.
The Sakai community will continue to be diverse, durable, and capable. The Sakai community is made up of a highly diverse group of education-focused organizations who share strong alignment of values and mission. And the community has demonstrated for nearly a decade the collaboration competency to produce and evolve great software, and the durability to endure changes that impact individual members of the community.
rSmart will continue to deliver Sakai. rSmart was founded to support the open community development movement in education. Our mission is to deliver the open platform and achieve the greatest potential impact by making our community’s work accessible to the widest possible spectrum of institutions. We’ve been doing this for many years and know how to engage as an integral part of communities like Sakai, and to leverage that community engagement to partner with our customers and help them improve learning outcomes and increase access to education.
A couple years ago I wrote about how path matters… and how choosing the right LMS is more about choosing a path, than choosing a product. I believe that the community source path enables a rich ecosystem of like-minded, education-focused organizations to put the best innovation in the hands of students and educators. Will Blackboard’s change in strategy help them align values and mission to contribute to that ecosystem? Time will tell.
In my role with rSmart I regularly engage in conversations about rSmart’s approach to solving the last mile problem for the Sakai and Kuali communities.
Our approach, like Red Hat, Moodlerooms, and other open source software companies, includes participating actively as a part of these communities, developing a product based on the community software, and engaging with the market to facilitate widespread adoption.
A question that often comes up is why we develop the rSmart Sakai CLE. Why not just use the “pure” community code? The short answer is that we do. But there’s more to it of course.
Last week when I wrote about the last mile concept, I discussed three different types of institutions when it comes to building or adopting software:
Build institutions have a “build” and/or “collaborate” culture, and are truly self-sufficient.
Borrow institutions are similar to Build but may not be fully self-sufficient. They are likely to engage a consulting firm to import expertise, experience, or capacity from time to time.
Buy institutions prefer solutions to be more turnkey and so depend heavily on partnerships with vendors.
Note that institutions may change type over time, or may reflect a different type depending on the particular application in question.
To understand why rSmart uses a distribution as part of our strategy to solve the last mile problem for the Sakai community, it’s important to understand the various ways that institutions adopt Sakai.
Build institutions are the ones that most people think of when they think about open source. These institutions have a culture and the capabilities to engage with an open source community and often play leadership roles in evolving or maintaining the software. When an institution like this adopts Sakai, a team of people take on the multitude of activities necessary. These include assembling the various software pieces; architecting and creating the development, production, and test environments; establishing the processes and expertise for source code management and deployment; configuring and integrating with other campus systems; integrating 3rd party tools; creating and/or assembling documentation and training materials for administrators and users, and more. When it’s all done institutions like University of Michigan have their own product called CTools, and similarly Indiana University has a product called OnCourse. Both of these are Sakai at the core but are derivative products that require a team of people to maintain. It’s institutions like these that employ many of the people who contribute to Sakai’s evolution and sustainability.
Borrow institutions often engage a consulting firm to help perform the activities described above, and likewise end up with a product derived from Sakai code and a team to maintain it. In many cases these institutions will continue to engage a consulting firm from time to time, or on an ongoing basis to augment their own team. These institutions balance cost and control largely by how much they customize locally and how difficult and costly it is to keep the local customizations in sync with the community code.
When rSmart began supporting Sakai in 2004 we were working mostly with Borrow institutions, and worked with the Build institutions as community collaborators. Each time a new school adopted Sakai we would go through all of the steps I described above. As we did we found that there was a lot of repetition in what we were doing each time. We discovered that there were many steps that could be done once in a very repeatable and reliable way and then used over and over each time we helped a new school implement. And, that the consistency made the production experience much more reliable and supportable. We also found that we could create comprehensive documentation and training materials that matched the resulting product and met end-user standards. And we found that we were able to build tools that helped customers make good informed decisions about how Sakai should be configured to match institutional needs and to maintain that configuration profile over time. As Sakai has matured and more schools have begun replacing legacy systems with Sakai, integrations have become more important as well. We’ve found that it takes a concerted effort to maintain integrations with SunGard Higher Education, Eluminate, Wimba, Kaltura, TurnitIn, iRubric, iTunesU, Big Blue Button and the like and so we have partnerships with companies like these to make sure that the integrations all work well and don’t break when one or the other is upgraded. The result of all of this re-use is the rSmart Sakai CLE. And it’s a big part of our strategy to make Sakai accessible to schools who fit the Borrow and Buy cultural types.
The value of the rSmart Sakai CLE is mostly in the economies of scale in our ability to do things once that benefit all of our customers. If we didn’t create the rSmart Sakai CLE we would be repeating a lot of work with each new adoption, and it wouldn’t be cost effective to offer regular updates & service packs, and have a complete set of documentation, training, and configuration tools. The consistency also makes it more effective to provide responsive support and hosting.
rSmart was founded to support community sourced software in education. We believe that Sakai and Kuali should be accessible to every institution. Everywhere. And we believe that the shift of freedom and control back to institutions will have a profound effect on institutions’ ability to leverage technology to meet the ever-increasing challenges of educating the population.
Because of this we take great care to keep the rSmart Sakai CLE closely aligned with the community code base. Two principles in our engineering processes are key to achieving this important objective:
- Ensure that enhancements and fixes rSmart produces on behalf of our customers flow regularly back into the community codebase
- Minimize effort to merge the full code base of a new release or a fix between the two codebases
These principles drive our engineering team to spend 20% of their time working as a part of the Sakai community’s maintenance team. They drive our decisions to contribute work like Google Docs integration, Elluminate integration, and the work we recently did with SunGard Higher Education on the LIS 2.0 specification.
This commitment to close alignment of code is the key to offering our customers the best of both worlds: the polish, reliability and support of commercial open source, and the control and freedom from vendor lock-in that open source provides. It’s this combination that we believe makes Sakai truly accessible to any institution regardless of size, culture, or development capabilities. And we’ve been able to demonstrate the freedom from lock-in as, over time we’ve been able to support transitions to and from our distribution for institutions who’s priorities and circumstances have changed.
The last mile – making open source software accessible
In the communications industry the “last mile” is the final leg connecting a customer to the global information and communications network. The last mile is often the most difficult and costly part of the infrastructure to make robust connectivity accessible to everyone.
Like the global information and communications infrastructure, open source communities and the software they produce are important global resources. And similarly there is a “last mile” problem making sure these resources are accessible to everyone. While it’s easy to get the software, most organizations don’t have the capabilities or the culture to succeed with it on their own. This is especially true of complex and mission-critical enterprise software, and why companies like Red Hat and IBM have been so important to the adoption of Linux: engineering that last mile to connect more users to open source.
It looks like Red Hat will be the first open source company to top $1B annually—a milestone only a handful of software firms have attained. As the first open source company to realize this level of success, Red Hat is an important example that demonstrates the magnitude of the potential in the last mile. And their approach to serving their customers addresses the last mile in a way that aligns with and grows contribution to the Linux community.
So what’s in the last mile?
- The last mile for open source applications provides the pathway to enable any organization, regardless of their culture or technical capabilities, to:
- discover the application
- evaluate fit with the institution’s objectives
- deploy and configure the software in a production architecture that will support anticipated use
- integrate with other campus systems and 3rd party tools
- manage the application in production
- optimize performance and reliability with the latest updates and patches
- train users to get the most out of it
- troubleshoot and resolve issues
- understand and build their own balanced engagement with open source communities
Travelling the last mile
There are three ways organizations travel the last mile, running the gamut from build to buy, each finding a different balance between control, costs, resources, and responsibilities.
Build: Some organizations have the culture and capability to build the last mile on their own. This approach requires a fair number of people and skills. It is generally a more costly approach, but it affords an organization with a great deal of control as I’ve written about before. Organizations that take this approach are often major contributors to open source communities, adding everything from code to governance.
Borrow: Another group of organizations have the culture and some of the capability to successfully adopt open source applications and have been able to engage consulting firms to help by adding expertise and experience to augment their own capabilities. These institutions are nearly self-sufficient in steady state, but may continue to engage consultants from time to time, ceding some level of control.
Buy: There’s a third, far larger group of organizations that don’t have the culture or capabilities to engage with an open source community or effectively harness community products. For these institutions, assembling all of the pieces is a daunting proposition that would require hiring or reallocating staff. And, if this kind of investment isn’t a fit with the organizational culture or priorities for the application being considered, then—daunting or not—the approach isn’t a good strategic fit. Too often for this reason, some institutions rule out or don’t even consider open source.
From my perspective it is this last “buy” group that has a “last mile” problem with open source. And to address the last mile for them, we need to make open source as easy to discover, evaluate, deploy, and support as the proprietary, licensed alternatives.
Red Hat has done a great job of addressing the last mile for the Linux community. The company I work for, rSmart, works to solve the last mile problem for Sakai and Kuali—two global communities serving education by developing innovative enterprise software for academics, administration, and finance. Our aim is to make sure that the software these communities produce is accessible to every school, college, university, and training organization in the world.
An open path: rSmart and SunGard Higher Education partner to deliver Sakai
If uncertainty is one of the most significant barriers to widespread adoption of open source software, then the barrier just got a lot lower. This morning my company (rSmart), and SunGard Higher Education announced a partnership that promises to have a real impact on the adoption of the Sakai Collaboration and Learning Environment (CLE).
I’ve spent the better part of the last decade helping to build capacity for the education community to develop and sustain its most important software—software like the Sakai learning platform which supports a wide range of scholarly collaboration including online courses, hybrid courses, and inter-institutional research collaboration.
Today the Sakai and Kuali communities are made up of more than one hundred education-focused organizations of all shapes, sizes, and national origins. These communities are producing and sustaining high-quality, enterprise software that is functionally and technically on-par with any of the alternatives available to colleges, universities, and educational organizations serving K-12 or corporate learners. Institutions as diverse as Marist College, Indiana University, the Naval Postgraduate School, and the American Public University System are running these systems successfully to serve millions of faculty, students, administrators, and researchers—and they’re doing it at a lower cost.
Taking stock of the situation: 1) These communities are producing software that meets expectations and performs at levels the industry expects; 2) There are good examples of peer institutions across the spectrum of institution types using the software successfully; 3) There are good reduced total cost of ownership stories that are very appealing in today’s economy; 4) The Sakai and Kuali communities offer a path for institutions that appeals to the natural disposition in the market toward co-creation and open, collaborative efforts; and 5) At least one quarter of the market have legacy contracts for their learning platform that give them a time-certain deadline to transition from the platform they are running today to something new.
It seems like these conditions would represent a case for change, and that the market would be moving quickly to the Sakai path. And yet, while there’s a healthy growth in adoption, it falls short of its potential.
I believe that one of the most significant barriers to open source adoption is the uncertainty and unfamiliarity with open source software vendor relationships. Most organizations across industries aren’t capable, or don’t have the culture or desire to adopt open source software on their own. Most acquire OSS through more traditional vendor relationships. Though I am very proud of the rSmart team and what we offer our customers, we have a limited reach. This is one of the reasons I’m so excited about this partnership with SunGard Higher Education. rSmart’s community-centric culture, and strong competencies developing, supporting, and hosting Sakai, combined with SunGard’s reach, services capacity, and longstanding reputation for serving education may remove that difficult uncertainty barrier—it may finally create the open path that enables truly widespread adoption of Sakai.
Apples, Oranges, and Open Source
Comparing open source vs. proprietary software is like comparing apples and oranges. It’s a comparison that just doesn’t make sense for anything other than the basic comparison of licensing rights.
There are great variations among open source options, and among proprietary options. Yet many conversations about open source software tend to use very broad generalizations and treat each of these (open or proprietary) as a distinct thing. I’m involved in a lot of conversations about adopting open source software and I’m always struck by the black & white view of proprietary vs. open.
At the highest level organizations and even governments are adopting an ideological disposition that favors “open” vs. “closed.” In the education community there is often an affinity toward openness because of the alignment with core values and the mission of the academy. This is a good and healthy way to set strategy.
When it comes to making a decision about a particular need though, many people and organizations are looking for a pragmatic approach to making decisions about their options. Even those who have an established strategy that considers open source need to make specific decisions about the options for a particular need. This is where the simple open source vs. proprietary discussion breaks down. The general distinctions between open source and proprietary provide almost no useful information to inform a choice between X open source product, and Y proprietary product. In fact, most often, the choice isn’t really between X and Y, it’s between W, X, Y, and Z, where the other options represent the new choices afforded by open licensing.
Colleges, universities, K-12 schools and districts, have more choice today than ever when it comes to enterprise software. Despite a great deal of consolidation in the proprietary software vendor space, the emergence of community-developed, open licensed software, and SaaS services have more than filled the competitive void. I work in the Kuali and Sakai communities that together produce some of the most mission-critical enterprise systems for schools: eLearning Platform, Financials, Research, Student, Business Continuity, and more.
Some of the most important questions an institution can ask when considering the various options aren’t those that appear in an RFP with a feature matrix. They are introspective questions about institutional culture and capabilities–where the institution is today, and where it would like to be. And also, of course, what are the goals for the new system?
I spend a lot of time talking to people considering open source “alternatives” to the proprietary eLearning and ERP systems. I’ve recently begun to use a tool in those conversations that helps facilitate the conversation. If I’m near a whiteboard I’ll use that, otherwise the iPad makes a good mobile whiteboard alternative. Here’s a snapshot from a recent conversation:
This simple visual has been a very effective way of elaborating the choices for these software needs and comparing them on two dimensions. The two I’ve focused on have been cost and control. I typically talk about 5 different sourcing options:
- Licensed proprietary software
- “Home grown” software developed at the institution
- “DIY” (do-it-yourself) open source software (OSS)
- Commercial OSS
- Software as a Service (SaaS) OSS
Among the various choices it’s fairly easy to paint a picture of the options relative to cost and control tradeoffs. These aren’t the only dimensions to consider, but they are two that should be central to the decision. I should also note that control can directly relate to risk, strategic fit, and institutional capabilities (both current and desired future). One of the other reasons I’ve often focused on cost / control is because one of the most often cited reasons for looking at open source eLearning or ERP options is greater control.
You might be looking at the diagram, thinking… “He’s nuts. That green dot should be lower (or higher) or further to the right.” Good thinking. There isn’t one right way to paint this picture. It’s a conversational tool that needs to be adapted to fit the specific situation you’re talking about. I believe that there’s some “rough general truth” to the relative positions I’ve indicated, but the real usefulness is in the conversation & thinking that this tool facilitates, not where I’ve placed the data points.
As a starting point I’ll use this to understand current institutional culture and capabilities. How are systems generally sourced today? In some cases economics or new institutional leadership are driving a cultural change. The diagram can be a useful tool to understand how the various options support that desired change. It’s also interesting to note that the culture around things like eLearning or Research might be very different than the culture around Financials.
One of the most interesting conversations is about the various open source options. Ok, this is probably most interesting because it’s where I’ve focused for the past 8 years or so. Most people assume that to consider open source they have to hire software engineers and generally have to support it differently than the proprietary system they are replacing (the “DIY OSS” option). By the way most research and media coverage makes the same assumption. The visual helps to clarify that option relative to other options. There are good reasons an institution might move from proprietary or home grown to DIY OSS. There may be a strong institutional culture driving it. Often though, institutions believe that to leverage something like the Sakai eLearning platform they have to move to DIY OSS. And if that’s not a match to the institutional culture, or they don’t have the resources and don’t want to build the necessary capacity, the analysis stops. Most institutions, in fact, adopt open source software in the very same way they adopt proprietary software. But the options aren’t widely understood.
If you are involved in sourcing a replacement system, or a new capability for your institution. You have lots of options. Consider them all. You may find that’s it’s a useful exercise to compare the characteristics of each that are important to your institution. This should be a very strategic discussion that starts by determining the characteristics that are important to your institution: cost, risk, capabilities, control of future capabilities, alignment of values, future potential, opportunities for staff development, opportunities to align with peer institutions, etc. From there it’s a much simpler comparison exercise to understand how each option supports your goals.
Path Matters
There’s a conversation going on today on the EDUCAUSE CIO List about criteria for evaluating learning management systems (LMS). Patrick Masson, CIO at SUNY Delhi, suggested in that conversation, that a feature comparison might no longer provide the right assessment criteria. Brad Wheeler, CIO at Indiana University and uber-leader of Community Source in education, responded in agreement. Brad and Patrick each suggest that features among the various LMS options are roughly on par and don’t offer much in terms of differentiation. Brad goes on to suggest that:
“… the LMS decision is now more about choosing a PATH than PRODUCT if we conclude that products have similar base functionality at any point in time and have similar trajectories for improvements that matter. The paths differ greatly in cost, being a member of a type of educational community, the unbundling of software license fees/support fees (if required), and compulsory upgrades or even product withdrawals from the market.”
Back in 2007 Luke Fernandez wrote a thought-provoking piece that uses a metaphor that likens choosing a new learning platform to choosing a place to live. From my perspective it hits on the same idea that Path Matters.
Nearly all of my professional energy for the past 8 years has been focused on creating a sustainable capacity in higher education to develop enterprise-class software applications. The lion’s share of that focus has been on Sakai, Kuali, and rSmart.
From my own experience, more than anything else, from my work with friends and colleagues in these communities is that Brad and Luke are right–Path Matters.
In Patrick’s message this morning he suggests some new evaluation criteria in the spirit of starting a conversation. Admittedly Luke’s criteria are pretty technical:
- Identity management
- Integration & interoperability
- Use of open standards
Brad suggests aspects of path like:
- Cost
- Community participation (think of Luke’s metaphor)
- Unbundling of services
- Risk (product withdrawals)
I spend a lot of time talking to schools who have adopted community developed software like Sakai and Kuali. More than anything else they talk about the value of the relationships, the collaboration, the input they have, the intangible staff development opportunities, the ways in which they are transforming business practices through the collaboration among their staff and the staff who perform similar functions at other institutions.
In a world where Sakai, Moodle, Desire2Learn, and Blackboard are all on par in terms of the capabilities they enable for learning and scholarly collaboration, we need, as Patrick suggests, better selection criteria. I know from my own experience that, when Brad says “it’s about choosing PATH”, he’s right. So how can we capture these path intangibles in a better decision-making model? As Luke says in his response today:
“… steering a campus to give due consideration to PATH conversations is [not] an easy thing to do.”
I hope, for education’s sake, more campuses find ways to consider such important strategic aspects of the decision.
Oracle and Rimini Street battle over 3rd party support
I read the recent news about Rimini Street’s battle with Oracle with great interest this past week.
The Chronicle headline last Sunday was “A Small Company, Promising Major Savings on Vital Software, Lures Colleges.” The issue highlighted in the story:
Cost-conscious colleges are caught in the cross-fire of a legal battle between Rimini Street, the low-cost maintenance provider, and Oracle, a software powerhouse that serves hundreds of higher-education customers. In January, Oracle sued Rimini Street for running what Oracle calls an “illegal” and “corrupt” business model.
Rimini Street offers colleges and universities 3rd party support at half the cost of their current ERP maintenance contract. It’s not for everyone, but for schools that want to “freeze” their current ERP it seems like a great deal. Some schools intend to “stay put” with their current system for many years. They don’t want to go through required upgrades, they just need to stay current with fixes and regulatory updates, and they need someone who can help when issues come up. Other institutions intend to move from their current solution to something else. A transition like this is often a costly, multi-year endeavor. Because these institutions simply need to maintain & support what they have during the transition, Rimini Street is a great option because half of what they were paying the vendor for support can be applied to the cost of the transition.
This battle may stretch out for several years like the Blackboard patent dispute. If it does, Colleges and Universities will lose in the process. Like the Blackboard dispute, which was ultimately settled favorably (the patent was invalidated), it’s easy to get drawn into the gory details of the dispute. Why? Because it has potentially dramatic consequences for all of us who care about getting more value out of IT for the good of education.
There’s no question that, like the Blackboard patent battle, the consequences are very real for the companies involved, and their customers. A lot of money will be spent that doesn’t do anything to create real value, and that money ultimately comes from colleges and universities. In these hard economic times it’s difficult to stomach.
But rather than focusing on the details of this dispute, our time is better spent working toward the evolution toward more community developed software and educational resources. Initiatives like Kuali and Sakai are providing alternatives that make it easy to un-bundle software and services. For colleges and universities that means disputes like the one between Oracle and Rimini Street won’t limit competitive services. A few interesting things are happening:
- A lot more value is being created through collaborations that result in open educational resources. There is a growing amount of commodity software, and software core to the business of Education that is substantially driven by, if not fully, open source. The same goes for other open educational resources (OER). If you haven’t been following Brad Wheeler’s “Collaboration IS Strategy” it’s worth catching up on.
- Entirely new companies have emerged with new business models to fill the void where the evolution of community driven resources have advanced faster than the incumbent vendors’ ability to adapt. And they are growing rapidly.
- rSmart
- Flat World Knowledge
- Rimini Street
- MoodleRooms
- A lot of IT services that have been historically been delivered by individual institutions’ IT departments are moving “Above Campus.” Email, office applications, eLearning, content, and even ERP applications are being crowd-sourced and cloud-sourced.
What do these things have in common? From my perspective they are all market-driven forces that are challenging the status quo because the status quo isn’t delivering enough value. Educational institutions need to get more value from IT if they are going to live up to the potential of education to help us address some really big challenges affecting us all.
I'm Chris Coppola, CEO and co-founder of 
