When developing services and applications for any organization, developers inevitably stumble across a desired feature that the chosen software package or framework does not handle well, if at all. If the software package is proprietary, maybe the vendor will add the feature in a release in a year or so, but probably not. If it's really needed, the developer will now have to write something from scratch that can hopefully integrate into the proprietary system, if that's even technically and legally possible.
Fortunately, many developers in the present era use open source software that can be modified to serve organizational needs. And each developer faces a choice in implementing the desired feature within the open source codebase: writing code specific to the current use case, or writing more generalized code that can be used again later by both the organization and others outside the organization that use the same software. Often, it’s easier and quicker to develop a custom solution to the problem, but that doesn't necessarily make it cheaper for either the developer or the organization...particularly in the long term.
One of the biggest debts incurred on any application is a reliance on customized solutions for features that could be generalized. And by generalizing features, allowing others to utilize and contribute to the work for their applications, both the organization and the developer ultimately reduce the amount of time and effort spent identifying and fixing issues, and integrating the features within the organization's applications.
Although built in the open source Content Management System (CMS) Drupal version 6, the previous version of the University of Michigan Library's Staff Intranet relied heavily on custom solutions to problems that might have been generalized. These customizations made the site difficult to update and prone to errors experienced by few others using the same CMS. When it came time to do a complete upgrade, we made a conscious decision to greatly reduce our reliance on custom solutions. In order to do this, we first looked at any similar solutions and worked to make them more complete and appropriate for our use case. But, because we were migrating to the newly released Drupal version 8, there were a number of features we needed that had not yet been created by anyone. So, we were forced to make choices. On some of our more specific features, we had to have some custom solutions, but these were considerably reduced in both scale and scope from the previous Intranet application. And when there were things that others would also need, we decided to create them and contribute back to the Drupal 8 CMS codebase.
The first such instance was the cosign module. Cosign is the single sign on for all of the University of Michigan and a module existed in Drupal versions 6 and 7 that allowed Cosign to integrate with Drupal’s native sign on. After reaching out to see if the maintainer was working on a Drupal 8 version of the module, we realized we needed to create it. We did so and released it for others at U-M to use and contribute to. Next, we needed to recreate the image selecting functionality utilized by our E-Card feature. This functionality had stalled in Drupal 8 core development, so we wrote our own and released it as a contributed module. As of June 3, 2017, it is used on over 500 sites. Finally, before we could launch we needed a select box for titles of items that were related to pieces of Documentation. We created a module for this and released it as well. It is used on over 50 sites as of the same date.
After we launched, a decision was made by the Library’s Intranet Committee to integrate the Policy and Documentation types. This could have been a case where doing a custom solution was appropriate, and we had modified our types using custom code during the initial migration. But since we had already done this once, and might need to do it again, we decided to instead create yet another Drupal module that would allow others to do this as well. Three more modules have since been released to facilitate the decision to make some Intranet content public. The modules bulk update content, so they are highly generalized and could be used for many other things. We may also work on integrating them with other projects in the near future.
Although some of the modules created at the U-M Library are not yet in wide use, developers from India, the Netherlands, Ukraine, Bangladesh, and the US are currently contributing code and testing to make the modules better. Likewise, we continue to test and contribute patches to other modules we use making those modules more stable and usable for everyone using them. This will inevitably help both our organization and others to expedite site development, add more features, facilitate smooth updates and reduce bugs.
Contributing to open source software reduces both our debt as well as others. It allows us to pool our resource investment in the software with the tens of thousands of other users of the same software. This model reduces both our time and resources, and benefits others who use the software as well. It can sometimes be difficult to work with others outside our organization. There are disagreements about how best to implement a feature or a particular piece of code. Features can sometimes take months to be implemented, during which time the developer is forced to patch any updates. But straying from the consensus and going it alone will inevitably lead us to toiling in isolation as the rest of the community moves in other directions. Working in isolation, we generate more work for ourselves and create debt for our organization. It therefore behooves us to be active and involved in consensus building with others from around the world. Ultimately, when we act unilaterally we generate debt for ourselves and our organization, while simultaneously depriving others of our contributions to a common goal.