4 The Rise and Fall of an International Medical EdTech Consortium

A few years ago, a friend and I gave a well-received presentation at a well-known technology in academic medicine conference called Building Together: Lessons Learned Building a Consortium. Creating this talk was both enjoyable and challenging, as it required us to distill a tremendous amount of experience gained over fifteen years of building an international open-source (turned community-source) software consortium. After presenting the talk again at an annual Consortium conference, I felt that this important work would translate nicely into a blog post, a story, and now a case study — one that may help other organisations considering a collaboration model learn from our experience.

The Story of the Consortium

Origins of the Collaboration

In 2008, after four years of developing a homegrown software solution for managing curricular data at our medical school, another major Canadian university was looking to replace a similar platform they had initially partnered with a commercial vendor to create. It was expensive for them to operate, and they found that they paid a significant amount of money to the vendor whenever they had to make changes to meet their evolving needs. In other words, the vendor relationship they built was cost-prohibitive and unsustainable.

After carefully considering their options, some truly progressive leaders asked our university if they could collaborate on the development effort for our software and share our source code. This collaboration was the impetus of what became our Consortium.

In 2011, a prominent American university formed an internal committee tasked with replacing its specialized learning management system after its commercial vendor discontinued the product post-acquisition and attempted to force a migration to another popular general-purpose learning management system. The committee reviewed eight platforms, which included homegrown tools, open-source systems, and vendor products. After a year and a half of extensive research, product demos, analyses, and pilots, they chose our software in 2013, and our Consortium sprang to life.

Collaboration Mechanics

Instead of simply sharing the source code between our three organisations, the Consortium we created became the vehicle that enabled both the technical and product collaboration.

From a technical perspective, the concept was to build and maintain the upstream Consortium software collaboratively first, then pull the released product down to our organisations for local customization and branding purposes before deploying it to our own self-hosted server environments. After several significant evolutions, we landed on managing the upstream software product using shared source code repositories on GitHub and tracking our features and bugs in a commercial project management system called Jira.

At first, our collaboration model was incredibly simplistic, and there was very little governance, process, and operational structure. Our teams would meet bi-weekly using readily available video conferencing technology to discuss the latest needs and how we would address them. Initially, having limited governance allowed us to embrace the now common “move fast and break things” paradigm, which worked well for a while but began to show cracks as Consortium participation increased and the software needed stability and maturity.

To address the need for increased governance, we ended up creating a Consortium Advisory Committee (Advisory Committee Terms of Reference [docx]) and two sub-committees, the Product Management Committee (PMC) (PMC Terms of Reference [docx]) and the Architecture Review Committee (ARC) (ARC Terms of Reference [docx]).

The Consortium Advisory Committee was chaired by and reported to the Director of Information Technology at the host university and comprised representation from six of the early adopting organisations and two rotating two-year term representatives. This committee was responsible for maintaining our mission, vision, and strategic plan, the big-picture prioritization of areas of focus, the development and approval of policies, procedures, and best practices, and overseeing the work of the Product Management and Architecture Review Committees. It is important to note that this structure resulted from multiple iterations of governance attempts. This final governance structure worked well, with leadership focused on leadership activity, product experts focused on product functionality, and technical experts focused on architecture.

To enhance operational efficiency and stability, we formed a “Core Team,” a dedicated department for the Consortium within our Faculty at the host university. The team had its own budget, funded through an annual $60,000 Consortium fee paid by participants, which increased over the years with inflation. The fee itself was determined by understanding the true costs of running the department and dividing it equally between the participating organisations. This low annual Consortium participation fee was often inconsequential compared to what schools would otherwise pay to commercial vendors for similar or less capable software. And that was the point. Schools would then have money available to invest in themselves and their own technology teams, who would, in turn, contribute back.

Our scalable and sustainable funding model supported the salaries of several dedicated staff members, including an Associate Director, Technical Lead, Product Lead, UI/UX Designer, and Web Developers, as well as covering the administrative overhead costs of operating within the university. This Core Team provided stability and support for the Consortium community. Also, it functioned as a corporate memory in a sense, as when there was instability within a participating organisation, such as leadership or staff turnover, there was a stable team who could help the participating organisation with retraining, orientation, or re-onboarding.

Ingredients for Successful Collaboration

