by Terry Reese

Introduction

The role of the developer–and attitude toward open-source in general–has changed a lot within the library community over the last ten years. While libraries have always had individuals writing code and building tools, this work has predominately been relegated to the fringes of library research or hidden away within the technical services and systems communities wrangling with MARC and library management systems. And while MARC and library management systems haven’t gone away, development activities have become an integral part of the library and have gained acceptance as both fertile ground for library research and a necessary component of a successful library. In many respects, I think that this will be one of the most enduring legacies of the Code4Lib movement; legitimizing the work developers do to the library community. Developers and open-source software no longer flummox the vast majority of library administrators, who now see development opportunities as areas for research, collaboration and innovation. Libraries, in large part, have taken on large development projects and encouraged developers to think innovatively and experiment liberally. Unshackled, developers have worked to re-engineer the library, and in the process are actively sharing their code, expertise and experiments within the wider library community. What’s more, as libraries continue to evolve, more and more of their critical workflows and systems will be developed utilizing components or tools created in and around the Code4Lib community.

However, in the midst of this sea change within libraries, it is important to consider the long-term ramifications for developers as we move forward. For every library technologist or developer hoping to create the next big thing, there is the underlying question of how a successful development project may impact that developer or their organization. And what’s more, if a project is really successful, how does the developer or host institution determine their long-term responsibilities to a particular community or project? Is it enough for a developer to simply open-source his/her work or is there a larger responsibility to provide the necessary “care and feeding” to the communities that they help to establish? These are difficult questions with few “right” answers because they represent large opportunity costs. However, as libraries become more reliant on the larger library development community to provide shared workflow solutions, it becomes even more incumbent on library developers to think critically about the long-term impact a project may have, both for themselves and the larger development community. While every developer hopes to build a successful project, few are prepared for the community entanglements and the long-term hold these projects can have on a developer’s career.

The privilege of software development

It is sometimes easy to forget that being a developer is a privilege. We spend our days negotiating with unfriendly systems and archaic data models. We find ourselves needing to be licensing experts as we search for components, libraries and building blocks from which to build our work. These every-day issues can make one feel like Sisyphus, forever pushing against the mundane tasks that interrupt the development process. But the reality is that as developers, we create things–very cool things that people count on and come to rely on. Whether intentional or accidental, people become developers because they have the opportunity to take those things that they imagine, and make them real. It is a privilege because “we collectively are given the opportunity to create things that matter: to individuals, to teams, to organizations, to countries, to our civilization. We have the honor of delivering the stuff of pure intellectual effort that can heal, serve, entertain, connect, and liberate, freeing the human spirit to pursue those activities that are purely and uniquely human” (Booch, 2004).

We are at our best when the work that we create transparently enables the user to make connections and meet their needs. Users become co-developers, not through the writing of code, but through the interactions between the developer and the community. Within the Code4Lib community, we tend to think of our work as being about the code, but in reality, that is just a very small part of a project. Users tend to provide the vision, the context that enables developers to find problems and solve them. Through our work, the user and developer form a symbiotic relationship allowing the developer and user the ability to imagine new ways to interact with the world. And because of this relationship with the user, the privilege of software development also comes with a responsibility. Within the Code4Lib and library communities, we have done a very good job of thinking creatively and pushing innovative approaches to these larger problems. We continue to encourage library developers to think differently about the library, to reimagine workflows and what it means to be a library in the 21st century. And yet, we tend not to think about the long-term responsibilities developers and organizations will have to the user communities that spring up around these new innovations and research. As the Code4Lib and library development communities continue to move libraries in new directions, these communities need to engage in a new discussion; one around the idea of more responsible development that requires developers to consider not just the life-cycle of their project, but also the long-term stewardship of their creations and the user communities that spring up around them. Developers need to be prepared to fulfill their responsibilities to their work and can do so by planning not just for a successful development, but for accidental success as well.

What if you succeed?

