Open source is not a patchwork problem. It’s a blueprint solution.
I recently read an article, "The High Stakes of Digital Sovereignty: Can Dutch Academia Divorce Microsoft?" written by Victoria Mossi in, WebProNews . Several comments in the article got me thinking...
The friction of migration is the primary defensive moat for Big Tech. Moving petabytes of research data, emails, and administrative records from a cohesive ecosystem to a patchwork of open source alternatives presents a logistical nightmare.
This nightmare is not an issue specific to open source; it is an issue related to any enterprise migration in which all of an organization's services, content, etc., are sequestered within a single-vendor ecosystem. The same logistical nightmare of moving petabytes of research data, emails, and administrative records would exist if a campus migrated from Microsoft to Google.
The term "patchwork" is also an interesting choice (pejorative?) to describe an open source environment and shows a bias toward commercial/corporate monolithic solutions (simply because they are the most widely used?) while demonstrating a lack of understanding of the inherent value and architecture of both historical paradigms in digital and networked services and current affordances enabled by open infrastructure. Indeed, the entire Internet is a "patchwork" (I'll use this as a compliment just like the EU) of open source software and open standards, designed expressly to avoid any part of the network being either controlled or vulnerable to a single technology, company, or government. Replicating such a patchwork should be the goal of institutions of higher education (a sector, by the way, which contributed significantly to the highly diversified and distributed architecture that is the Internet and the World Wide Web today).
So the patchwork is the desired model. Any claim that "standardizing" on one technology or company (e.g., Microsoft) will remove or even diminish migration woes is a bold statement, especially now, given that every campus in the world now must deal with the Windows 10-to-11 migration. Here's the nicest recap from a campus IT director I could find. But perhaps an actual timeline of Microsoft's "cohesive ecosystem" would best render this point moot. [1]
While alternatives exist, few offer the seamless interoperability that defines the Office suite.
I suppose nothing makes "seamless interoperability" more achievable than being forced to use all of one vendor's tools and services. It should not be a surprise that using Microsoft software provides tight integration and interoperability with Microsoft software; again, this would be true with any single-sourced provider, such as Google or Oracle. However, there is a difference between specifications and standards. Most technology vendors are happy to provide specifications to ensure integration and interoperability across and within their product portfolios, but few are willing to support open standards (unlike in open source, where open standards are a core value). While this provides seamlessness within a vendor's toolset, it restricts (and even stops) the same level of seamlessness with any other service, resulting in vendor lock-in or, worse, a vendor black hole that campuses can never escape.
[open source] functionality often lags behind the polished, AI-integrated features that Microsoft rolls out with relentless speed.
The claim that open source "lags behind" proprietary platforms like Microsoft in innovation just does not hold up. In reality, almost every foundational technology behind today's "polished" enterprise and AI platforms began in open source first. Containers emerged from Linux kernel work on cgroups and namespaces long before Microsoft branded Azure cloud services; Git redefined version control years before Microsoft bought the market-leader; Kubernetes set the global standard for orchestration again before Azure, (and AWS and Google for that matter) wrapped it in managed services; and the web itself—from Apache and Nginx to PostgreSQL, JSON, and OAuth—was built by open communities and only later productized by vendors like Microsoft (does anyone use IIS or Internet Explorer—oh wait everyone seamlessly migrated to Microsfot Edge.).
Even Microsoft's own ecosystem tells this story: Azure runs on Linux and Kubernetes, Windows ships with Linux via WSL, VS Code is open source at its core, and GitHub is built on Git—all open source innovations Microsoft adopted, not invented.
The same is true for artificial intelligence. The infrastructure underneath Microsoft Copilot—TensorFlow, PyTorch, Hugging Face, ONNX, diffusion models, and open LLMs—was developed in open collaboration and only later integrated into commercial platforms. What vendors excel at is not inventing these systems first, but packaging, branding, integrating, and distributing them at scale. Open source leads in invention and experimentation; proprietary vendors lead in polish and enterprise distribution. The correct distinction, therefore, is that "[open source] branding often lags behind the polished, marketing that Microsoft rolls out with relentless speed."
Open-source software often requires significant internal IT overhead for maintenance, security patching, and user support—costs that were previously bundled into the Microsoft license fee.
So we agree that those costs remain: Microsoft does not provide maintenance, security patching, and user support for free; those costs, like all of Microsoft's non-technology costs, are hidden in campus licensing fees. Incidentally, many argue that understanding the implementation and maintenance costs of an organization's technology portfolio is a best practice and an IT manager's responsibility.
What other costs are buried in Microsoft's licensing fees? According to Finbox, "For the fiscal year ending June 30, 2025, Microsoft's total sales and marketing expenses were approximately $25.65 billion, and its specific advertising costs were around $2.1 billion."...all paid for by customers through licensing fees? At UMass (where I once served as CTO), the UMass Office of the President's budget (five campuses) for FY2025 was approximately $4.3 billion. University-wide infrastructure services, including digital systems and research IT, were $51 million in FY2024.
Microsoft's annual marketing spend would support 2,451 campus IT budgets or the entire UMass system 5.8 times, or about 29 campuses.
... [a] university does not operate in a vacuum; it collaborates with institutions in Boston, Tokyo, and London. If the rest of the world communicates via Teams and formats documents in Word, a unilateral move to open standards can create friction in international collaboration.
It's actually the exact opposite. Open standards—such as those developed by the IETF, W3C, OASIS, and, most significantly for education, 1EdTech and EUNIS (video)—were explicitly created to enable interoperability across platforms, vendors, and borders. From TCP/IP and HTTP to HTML and the OpenDocument Format (ODF), these standards have been essential for enabling global communication and collaboration without relying on proprietary tools. ODF, standardized by ISO/IEC 26300, ensures that documents remain accessible and editable regardless of software or vendor (even if they don't want it), directly addressing the risks of lock-in that formats like Microsoft's OOXML pose.
Far from causing friction, open standards reduce it by creating a level playing field. Governments and institutions worldwide—including in the UK, Germany, and many others—have adopted multiple open formats (national signatories of the Open Data Charter) to promote long-term access, digital sovereignty, and inclusive collaboration. Relying solely on proprietary specifications in systems like Teams or Word can exclude partners, introduce licensing barriers, and tie collaboration to specific vendors' decisions. Open standards are not a unilateral divergence—they are the global norm for sustainable, vendor-neutral cooperation.
Compatibility issues—formatting errors in grant applications, inaccessible calendar invites, file corruption—can hamper the very research the university aims to protect.
In order:
"Formatting errors in grant applications:" Text Formatting Consistency in Documents, OpenDocument Format (ODF)
"Inaccessible calendar invites:" Calendar Invites and Scheduling Interoperability, iCalendar (RFC 5545)
"File corruption:" File Formats for Smooth File and Data Transfer = ZIP, PDF, CSV, XML, JSON, and more.
There is also the cultural resistance of the workforce. Faculty and staff, already burdened by administrative overhead, are generally resistant to learning new workflows. The "switching cost" involves thousands of hours of retraining.
As already noted [1], proprietary software vendors like Microsoft are continuously introducing change into organizations through service updates, product upgrades, security patches, and new versions. While many of these disruptions might rightly be perceived as positives — who doesn't want security patches and new features? — corporations that develop proprietary software are also vulnerable to other disruptions directly felt by adopting organizations: product sunsetting/end-of-life, vendor mergers (and thus the products and services offered), corporate acquisitions, and company bankruptcies. Each of these events ripples through adopting organizations, often without warning or preparation.
Yet somehow, for some reason, universities, faculty, and students make it through and seem content to shrug their shoulders, as if such disruptions and the resulting administrative overhead, learning new workflows, and thousands of hours of retraining are just the cost of doing business. Need a reference point? Universidad Pública de Navarra began using the learning management system Sakai in 2008 and has been running it ever since. Meanwhile, in the corporate proprietary LMS world, WebCT and Angel Learning were bought by Blackboard, which was purchased by Anthology, and is now in bankruptcy. I know a university system that migrated to Angel only to have to migrate to Blackboard two years later, then faced another disruption two years again, when Blackboard required campuses to move to its hosted "solution." After the Blackboard contract expired, the university ran an RFP for a new LMS and selected Brightspace, requiring another migration. "Switching costs" indeed!
Recommended by LinkedIn
Unless the alternative offers a superior user experience—which is rarely the case with underfunded open-source projects compared to trillion-dollar tech products—adoption remains sluggish.
I don't know which era of open source this article is referencing, but the user experience for open source software is (often) the same (especially as iconography and workflows standardize) or better (as end users can modify the interface to their own needs). For fun, check out the screenshots below and pick which is the commercial version and which is the open source version (answers below).
Which is the open source option...?
Also, I'll note here that "underfunded open-source projects" is the wrong metric for assessing the value/quality/viability of open source software. Yes, open source can always use funding, and I, as E.D. at Apereo, spend a lot of my time seeking financial support for the Foundation and our projects. But an open source project can run on much smaller budgets than a proprietary one, since much of the development is a by-product of a contributor's actual job, project, or work. This is evident in the open source development environments across higher education, where projects launch as part of other activities, such as research projects, teaching and learning programs, or campus/system initiatives. Most of the people working on an open source project in higher ed are faculty (who have jobs), researchers (who have funding), students (who are working toward a degree, not software), or IT staff (employed by the university). Arguably, because so much open source development in university settings comes from academic staff and students, open source projects for education are even better positioned.
Ideally, even open source projects outside higher education, in and of themselves, are not stand-alone businesses or vanity projects led by an entrepreneurial maintainer trying to create a business, monetize their work (e.g., through VC investments or selling to another company), or build a professional profile [2]. Better metrics for the success of open source are the number of contributors and adopters, how quickly issues and bugs are resolved, the day-to-day activity of the community (discussion posts, events, etc.), and other non-financial metrics.
Finally
The question facing higher education is not whether migration is hard. It is. But staying locked into proprietary systems is no longer the safer, easier, or more sustainable path.
The real question is: What kind of digital future do universities want to build?
One dominated by opaque licensing, marketing-driven priorities, and vendor lock-in?
Or one built on shared standards, collaborative development, and open, sovereign infrastructure?
Open source is not a patchwork problem. It’s a blueprint solution.
1. Timeline of Microsoft-initiated migrations and their impact on adopting organizations.
1999: NT4 → Active Directory (Windows 2000 Server); Rebuilding domain structure and re-architecting identity systems.
2003: Exchange 5.5 → Exchange 2003; Required full Active Directory deployment and domain restructuring.
2007: Office 2003 → Office 2007; Ribbon UI overhaul required mass user retraining and macro updates.
2010: SharePoint 2007 → SharePoint 2010, Major architecture change; needed service applications redesign and complex migrations.
2010: OCS → Lync Server 2010; Rebranding and VoIP changes required new infrastructure and staff expertise.
2011–2013: BPOS → Office 365; Directory sync and federation (ADFS) setup was complex and error-prone.
2015: Windows 7/8 → Windows 10; New servicing model required revamping patching and deployment workflows.
2016: Exchange 2013 → Exchange 2016; Simplified architecture, but mailbox moves and hybrid setup were still complex.
2017: Skype for Business (on-prem) → Skype for Business Online; Required hybrid deployment and retraining, even for the same features.
2019: Skype for Business → Microsoft Teams; Re-architecting communications, governance, and user education; no in-place upgrade.
2019: Azure AD Connect (legacy) → Azure AD Connect v2; Required complete rebuild in some cases; legacy versions deprecated.
2021: SCCM + Intune → Microsoft Endpoint Manager; Merging systems required duplicated policies and slow migration paths.
2022: Multiple Compliance Tools → Microsoft Purview; Required reconfiguring labels, policies, and audit controls across tools.
2023: Exchange 2013 EOS → Move to Exchange Online/2019; Time-sensitive migrations; on-prem → cloud had complex hybrid needs.
2023: Azure AD rebranded to Entra ID; Admin portal changes and documentation rework caused confusion and retraining.
2024: Windows 10 → Windows 11; Hardware requirements (TPM 2.0, UEFI) forced hardware refreshes and testing.
(Planned) 2025: Exchange Server 2016/2019 → Subscription Edition; New licensing and migration model; likely no in-place upgrade path.
Ongoing: Office 365 + Copilot rollout; Requires tenant-wide policy reviews, licensing changes, and data exposure assessments.
2. I suspect this line of reasoning will infuriate some, especially those who are working tirelessly and unappreciated to maintain projects that many depend on, yet with few supporting them financially or in any other meaningful way. I'll stand by my higher ed/edtech perspective that open source is a by-product of research activities (post-docs, grad students, etc.) working on software to enable their research, like any other lab technology, or academic initiatives where funding is part of "release time" for IT staff to implement a program. This distinction is one of the reasons organizations like Apereo are needed, as there are fundamental differences in development and management models within higher education and even education more generally.