Building Together: Part Two

Part one of my “Building Together” series, Ingredients for Successful Collaboration, covered the origin story of the Elentra Consortium, an international open-source (turned community-source) software consortium in Canada, the United States, and Singapore. I also defined what I believe are the key ingredients that made our collaboration successful in the first place. If you have not yet read part one, I recommend starting there.

In part two, I will cover the lessons we learned while building and operating our consortium for over a decade. Some of these lessons we got perfectly correct from the start, others we had to learn the hard way.

Lessons Learned

1. Select the correct license 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 license extends far beyond software. We started by using the GNU General Public License (GPL) open-source software license. While this license was perfect for our initial needs, once our institution signalled an intent to commercialize the product, they were uncomfortable with the copyleft license, which prevented the extent of commercialization they were ultimately after.

Through significant difficulty and expense, we transitioned to our own community-source software license, which is more restrictive but better reflected how we operated within our consortium model.

Looking back, it seems like a chicken and an egg scenario. Suppose you spend all the time and energy upfront with all the decision-makers at your institution, determining what may eventually become of the software you have not yet built. In that case, you may never get around to making it. But, if you don’t get enough input or buy-in from everyone at every level of the onion, you might be missing the opinions and input of people who will require changes in the future.

2. Clearly document how you handle intellectual property

Who owns the 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 through the software license, it’s essential to recognize how difficult this is to change later. As I mentioned, we started using the GPL (open-source), 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, lines changed within a file, etc. 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, and you should also have a “Contributor License Agreement” that individuals sign in the event the institution they’re contributing through has no policy or conflicting policies.

Trademark tip: If you have a formal name for your collaboration, ensure you can get the appropriate registered trademark in every country 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.

3.1 What should your governance structure look like?

• Elentra Consortium
  • Advisory Committee
    • Product Management Committee
      • Topical Working Groups
    • Architecture Review Committee
      • Topical Working Group

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.

3.2 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, but 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, but thanks to a few talented facilitators, this was a beneficial exercise. 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 recognize it initially, there are goals. You have goals, individual contributors have goals, and institutions have goals. You could easily substitute the word “goals” with “interests” in this section, which actually may be more accurate.

5.1 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 what your personal goals are. 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 work than creating a homegrown solution for yourself. As the African proverb states, “If you want to go fast, go alone. If you want to go far, go together.”

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

Do your best to determine the goals of the institution 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 institution. It may feel like pushing a rock up a hill if you want to build commercial software that makes a lot of money, but the institution you work for is focused on curricular design. Also, consider whether your idea for collaboration fits into the strategic plan for the institution employing you.

6. Consider the size

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

6.1 How big do you want your collaboration to get?

From personal 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 (e.g., Goals, Mission, Vision, Values, Governance, License) fully dialed in.

7. Build a strong community

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

7.1 How can you create an engaged community?

We are always learning better ways to do this, and we are just getting started. An effective community isn’t built overnight; it is cultured through clear vision, consistency, and integrity. Ensure that everyone has a voice.

Presently, we do the following:

• Host a Slack Team with hundreds of participants and dozens of channels ranging from committees and working groups to general help.
• Host a few different email mailing lists, which are less used for discussion these days and more for announcements.
• Host bi-weekly consortium community meetings that routinely have 60-90 attendees.
• Host an annual in-person conference that started as ten developers in a meeting room and had over 287 attendees last year.

7.2 How can you involve the right people?

Onboarding a new participant, whether an institution or a person, is an expensive operation at the best of times. Onboarding the wrong participant can be an incredible drain of resources. Discuss with your team what makes a good participant, and focus your energy on working in that direction.

Conclusion

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

As we continue to evolve, we are excited to see where our journey takes us and to share our experiences with others who are building collaborations of their own. I hope our lessons learned can help inspire and guide others as they embark on their collaborative journeys.

I hope that you enjoyed this series. I would love to hear from you, so please comment below or connect with me on Mastodon or reach out by email.