One of the most common questions folks ask me when I tell them I'm the Product Manager for the OCLC Developer Network is "so what do you do?" I can understand this. The Developer Network is a relatively new endeavor for OCLC and it's not a product in the traditional sense.
Which makes people wonder why OCLC hired me and what it is that I do. Primarily my job is to help build a community of developers (library and non-library) around OCLC's Web services (present and future). So my title might be just as fitting as the "OCLC Developer Network Community Advocate," but since that wasn't available as a job title, "Product Manager" was the closest fit. So as the person within OCLC who is looking out for your needs as a developer, there are a variety of broad activities that I am tasked with:
- I do outreach to developers to teach them about the Web services, to get their comments and to try to make things better. Sometimes this means teaching actual workshops or putting together Web tutorials. Sometimes it's just one-on-one work, answering questions on the DevNet list [WC-DEVNET-L], Twitter, blogs, etc.
Dispelling misinformation and misconceptions about OCLC's Web services is another big part of job. I try to help folks get access and take feedback about when there are problems. There are two big things I'm learning that people don't know:
- First, nearly all the OCLC web services are in some fashion completely free to anyone for noncommercial use. Some have daily usage limits for anyone (like xISBN, xISSN), but others like the WorldCat Registry and WorldCat Identities have no usage limits whatsoever. Oh sure, the WorldCat Search API requires some qualification...but if you don't qualify for whatever reason, use the WorldCat Basic API. Or let us know what you're working on and make the case for why your app deserves access. (Never hurts to ask!)
- Second, OCLC Web services operate in a very beta mindset. There are advantages to this, like the ability to be responsive to requests for changes in a relatively speedy fashion. However, it also means that the Web services can occasionally be rough around the edges. This is especially true for the Experimental Services like Terminologies, Metadata Crosswalk, Dewey.info.
- I write lots and lots of documentation. It's pretty much impossible to have developers use your Web services without effectively documenting it. So one of my big tasks is to make the DevNet Web site better by adding more thorough documentation. Right now I'm working on documentation for the WorldCat Identities Web service.
Writing documentation also means engaging and interacting with the staff at OCLC who are more directly responsible for the Web services. I get to learn from the people who know them best, which is pretty darn cool. Right now I'm also learning about Linked Data from some folks in OCLC Research and a few external colleagues. It's interesting and challenging--I haven't figured out exactly what to do with it yet. What are you doing with Linked Data that the Developer Network can help support you on?
- I write demo code. There are lots of reasons for this. One is so I can answer questions and make suggestions to you, when you're using the Web services. Keeping my coder skills in shape is essential to serving you effectively. I also write demo code so that I have something to teach and present from.
Seeing real world examples makes a huge difference when presenting to others. I try to create demonstrations that show of the power of OCLC Web services and how they can be combined with data from other Web services. If you want to see the best of my demos in action, look for my presentation at code4lib 2010.
- I test web services (both OCLC and others) and provide feedback to develop new services from OCLC. Testing the Web services also puts me in the unique position of being able to evaluate the services before they are deployed--which means I get to critique and take a critical look and what works and doesn't work.
Case in point, the last two weeks I've been playing with the soon-to-come JSON output for the WorldCat Search API. I want to make sure it works for as many use cases I can think of, and that the structure is as simple as it can be while providing the most robust information. While some of my feedback is my own, based on my own experience working with the service and my knowledge of development and other web services, the most important feedback that I can pass along is that which comes from you, the members of the OCLC Developer Network. I need your input to help guide what comes next. Which is why getting feedback about service performance, methods of access, formats, data provided and its structure is important to my serving you and doing my job well....
All and all I have my hands full, but I wouldn't want it any other way.