This is one example of how some custom code became part of the contrib-cm layer of CMDrupal, the benefits of developing openly over open sourcing code after it's "done", and how this project continues to grow and change. Having a basic understanding this process is important for everyone using Drupal or CiviCRM in a community media environment. Probably not as important as understanding how a bill becomes a law, but like government… without an understanding of how it works, it is difficult to make improvements.
Not many people using Drupal in a community media organizations understand the origins of many of the modules they use. Someone else likely configured it for them and it either works well for their needs and workflow or they adjust their needs to fit what the code does 'out of the box'. These are the organizations that are open source users. They have yet to embrace the difference between open source and commercial software beyond the idea of open source being something good.
As a user of Drupal and CiviCRM, you really aren't very different from a FinalCut user. The benefit of using open source over an Apple product is really lost if you don't know how to make a feature request, pool funds with other groups to get a new feature developed, or how to share what you've done on your website with other community media organizations. Like FinalCut, you just wait for the fix for a problem with Drupal or CiviCRM to appear in a future update.
When Manhattan Neighborhood Network (MNN) started the upgrade process from Drupal 4.7 solution to Drupal 7, I gave the other developers from CivicActions and Openflows working on the project a tour of how channelAustin was managing members, classes, equipment reservations, project proposals and show submissions. channelAustin was one of the original Open Media beta stations, but was never able to launch any of the self service functions in D6. Instead of pushing forward with modules designed to run a station a specific way, they invested in Drupal 7 and CiviCRM solutions to that could be customized to meet the requirements of their new franchise agreement. While channelAustin benefited from the code developed for the stations that had already launched Drupal 7 (PhillyCAM, BNN, and SPNN, etc), those stations hadn't engaged in the open collaboration the like beta 'partners'. So while there was a code base to build on, it was largely undocumented and lacked a community to provide any peer to peer support.
Luckily for everyone using CMDrupal today, channelAustin still believed that by communicating openly, sharing their code, and collaborating with other organizations to solve the problems they had in common, the resulting solutions would be greater than the time, effort, and financial investment any individual organization contributed. Even though the community that had developed around the Open Media dissolved, channelAustin kept the faith and continued contributing openly. When we started the MNN project, we started with the code developed with channelAustin. This was obviously a benefit to MNN, but channelAustin and other stations already using Drupal 7 would quickly see the benefits from sharing their contributions with MNN as well.
Some of the Drupal and CiviCRM modules worked for MNN 'out of the box', but because of MNN's size, organizational structure, and years of data in older versions of Drupal and CiviCRM, several new modules had to be developed and existing modules improved . Because these updates were building on the code other stations were already using, it was easy for them to test the initial changes and improvement coming from MNN.
CiviCRM Multiday Event is a great example of this virtuous cycle in action. While this need for multiday sessions was identified back in 2009, it wasn't until all of the work that's gone into Field Collections, FullCalendar JQuery plugin, and FullCalendar module that creating a solution became feasible at MUCH a lower cost than the $13K the CiviCRM team estimated it would cost.
MNN funded the development and testing of the first version of CiviCRM Multiday Event. That initial version was committed to Drupal.org and installed by channelAustin and AccessVision. After testing it, channelAustin requested a few features be added. One feature was support for the Color module and filtering events by type in the calendar view. Another feature request was support for custom CiviCRM fields. AccessVision merged CiviCRM Multiday Event with the Accordion View they'd already been using to display events. I took the View AccessVision developed and added a support for Color based on an Event Type taxonomy and added that as a submodule. To get custom fields working in event template, I had to patch CiviCRM's API. Each time an update was committed to Drupal.org, it was documented and added to the Moderate Starter Kit on Drupal.org adding to the modules ECAT manages in the Easy Kit and documentaiton AmherstMedia contributed. The patch to CiviCRM's API was included in the 4.2 release. Additional testing and contributions are now being made to CiviCRM Multiday Event from groups outside of the community media space including the Suffolk County Democrats.
All of these improvements to CiviCRM Multiday Event have already come back to MNN and are included in the Moderate and Difficult Starter Kits.
This virtuous cycle of building on work that's already been shared is happening again with CiviCRM Certify improving on CiviCRM Event Autogroup. @coderdan from Portland Community Media improved a module I originally developed for channelAustin. @synclayer found a few bugs while implementing testing this at MNN. Those bugs were fixed at the pre-NCMR sprint and rolled into the Difficult Starter Kit that both MNN and channelAustin use.
While it's true that these groups could have just sat back and waited for someone else to develop the features they wanted, these are all organizations that recognize the benefits of becoming an open source contributor over simply using open source. They share these attributes:
- They communicate both their successes and problems openly
- They use this open communication to identify shared needs
- They share their code before it's "done"
- They aren't trying to own the solutions or sell them as products
- They are openly giving credit to work others contribute
- They provide guidance to groups trying to adopt Drupal and CiviCRM at the easy, moderate, or difficult level
In an ideal world, the groups contributing will get far more back than they give as the community continues to grow… but that only works when new features and fixes are compatible with what was originally shared. The solution to keeping things compatible while allowing flexibility defined at the Community Media Drupal Summit in Austin was to create 3 starter kits.
Getting stations to adopt a Community Media Starter Kit at any level helps standardized the version of modules and provides a common core that helps reduces the cost and effort put into documentation and development as well as providing enough commonality that peer to peer support between stations is possible, but it also requires collaboration... and that takes time and it has to be a priority in every community media project that leverages this work. We are now WAY beyond, Station A use Drupal… Station B use Drupal… they should do something together. Getting both MNN and channelAustin both using the Difficult Starter Kit was a lot of work, but that work should benefit everyone using a kit at any level as new features are added and improved at every level. If we had waited until every feature both of these organizations wanted was "done", we'd just have several sites running Drupal. Because of the kits, updates and new features related to adaptive theming and site building flow up from the Easy to the Moderate and Difficult. More complicated solutions like CiviCRM Multiday Event and Certify start at the Difficult level and are pushed down to the Moderate level as they become stable and well documented. Currently Jason Daniels (ECAT), Mark Libkuman (Openflows), and I (A Little Help Hosting) manage the updates to the kits, but we'd welcome more involvement from anyone willing to contribute the time to understand the process.
The changes in Organic Groups between version 1.x and 2.x is the first real test of the starter kit approach. As MNN pushed forward with updates required for OG2, it broke many things designed to work with OG1. This has forced a conversation between MNN and channelAustin about how major version changes with modules need to be handled at the difficult kit level and what their collaboration will look like moving forward.
CiviCRM Multiday Event is now used by 65 sites. It is well documented and easy to implement for any station using the Moderate Level Starter Kit. Evolving that code into a module that works for so many organizations was only possible because we were building on a common layer. Without that, it is unlikely CiviCRM Multiday Event would exist beyond a custom configuration for MNN.
Without putting effort into maintaining the compatibility between stations, it is unlikely another solution like CiviCRM Multiday Event will evolve to the point it can be implemented by station staff (non-developers) at several stations... or put another way, it unlikely any new bills will become law.