eDitoriAl BoArD tHouGHts | DeHMlow 103 I n the age of the Internet, Google, and the nearly crushing proliferation of metadata, libraries have been struggling with how to maintain their relevance and survive in the face of shrinking budgets and misinformed questions about whether libraries still provide value. In case there was ever any question, the answer is “of course we do.” Still, an evolving environment and changing con- text has motivated us to rethink what we do and how we do it. Our response to the shifting environment has been to envision how libraries can provide the best value to our patrons despite an information ecosystem that duplicates (and to some extent replaces) services that have been a core part of our profession for ages. At the same time, we still have to deal with procedures for managing resources we acquire and license, and many of the systems and pro- cesses that have served us so well for so many years are not suitable for today’s environment. Many have talked about the need to invest in the distinctive services we provide and unique collections we have (e.g., preserving the world’s knowledge and digi- tizing our unique holdings) as a means to add value to libraries. There are many other ways libraries create value for our users, and one of the best is for us to respond to needs that are specific to our organizations and users— specialized services, focused collections, contextualized discovery, all integrated into environments in which our patrons work, such as course management systems, Google, etc. The library market has responded to many of our needs with ERMSs and next-generation resource management and discovery solutions. All of this is a good start, but like any solution that is designed to work for the greatest common denominator, they often leave a “desired functionality gap” because no one system can do everything for everyone, no development today can address all of the needs of tomorrow, and very rarely do all of the disparate systems integrate with each other. So where does that leave libraries? Well, every prob- lem is an opportunity, and there are two important areas that libraries can invest in to ensure that they progress at the same pace as technology, their users, and the mar- ket: open systems that have application programmer interfaces (APIs), and programmers. APIs are a means to access the data and functionality of our vended or open- source systems using a program as opposed to the default interface. APIs often take the shape of XML travelling in the same way that webpages do, accessed via a URL, but they also can be as complex as writing code in the same language as the base system, for example software devel- opment kits (SDKs). The key here is that APIs provide a way to work with the data in our systems, be they back- end inventory or front-end discovery interfaces, in ways that weren’t conceived by the software developers. This flexibility enables organizations to respond more rapidly to changing needs. No matter which side of the open- source/vended solution fence you sit on, openness needs to be a fundamental part of any decision process for any new system (or information service) to avoid being stifled by vendor or open-source developer priorities that don’t necessarily reflect your own. The second opportunity is perhaps the more diffi- cult one given the state of library budgets and that the resources that are needed to hire programmers are higher than most other library staff. But having local program- ming skills easily accessible will be vital to our ability to address our users’ specific needs and change our internal processes as we need to. I think it is good to have at least one technical person who comes from an industry outside of libraries. They bring knowledge that we don’t neces- sarily have and fresh perspectives on how we do things. If it is not possible to hire a programmer, I would encourage technology managers to look closely at their existing staff, locate those in the organization who are able to think outside of the box, and provide some time and space for them to grow their skill set. I am not so obtuse as to suggest that anyone can be programmer—like any skill it requires a general aptitude and a fundamental inter- est—but I am a self-taught developer who had a technical aptitude and an strong desire to learn new things, and I suspect that there are many underutilized staff in librar- ies that with a little encouragement, mentoring, and some new technical knowledge, could easily work with APIs and SDKs, thereby opening the door for organizations to be nimble and responsive to both internal and external needs. I recognize that with heavy demands it can be difficult to give up some of these highly valued people’s time, but the payoff is overwhelmingly worth it. These days I can only chuckle at the doomsday predictions about libraries and the death of our services— Google’s dominance in the search arena has never really made me worried that libraries would become irrelevant. We have too much that Google does not, specifically licensed content that our users desire, and we have rela- tionships with our users that Google will be incapable of having. I have confidence that what we have to offer will be valuable to our users for some time to come. However, it will take a willingness to evolve with our environment and to invest in skill sets that come at a premium even when it is difficult to do so. Mark Dehmlow Editorial Board Thoughts: Adding Value in the Internet Age— Libraries, Openness, and Programmers Mark Dehmlow (mdehmlow@nd.edu) is Digital Initiatives librar- ian, university of notre Dame, notre Dame, Indiana.