So why did our collaboration work so well? What were the magical ingredients that made our teams click, translating into a successful product, stable collaboration, and substantial growth in the market?

1. A shared vision and goal — to develop and maintain a robust teaching and learning platform that meets the ever-evolving business needs of our organisations.
2. A culture of collaboration and sharing — a willingness to work together and share not only source code but also requirements, ideas, documentation, and processes.
3. Buy-in from leadership — an organisational commitment to dedicate the people, the time, and, of course, the money to support the initiative, with the expectation of a high return on investment.
4. Open communication — despite the geographical distance between our organisations, working together was rarely a barrier. We were “working remotely” long before remote work was the norm. We had regular open communication through chat rooms on Slack, email mailing lists on GNU Mailman, bi-weekly meetings through web conferencing, and even an annual in-person meeting, which later became a popular international conference.
5. Technical aptitude — an intelligent, ambitious, and focused team working to solve interesting and complex problems in the niche medical education market. The team had the technical know-how to collaborate effectively, manage and maintain software and servers, and address issues as they arose.

Interest in Commercialization

After several years of increasing success with our consortium model, and as the software product continued to mature, the Dean of our Faculty began to push for a potential pathway for commercializing the product. While a commercialization pathway was never the intent of our collaboration, the Consortium Advisory Committee did understand and agree in principle with the fact that the full impact and benefit of the software we were building could never be fully realized in a pure-consortium model, given the technical expertise required by an organisation to maintain, upgrade, and develop software hosted on-premises. The consensus from the Consortium community was that we wanted to keep the software open-source and self-host our implementations of the software but that we would also welcome the concept of a Software-as-a-Service (“SaaS”) commercial vendor into the Consortium, with the assumption that a successful vendor would become a prolific contributor and could potentially inject funding and enhance the Consortium’s influence, sustainability, and long-term viability.

Between 2015 and 2020, while continuing to grow the Consortium to 21 universities spread across Canada, the United States, and Singapore, our university spent countless hours and substantial energy with technology-transfer units, venture capitalists, investors, and lawyers, attempting to fulfill the mandate of establishing a viable pathway to commercialization.

In my opinion, we never found the right investment partner during this crucial phase. It was not that the software wasn’t impressive, that the market was too small, or that the growth wasn’t remarkable; it was that the individuals we met could not comprehend how open-source software could be investible. Given how we had structured and licensed the software under the GNU GPL v3, the intellectual property (“IP”) was owned by the universities or, in some cases, the individuals who created it. I often referred to this as an “IP constellation,” and in my opinion, this was more of a feature than a bug because it prevented any single institution from unilaterally making IP-related decisions that could impact the others. Unfortunately, my perspective was not shared by the individuals we met, so according to the advice our university received, the product was not investible in its current open-source state. This advice was disappointing, and no number of modern examples, proposals, or evidence provided was enough to alter any opinions. As a result, our university determined that moving forward, the software licence would need to change, and the IP would need to be owned by our university.

In 2018, after a substantial amount of effort, our university created a new Software Consortium Agreement coupled with a new custom-built community-source software licence. This agreement and licence ultimately capped the Consortium at its current size, transitioned future versions of the software to a commercial licence, and transferred ownership of the intellectual property to our university. Consortium participants did raise some concerns throughout this transition; however, organisations ultimately signed onto the new agreement with the understanding that our university would safely steward the intellectual property and proceed with the SaaS commercialization efforts, which would benefit all.

Over the next few years, the collaboration efforts continued to be refined and improved, the software continued to mature, and the community collectively continued to support the concept of the eventual arrival of a commercial vendor Consortium participant.

The Launch of SaaS

In 2021, approximately six years since the former Dean of our Faculty began pursuing commercialization efforts, our university officially launched the new start-up company. New clients were ready and started signing up for their Software-as-a-Service offering of the software initially created by the Consortium community. Despite the challenges of launching a new start-up company during the COVID-19 pandemic, there was substantial optimism from all parties that this new company would be successful and high hopes from the Consortium community that they would realize tremendous benefits in terms of contributions, recognition, and long-term viability.

However, after its launch, it didn’t take long for tensions to rise. Software start-up companies must be focused and competitive. As one would expect, the new company was squarely focused on their customers, their revenue, and their growth, but surprisingly, they abandoned the concept of contributing to the software releases of the Consortium and moved towards developing a forked version of the software. There were strong indications to many that the new company felt the Consortium presented competition instead of allies and collaborators, which cast a heavy shadow of mistrust between the Consortium community and the budding start-up company.

