Open Source Your University

" We're not sharing code in any meaningful way with each other. There isn't a true professional network of community practice; this is counter to how academic communities work.  We should really be standing on the shoulders of our peers instead of inventing the wheel time and time again.  What if the scientific world acted like this?"

-DrupalCon Portland 2013 Session: Unconsortium The Next Phase of Drupal Collaboration in Higher Education.

One of my favourite things about the Edu Drupal Unconsortium is that it’s growing one person at time, and impacting Higher Ed from the 'outside-in’.  It’s the power of 'open' in action - a grassroots movement of individuals (not institutions) seeking to disrupt the traditional, expensive and broken methods of developing software solutions by silo.

Higher Ed already understands ‘Open’. One could even argue we're flogging Open right now,  with seemingly endless articles, projects and initiatives like OER, Open Textbooks and MOOCS (oh the MOOCS!).  Universities are adopting open source solutions like Drupal and Moodle at a blinding pace, however the extent of open software participation ends at 'download' - and here lies the problem.

This user-centric approach to open source projects like Drupal means hundreds of thousands - millions of dollars spent on in-house development and maintenance. I’ve sat through more than one Drupal session where developers complained about ‘upgrade nightmares’ resulting from patched core, or buggy custom-modules. Entire institutions are hostage of of processes like these and it simply doesn’t have to be this way.

Imagine what we can accomplish, if contribution to open source, and community participation were expected pieces of development workflow in Higher Ed?  Innovation happens in collaborative environments - we’re missing out on that, hammering away at the same use-cases over and over and over again.  It's exhausting!  Why?

If you are that person working in an institute of higher education who gets this - no matter your role profile, here are a few suggestions on bringing your institution into the open:

Be Deliberate

An institution doesn’t just ‘open source’ itself, the idea seeps in.  Speaking from experience, no matter how passionate, and seemingly convincing you feel you are...this takes time, and there will be doubters.  Pledge patience, but be deliberate: run a 'Lunch and Learn' on Drupal in Education,  perhaps organize a small documentation sprint, tell a community story, teach someone how to submit a patch. Lead by example.

Find Allies

All those OER, Open Textbook, MOOC, Open Badges people in your university are allies - connect with them.  Even if your department has no interest, these people will.  Consider a collaborative effort that includes all open initiatives.  Ask questions. Open Michigan inspired our Open Royal Roads earlier this year, and wouldn't have been possible without cross-unit collaboration.

Define Contribution Guidelines

Laws around data exist for a very good reason,  and although this is an obvious one I want to state: being ‘open’ also means being responsible.  Acknowledge risk, and privacy rules by preparing and documenting contribution standards. Think of this as a code-review for contribution - not everything should be shared.  This will help ease concerns and create a framework to scale.

Check Your Pride

Sharing imperfect code is a challenge for the ego.  The ego of a University is even tougher to calm, but holding for perfection is probably the number one reason contribution never happens.  Find balance, and let go.

Invest in Mentorship

Although the Drupal community is already an incredible one for learning and support, it seems important to say that reaching out to others goes a long way building an initiative like this one. Share what you know, share what you’ve learned - encourage empower and congratulate those who are following your footsteps.  Teach, teach, teach - share what you know.

Make Time

Most developers I know on this project, or similar contribute on their own time.  We do it because we believe in the importance, love the learning and OK it's also fun... but universities need to make the time as well.  Universities need to include community contribution and participation a part of development workflow - by scheduling it. Ask for a small percentage of time for community contribution.

Propose a Project or Contribute

Sign-up, and check out our list of current projects, or propose your own.

Recommended Reading:  Working in the open: 7 recommendations from Mozillians.

PS: I would be interested in other best practices, and advice you would suggest for bringing universities into open source!

Image Credit: Rak Tia, Rupert Ganzer

1 Comment

Not Invented Here *has* to go!

I really like the point you make about "check your pride" ... the NIH syndrome one of the highest barriers to collaboration across institutions, imho. I think it's much healthier, and productive, to admit that we are *all* learners. That and we should embrace the bazaar-style development and distribution methods of the Drupal community. Release Early, Release Often necessarily means that we release code when it's not perfect. A challenge for some of us, to be sure. It's natural to want to fix that one last thing before something is "ready" to be shared. We have to get over that. Share earlier. In whatever state our projects are in. Even better, share intent, before projects start, that way we might even be able to collaborate on building something together. Crazy talk? I don't think so.