When starting a “hobby” or experimental project, few people expect for it to fail, but even fewer plan for it to succeed. When one thinks about it, that’s really not all that surprising since most “hobby” development within the library community starts out as a tool to meet a local need. If we looked around our own institutions, nearly everyone could find one project that would meet this description. These projects serve vital needs within our organizations and often times do such a good job, that they become viral within our communities as well. Through word of mouth, these tools spread outside of our organizations, taking on a life of their own and, intentionally or not, binding an organization and developer to supporting a particular tool set.

I have had some experience with this kind of accidental success. In 1999, I started writing a small MARC-based set of code libraries as a way to learn how to understand the MARC format. Because these tools ended up having a significant impact at Oregon State University, I was encouraged and cajoled to release what would become MarcEdit. When MarcEdit (http://people.oregonstate.edu/~reeset/marcedit/) was first made available, I had no idea at the time how quickly the tool would become as successful as it has, nor did I understand the size and scope of the community that would develop around it. In the 12 years since I first released MarcEdit, the application has become a well-used utility for manipulating library metadata. It has been written about and cited in a number of books and articles, and has become in many organizations a critical part of their metadata workflows.

For my part, the program has become both a vehicle for experimentation and research; and a never-ending stream of support questions from the user community. As a group, developers tend to underestimate the time necessary to answer questions related to their work. Like most, I had made the assumption that the “web” would shoulder the lion’s share of the support requests, while in reality, developers or their organizations need to make some hard decisions related to the amount of support that they are willing to provide. Even today, I still receive 20-25 personal requests a week for support or assistance with a metadata project, which has a real opportunity cost in relationship to my time as a developer to do new and creative work for the community.

For the first time in 2011, I tried to get a handle on the size and scope of the current MarcEdit user community. Utilizing MarcEdit’s automatic updating feature, I was able to capture access log statistics representing an active usage of the program. What I found was surprising – taking just the first million executions over the last year, I could see that MarcEdit had been actively used in over 143 countries/jurisdictions. What’s more, breaking down the active user community, nearly half of all usage from the tool came from outside of the United States.

ISO Code	Country	Total Uses
US	United States	619,884
CA	Canada	103,558
AU	Australia	47,916
GB	United Kingdom	34,004
ES	Spain	24,402
TW	Taiwan	18,816
HK	Hong Kong	17,740
SG	Singapore	14,818
IN	India	12,022
MX	Mexico	10,386
IT	Italy	9,344
PK	Pakistan	9,230
MY	Malaysia	8,842
FR	France	8,826
DE	Germany	7,174

Table 1. Top 15 Countries by Usage

While I have long suspected that MarcEdit had a substantial user community, I had no idea that it had grown to represent such a diverse set of the library community. Without meaning to, I’d managed to create something that a large number of people were finding useful in their daily work. However, this success also raised questions related to my long-term responsibility to the MarcEdit community. As the sole developer of MarcEdit, what are the long-term responsibilities to provide support, project stewardship and succession planning of the application – and does a user community have the right to expect this level of support? These are important questions for any member of the code4lib (and larger library development community) as more and more community driven development is becoming critically embedded within the library. How we steward our work now and ensure its long-term success will continue to play a very important role in how the library community views and ultimately relies upon the development community.

The responsibilities of software development

If you accept that being a software developer is a privilege, then it is equally true that software development comes with a set of responsibilities. The unwritten contract between the user and developer underscores certain expectations related to support, stewardship and longevity – expectations that many developers may not fully consider when building a user community. What’s more, some developers may indeed view the idea of stewardship as out of scope for their particular work or project.

Within the Code4Lib community, it’s very common for developers to believe that releasing their tools as open-source fulfills the stewardship contract with their users. From a developer’s perspective, making the source code available ensures that someone, down the road, will have the ability to pick up the project and continue development. For some projects, this type of foster care approach to software development may make sense – especially if the project in question never succeeded in growing its user community. However, projects developed at libraries tend to spread virally. Developers or users attend conferences, they write articles–word gets out and very quickly these projects become embedded in best practices and workflows at other organizations. These projects require much more “care and feeding” and for the developer or organization actively seeking to build a community, a great deal more should be expected than simply releasing the source code for a project.

Stewardship of Open-Source Projects

Over the years, library administrators have become much more comfortable relying on open-source projects. At the same time, very few within the library community could be considered good open-source citizens. (Intridea, 2011) While libraries have generally become much less resistant to using open-source tools and projects, very few actually contribute anything back to those projects. There are obviously exceptions, like the DSpace effort, that have had success building robust user and development communities around open-source projects. However, engendering this level of involvement and ownership in a project doesn’t happen by accident. The DSpace community, for example, was created through a very intentional development process. Securing funding to seed and support a user community, MIT worked with a number of early partners to advocate for the long-term health of the project. As the project has grown, MIT has been able to step aside and become a participant in the larger DSpace community, while handing off the project to a new set of maintainers. However, MIT’s experience in growing the DSpace community is atypical within the library community. In most cases, developers or organizations may be able to build user communities, but struggle to create the thriving developer community needed to relinquish stewardship of a project.

For example, Oregon State University Libraries (OSUL) developed an open-source content management system for librarians called Library à la Carte, to support the development of course guides, subject guides, portal pages and modules. OSUL sought to develop the project to provide libraries with a more flexible tool kit than found in existing products like LibGuides, as well as providing a framework for librarians to think innovatively about how they connect to users. By most metrics, the project has been successful building a community of users and pioneering a number of user oriented innovations. Likewise, OSUL has actively pursued a plan to enable libraries to utilize this project, providing support and continued ongoing development. However, while building a user community has proved to be somewhat successful, encouraging the growth of a developer community has proved elusive. While OSUL has engaged in training, hosted impromptu user groups at national conferences, and even for a brief period offered a hosting service for a limited number of partners, an active developer community never formed around the software. For OSUL, this means that support for the project continues to be shouldered solely by the Libraries, which does incur opportunity costs.

The experience OSUL has had is probably much more typical of development projects within the library world. The issue then becomes what role or responsibility does the developer/organization have for long-term stewardship of a project. In the case of Library à la Carte, OSUL encouraged the development of a user community and now feels a deep obligation to that community, making decisions about the Library à la Carte program much more difficult.

So what should developers do? As developers and organizations seek to make their open-source projects available, they should plan not only for success of the projects but include the long-term stewardship of their project as part of the development life-cycle. Project developers should consider the following:

Have clear community goals and a plan of action to reach them

Many projects flounder because of the belief that a vibrant user community will equate to a vibrant developer community–it doesn’t. Just like user communities, projects looking to birth and support a strong development community require purposeful action. It’s not a coincidence that projects that make a priority to support developers and actively court their participation throughout the project lifecycle engender the most community support. At OSUL, this was probably the biggest single miscalculation that was made when promoting Library à la Carte, assuming a vibrant development community would spring out of the existing user community. In reality, these two groups have different needs and oftentimes will not be made up of the same principle players. By not having a clear plan of action, OSUL was able to build user interest in the project, but to this day, has never been able to generate the same interest from within the developer community. What’s more, given the rapid rate of technological change, most projects have a narrow window to make those connections–missing that window will result in a missed opportunity and ultimately will make community building more difficult in the future.

Determine if you can provide support

One of the least transparent processes within the library development community surrounds the topic of support. Developers need to be exceedingly clear what type of support will be provided and for how long. Invariably, questions related to enhancements, system requirements, component incompatibilities, updates or simple troubleshooting will need to be addressed. When a project or tool is first released, developers will often times go to great lengths to provide support for their work. While this will certainly help to build a user community, it also raises false expectations. Users that come to rely on a tool or service may continue to require a high level of hand holding, making long-term support more difficult as a project attracts more users. Developers or their institutions need to be fully transparent to potential users regarding the support that they can provide, as well as their own expectations of the user community. While it would be naïve to expect a large number of project users to contribute code back to the project, there are many other tasks in which members of a user community can participate. Supporting documentation efforts, creating support groups, financially supporting the development efforts of a developer or host institution – the ability to contribute to a project go far beyond just contributing code back to a project, and all ultimately help determine a projects long-term success. Likewise, users themselves will need to understand support expectations so that they can make informed decisions regarding a project’s fit for their institution.

Provide a development roadmap

One of the benefits of an open-source project is that the source code is always transparent to the user, even if the user is unable to do anything with it. Just as important to source-code transparency is the accompanying development roadmap. While few users will actually contribute code back to a project, the presence of a clear development road map tends to encourage community members to seek out ways in which they can support a project. Users that understand and have confidence in the development process have a much greater incentive to become active project participants as testers, documenters or simply providing valuable feedback relating to functionality. Given the rapid rate of change facing libraries, projects actively seeking adoption by other institutions have a responsibility to provide a clear development path and goals. This allows their users the ability to understand and mitigate changes to a tool or project without impacting critical services.

Have a clear exit strategy for developers

Projects rarely last forever. At some point, developers and organizations move on. Like any project, open-source projects need to have a succession plan in place. For projects that are successful at building strong developer and user communities, the continued stewardship of a project or tool can generally be transferred directly to the community. DSpace and Koha are great examples of projects started by a set of institutions that successfully transferred stewardship to another entity [1]. Given the fluid nature of many open-source projects, developers need to be especially clear when detailing the life-cycle of a tool or project and need to be realistic about their overall interest and capacity to provide long-term support. Developers need to engage in responsible development, considering not only their own finite resources, but also the community of users that they have worked to create.

Have a clear exit strategy for users

Libraries insist upon exit strategies from vended projects, and should hold open-source developers to the same standard, requiring projects that provide polished exit strategies. While it is true that users of open-source projects or tools always have access to their underlying data, it is unrealistic to expect a project’s users to develop their own methodologies to extract and repack their data when a project is abandoned. Developers and their institutions have an ongoing obligation to those user communities through the total life-cycle of their projects.

Building new tools and making the source code available to the larger library community is an exciting time. For new developers, promoting and seeing your work make a difference is always a thrill. However, taking the time to consider the long-term stewardship of your project will not only make the overall project experience a better one, but builds trust within the larger library community by demonstrating an understanding of the long-term implications of making your work available.

Stewardship of Closed-Source Projects

While the topic of closed-source projects tends to rarely come up for discussion within the Code4Lib community, a developer or institution may have very good reasons for keeping the source code for a project closed and outside of the public domain. Sometimes these reasons are related to remuneration, sometimes due to organizational concerns and, more often I think, because the project represents a hobby or an itch that a particular developer wishes to scratch. And while many in the Code4Lib community tend to discourage the closed-source model, the library world is full of examples of closed-source projects that have made and continue to make significant contributions to the field. While open-source tools continue to become more ubiquitous, the software that drives the library at the enterprise level still largely remains closed-source. Many tools like EZproxy, ILLiad and CONTENTdm started out as resource projects only to grow into much larger development efforts, while others come from large system vendors or boutique software developers that create tools like BookWhere and MARC Magician. These tools and systems play an important role in the library software ecosystem, enriching the community and facilitating innovation [2]. However, for developers choosing a closed-source model, considering at the very beginning their responsibilities to their user community becomes even more important. While open source project maintainers need to consider their roles as stewards, the fact remains that the source code is available and open for further development. If a project is dropped, it may languish and fall into disrepair, but if an organization has sufficient need, they can revive the project and continue its development given enough time and resources. Closed-source projects are very different, in that the user communities that build up around them are completely dependent upon the project maintainer to continue to support and improve the product.

MarcEdit is another example of a product within the library community that follows a closed-source development model. I’ve been asked a number of times throughout the years why I haven’t open-sourced the application since I participate in and have lead a number of other open-source projects. I think sometimes people may believe that MarcEdit remains closed due to some bureaucratic wrangling with Oregon State University (OSU), rather than a choice that I purposely have made regarding the development process. I’m sure that some people within the Code4Lib community may have experience with this type of bureaucratic nonsense, but this has not been my experience at OSU. No, in my case, I have decided to keep MarcEdit closed because I have a very personal connection to the software–developing it has been a passion of mine for almost 13 years now and one that I selfishly keep to myself. However, in doing so, I understand that I have very specific responsibilities to the user community who have come to view the project as a necessary part of many organization’s technical services workflows.

When considering the stewardship of a closed-source application, one should consider all of the questions that relate to open-source development. In addition to those initial questions, maintaining a closed-source application requires careful consideration of some additional issues due to the closed nature of the project:

Provide a transparent and well-defined enhancement process

Unlike open-source software which thrives on communities of users that are also good open-source citizens and contribute back to the development, closed-source software generally employs a user feedback model. This doesn’t mean that community members of closed-source projects are passive participants. Actually, it can be quite the opposite as communities built around closed-source projects must proactively work with the developers to ensure that community needs remain a development priority. Like open source projects, community members can and should play an active role in helping to support the user community. At the same time, developers of closed-source projects and the user communities that build up around them often are insulated from each other. This is a challenge for both users and developers because the developer is for all intents and purposes the bottle-neck within this model. With only so many resources, developers must strive to provide their user communities with a well-defined enhancement process and issue tracking system to engender transparency in the development process. Like open-source projects, project roadmaps are vitally important to provide transparency to the development process and provide a way to interact with the user community. One of the dangers for developers of closed-source projects is the potential to become out of touch with the user community. Developers of these projects must remain vigilant to maintain the lines of communication and encourage active participation in the enhancement and testing process.

Determine who will provide support

Like all projects, one of the primary success drivers for a closed-source project is the level of support provided to the user community. While open-source support tends to be provided through the project community at large, closed-source projects are disadvantaged in that support must come directly from the software developers. For large enterprise development efforts, support is often funded through fees that libraries pay for the software. However, for hobby projects or boutique development efforts, the path to providing support oftentimes isn’t as clear-cut since time spent on support is ultimately time spend away from working on the project. How that support is offered can vary greatly, but users are much more vulnerable to support issues when working with a closed-source project because their ability to troubleshoot issues on their own is often limited by the software. At the same time, an active user community can be a boon for a closed-source project, as it engenders a sense of ownership in the work, as well as providing functional experts that can be utilized for both testing and feedback.

In the nearly 13 years of developing MarcEdit, I had seen the number of support requests being forwarded to me topping over a hundred a day. Questions would often be repeated, but answering each question individually eventually begins to take its toll. A developer looking to go the closed-source route need to understand that providing support for a project is the single most time consuming aspect of the development. The project’s user community must become a support resource, through the use of Listservs or forums to allow the user community to participate in the support process. This allows users to gain a sense of ownership of the project, while freeing the developer to spend more time developing the project. In my own experience with MarcEdit, providing the user community with a public Listserv to ask support questions has been a boon to the community. What’s more, the Listserv has helped to identify who within the user community has specific knowledge of relevant workflow specific tasks. This has given me a set of experts to query when discussing new functionality, and has given the user community more depth and a different type of available support.

Escrow the code

Because close-sourced projects don’t make the source-code available to the public, project maintainers must take special precautions to ensure that the source-code remains secure and accessible. This is especially true of single developer projects, where one coder may have the only copy of a project’s source. For developers looking to build a user community around their closed-sourced projects, it is the developer’s responsibility to detail the steps taken to preserve the source-code so that it can survive beyond the project team.

Again, with MarcEdit, this scenario nearly played out in the summer of 2010 when I was hit by a car on my bike. Since MarcEdit is a closed-source application, many people began to wonder what would happen to the project if the sole developer suddenly disappeared. This is a very valid question and concern. It’s been my experience that unattended software tends to have a short shelf-life; with its applicability depreciating the longer it remains idle due to software defects, standard changes or changes within the software’s system ecosystem. For developers looking to build closed-source systems, one important decision that needs to be made and documented is how the source-code will be escrowed for future developers. For years, MarcEdit’s source-code has been escrowed on two independent remote systems, accessible by two or three (it varies) other individuals besides myself. These escrowed copies act as insurance policy of sorts for the user community that the project could survive beyond any individual developer of the project.

Develop a succession plan

In addition to the escrowing of code, closed-source developers must also plan from the very beginning how the project will succeed without them. Succession planning is a necessary obligation for a developer to undertake to ensure that the project can continue to be maintained when the developer finally wants to move on to something else. Fortunately, there are a number of available options, from deciding to open-source the code and encouraging interested members in the existing user community to take up the development of the project to appointing a new project developer. Additionally, closed-source projects featuring a single developer should take additional steps beyond escrowing the project’s code, including considering how to support emergency succession of a project. In my case, this is something that I have long neglected in my own succession planning in regards to MarcEdit. While those that can access the escrowed code have the ability to continue the project, I’m not sure they would want to take over long-term development of the project. However, closed-source developers have an obligation to their user communities to give a lot of thought to the life-cycle of their projects and work to ensure that their role as the developer is ultimately expendable.

As one can see, developing a closed-source project places a number of new and unique obligations on a developer. This is one of the costs for keeping the source-code of an application closed. As I have found working with MarcEdit, there are tradeoffs going this route, and one of these tradeoffs is the added responsibilities to the user community. Whether I want to or not, I’m wedded to the MarcEdit user community because of the decision to close the project code. Developers looking to follow this same path need to realize that this decision comes with many obligations that cannot be easily untangled once a user community develops around a specific project or application.

Conclusion

The negotiation between the developer and their user community can be a very personal thing. However, as the Code4Lib and library developer communities continue to mature and play a more important role in determining the direction of libraries in the 21st century, we also need to remember what great privilege it is to be a developer. We have the ability to break down barriers, build connections and help individuals make new discoveries. It really is a privilege, but it also comes with an obligation to think beyond our immediate involvement in the work and consider how we will steward a project throughout its life-cycle. It’s an important discussion developers need to have with each other, as well as at their institutions, if libraries are going to continue supporting and encouraging an active development community.

About the Author

Terry Reese is the Gray Family Chair for Innovative Library Services at Oregon State University (OSU) overseeing the development and implementation of new strategic initiatives for the Libraries. He is the author of a number of metadata related software packages and libraries like MarcEdit, a MARC/XML metadata software suite and the C# OAI Harvesting package. He is a regular requested speaker and has published a number of works on digital libraries and library metadata issues, including co-authoring a book with Kyle Banerjee entitled, Building Digital Libraries: a how-to-do-it manual (http://www.amazon.com/Building-Digital-Libraries-How-do/dp/1555706177/).

Personal Homepage: http://people.oregonstate.edu/~reeset/

Notes

[1] While the current controversy surrounding the Koha project would seem to indicate otherwise, I believe that it actually demonstrates how successful this project has been at diversifying its community. Koha has been so successful, that the project has been able to survive not only being forked, but has seen both forks flourish. Real issues exist between the two communities, but I think that this group still represents a great example of how a project can be transferred to a community (as well demonstrating some of the potential issues that can arise when community members philosophically differ).

[2] I know many will argue that many closed-source tools have traditionally impeded libraries from innovating, but I think that attitude is naïve. While many enterprise system in the library community have admittedly provided less than stellar support to extend their systems beyond their scope, it’s unfair to not recognize the work these groups have also done developing tools like electronic resource management systems and supporting OpenURL development and support.

References

Booch, G. (2004). The privilege and responsibility of software development. Retrieved 11 18, 2011, from http://www.ibm.com/developerworks/rational/library/2101.html

Intridea. (2011). 10 Tips For Open Source Citizens. Retrieved 11 02, 2011, from http://intridea.com/2011/8/11/10-tips-for-open-source-citizens