The End of the Consortium

In July 2023, five years after our university took ownership of the intellectual property and only two years after launching the start-up company, the intellectual property and company were sold to an American private equity firm. At the same time, our university announced a review process to decide whether to discontinue in-house development and adopt the SaaS version of the software and determine if they would transition the Consortium to the company using an assignment clause within the Software Consortium Agreement signed by the organisations in 2018.

The review process was difficult for everyone in the Consortium community; it took six months to complete. Finally, on January 25th, 2024, our university announced that it would be moving to the SaaS version of the software and that as of February 26th, 2024, the Consortium would be transferred to the company to become a short-lived corporate division that would ultimately be closed as of June 2025.

What began in 2008 as an effective collaboration between universities grew into far more than a shared software project — it became a framework for collaboration, a mechanism for institutions to pool their knowledge, ideas, and expertise in ways that extended beyond code. The Consortium fostered a community where niche medical educational challenges could be tackled collectively and where institutions could refine not just their technology but also the very processes that supported their educators and learners. Its low-cost model allowed universities to invest in their own teams, developing internal expertise, innovation, and self-sufficiency.

Now, with its closure, Consortium participants face a critical decision: adopt the SaaS product, maintain their on-premises implementation on their own, or transition to an entirely new system. As institutions navigate this shift, many may find themselves relying more on external vendors, redirecting financial resources outward and potentially reducing their capacity to cultivate in-house expertise and shape their own technological and educational future.

The Consortium was more than a software project—it was a framework for collaboration and innovation, and its impact on academic collaboration and technology innovation will continue to be felt far into the future.

The Lessons Learned

There are many different perspectives from which this story could be told; my perspective is that of someone within the higher education community who values academic and technical challenges, collaboration, and community above many other things. Therefore, the lessons I have distilled from this experience reflect those values.

1. Select the correct licence for your output

How you license your output will influence adoption and culture within your collaboration and determine what you can do with and what can be done to the output of your collaboration in the future.

We were creating software in our case, but the need for a licence extends far beyond software. We started using the GNU General Public License v3.0 (GPL v3) open-source software licence. While this licence was perfect for our initial needs, once our organisation signaled an intent to commercialize the product, they were uncomfortable with the copyleft license that prevented the extent of commercialization they were ultimately after.

Through significant difficulty and expense, we transitioned to our own community-source software licence, which was more restrictive but better reflected how we operated within our consortium model at the time.

Looking back, it seems like a chicken-and-egg scenario. If you spend all your time and energy upfront, with all the decision-makers at your organisation, determining what may eventually become of the software you have not yet built, you may never get around to creating it. But, if you don’t get enough initial input or buy-in from everyone in every layer of the organisational onion, you might be missing the opinions and input of individuals who will require changes in the future.

2. Clearly document how you handle intellectual property

Who owns intellectual property created by the collaboration must be crystal clear in order to avoid future conflict and wasted energy.

While this will be very clear legally in the software licence, it’s essential to recognize how difficult it is to change intellectual property ownership later. As I mentioned, we started using the GPL v3, resulting in what I refer to as an “IP constellation.” Maybe that’s good for you, maybe it’s not, but it’s something to be aware of.

Take the time to define what is considered intellectual property. Is it an idea, the documentation, the processes, an entire file within the software, or lines changed within a file? There are, of course, legal definitions to be aware of.

Ensure that all contributors to your output, including students, faculty, and staff, have employment contracts that specifically outline intellectual property ownership. You should also have a “Contributor Licence Agreement” that individuals sign in if the organisation they’re contributing through has either no policy or conflicting policies. For an excellent example, please see the Individual Contributor License Agreement (ICLA) from the Apache Software Foundation.1

Trademark tip: If you choose a formal name for your collaboration, ensure you can get the appropriate registered trademark in every country in which you intend to operate. Failing to do so may result in a time and energy-consuming rebranding exercise.

3. Define and communicate your governance structure

An appropriate governance structure will balance innovation and creativity with process.

What should a governance structure look like?

You should recognize there is likely governance already above you that will drive or influence your collaboration. Also, consider that your internal governance needs will change from time to time as the maturity of your collaboration and the product evolves.

