In June 2009, Nathan Dickamore wrote an article on this site entitled “Participate in Community Development”. He wrote about open-source advocate Michael Tiemann's theories concerning "exonovation" and how community-driven (and supported) projects yield better products. Similarly, by using the community's time and talents, the Church can better tackle the monumental task of maintaining its legacy data systems, free up developer resources, and utilize the broad range of technical skills available in the larger community.
As an open-source advocate, Tiemann posits that more project contributors lead to fewer outstanding issues. As a software engineer for the LDS Church, I lead the maintenance efforts for a large number of applications within the Supply Chain portfolio. These applications use a diverse set of technologies and require a relatively broad skill set in order to maintain them. Resources are sometimes limited, and we find ourselves supporting and maintaining more products than a few developers can handle. Indeed, often a project’s needs are put on hold as other issues take priority. In addition, it seems that for every issue we resolve, the customer uncovers one or two bugs or makes enhancement requests. As maintenance developers, we sometimes find ourselves sinking as we do our best to keep maintenance applications happy while at the same time developing new software to meet additional needs.
Some of these maintained applications fall into the category of legacy applications. They include those using older and less enterprise-worthy technologies, such as Microsoft Access and Visual Basic 6.0. Understandably, these products now receive limited support and are often trumped by farther-reaching technologies using the Church's Java or .NET stacks. We often find it difficult to balance our time between newer and legacy applications, especially while these legacy systems await system rewrites that take advantage of later technologies.
In addition to freeing up developers' time to focus on other maintenance issues and new projects, utilizing the community's help in maintaining the Church's software would tap into a vast and deep vessel of technical knowledge. Few people employed at the Church would consider themselves Access or Visual Basic experts. While most developers can plunk along the scripting sea of VB or VBA, some are often lost and must delay helping customers while they seek solutions to old problems. Sometimes, these legacy systems stop working after Microsoft updates or OS upgrades. Much time is spent helping these applications limp along until more robust software takes their place. In the meantime, Church developers often realize how much of the original developers' knowledge is lost or forgotten. Thus, these applications are not as effectively or efficiently maintained, especially when a select few are proficient enough to work with the older technologies.
By following Dickamore's thoughts about using community-supported development at the Church, we can solve many of the problems maintenance developers face, especially insufficient resources and lack of breadth of knowledge to meet dynamic and diverse needs. The community of LDS Church members who wish to aid the Church through community-driven software projects is growing. Community members are already compiling a list of feature requests and bug reports. Often such requests and reports are accompanied by suggestions and even offers to volunteer time. It makes sense to open the doors for community support of legacy applications.
By involving the larger community, as Dickamore and Tiemann suggest, we would be better positioned to pool the large number of developers required to stay on top of maintenance tasks, minimize the number of oustanding issues, and have access to a broad reservoir of resources with which to tackle any problem.