When should governance be introduced?

Your collaboration’s governance is essential; however, governance will, in most cases, slow down the ability to make decisions. This slowdown isn’t necessarily bad. However, consider the milestones necessary before introducing appropriate governance.

Starting with a rigid governance structure may unnecessarily hinder innovation and creativity but introducing it later in the life of the collaboration is a complex change to manage and communicate.

4. Define your mission, vision, and values

By defining your mission, vision, and values, you will have robust documentation to refer to during planning and difficult decisions.

We officially defined our mission, vision, and values in 2018, ten years after the Consortium began. We did this while developing our first Strategic Plan (2019–2022). This process felt unnatural to me as a software developer in a leadership role; however, this was a beneficial exercise, thanks to a few talented facilitators and our collaborative Consortium Advisory Committee. Even if this is done early in the collaboration and requires revisiting, it is still worth it.

5. Recognize your goals

Whether or not you initially recognize them, there are goals. You have goals, individual contributors have goals, and organisations have goals. You could easily substitute the word “goals” with “interests” in this lesson, which may more accurately represent the lesson’s intent.

What are your own goals for this collaboration?

As someone presumably integral to the collaboration, it’s essential to be honest with yourself and recognize your personal goals. What motivates you to do all the additional work necessary to make this collaboration successful? Because it’s going to take a lot of work. Collaborating with others takes several times more energy than solving a problem by yourself. As the popular saying goes, “If you want to go fast, go alone. If you want to go far, go together.”

What are your organisation’s goals for this collaboration, and do they align with yours?

Do your best to determine the organisation’s goals that support this collaboration, recognizing that these goals may change over time (e.g., from Dean to Dean, CFO to CFO, CIO to CIO, or accreditation to accreditation). Consider whether your own goals align with the goals of the host organisation. From experience, it may feel like you’re pushing a rock uphill if you want to build open-source software but the organisation you work for is more focused on a commercialization pathway. Also, consider whether your idea for collaboration fits into the strategic plan of the organisation employing you. If it does, make every effort to communicate that fact and map what you do to the strategic plan.

6. Consider the size

Will this be a manageable localized collaboration that solves unique problems in a geographical region or niche market, or do you need this to scale to a national or international market?

How big do you want your collaboration to get?

From experience, collaborating with three teams is very different than collaborating with 23 teams. Not that one is better than the other; it’s just that the larger your collaboration gets, the more critical it is to have all the other lessons we discuss (e.g., Goals, Mission, Vision, Values, Governance, Licence) fully dialed in.

7. Build a strong community

A strong and supportive community will be your most significant source of strength.

How can you create an engaged community?

We were continually learning better ways to do this. An effective community isn’t built overnight; it is cultured through clear vision, consistency, and integrity. Be inclusive and ensure that everyone has a voice.

The community engagement opportunities we provided to the Consortium community included:

• a community-focused chat infrastructure through Slack with hundreds of participants (e.g., faculty, leadership, administrative staff) and dozens of focused channels ranging from committees and working groups to general help and advice;
• a few low-volume email mailing lists through GNU Mailman that were ultimately less used for discussion and more for community announcements;
• a bi-weekly Consortium community meeting hosted through web conferencing that would routinely have 60–90 attendees; we encouraged participants to turn on their cameras and provided a structured agenda while leaving plenty of opportunities for impromptu collaboration or questions;
• a bi-weekly or monthly one-on-one Consortium participant check-in web conference call to ensure that the team responsible for delivering our software for the organisation had their questions and needs met whenever possible; and
• an annual in-person conference that started with only ten participants in a single meeting room but eventually grew to over 285 attendees from all three countries involved in the Consortium.

How can you involve the right people?

Onboarding a new participant, whether an organisation or a person, is an expensive operation at the best of times. From experience, onboarding the wrong participant can be an incredible drain on resources. Discuss with your community what makes a good participant, and focus your energy on attracting fully aligned and committed participants.

Conclusion

Building a successful Consortium requires a shared vision and goal, a culture of collaboration and sharing, buy-in from leadership, open communication, and some technical aptitude. These ingredients and a willingness to adapt as you go will help to ensure that you will go far together.

While our specific collaboration can no longer evolve, I am excited to see where and how the lessons we learned from the incredible experience may inspire and guide others as they embark on their collaborative journeys.