Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
After Chris Barr forwarded my message from NGC4LIB, I signed onto this list so I could see any replies. A bit of response latency, then, but I do want to react to what Carl Grant wrote. He made some very pertinent points and I think he's right on many points. To some degree, we are coming at the same question from different directions and with complmentary solutions. I am aware of the emerging breed of commercial players offering support services for open source applications in libraries, and I am very happy to see them in the library technology eco-system. At least one of those companies (LibLime) is working with Palinet (my regional network) to provide implementation and support options for open source in libraries without local means to take on those tasks. That is great. Such companies will clearly occupy a very important niche if open source applications are going to become mainstream / widely adopted solutions in libraries. Let me stress that I am not against for-profit private sector ventures in this arena by any means. They will be essential, long term, to make open source alternatives viable for many libraries. But what I was trying to describe was a landlocked resource pool within libraries right now, in terms of software support funds and technical talent, that could potentially be liberated to flow in the direction of cooperative / collaborative development work that is not concentrated in a relatively few commercial nodes but that is instead molecular and broadly participative. I think such a movement needs to start in those libraries with the means to put technical staff at work on developing applications, using lightweight, open tools and the sorts of web services approaches elsewhere advocated on this forum. I envision something rather more consortial than corporate in this regard. If I wanted a drop-in in one-size solution for resource discovery, from a corporate supplier, for instance, I'd have to say that WorldCat local looks pretty darn interesting. But the kind of locally-iterable, modular, extensible toolkit that I think positions libraries well for experimentation and innovation requires lots of talent in lots of places trying little things and somehow developing a vetting process that streams the best stuff into regular releases of continually evolving software. I laud Evergreen to the skies, but (unless I am poorly informed) I believe that commit-level access to the source code is pretty much in-house at the moment. Which means that incremental changes and innovative extensions in local settings won't automatically flow into the mainstream release. Whatever the case, I'd be the first one in line to argue than the Evergreen model is better than the closed-shop offerings of current library software vendors. I know that I am speaking to the converted here, but I am trying to describe a network effect transformation of our technical infrastructure that involves more than only the re-direction of our software support funds to a commercial supply chain for open source applications. That commercial supply chain is important and it will grow as our collective investment in legacy library vendors erodes over the next 3-5 years. But I think what happens in our local settings (as we re-think what libraries do and what the work of library staff ought to be) is at least equally important. What if a 150 good library developers really were to be working collectively on a suite of library tools using a shared modular architecture? That is fundamentally different from the supplier model that would work for a core portion of the library software market that requires certainty security. But in contexts where rapid innovation is privileged and supported, the new collaborative development environment would be a huge boon. I think that such a migration of creativity from product-oriented contexts (i.e. here's fixed deliverable a firm can install, support, and enhance, for you, the customer) to a shared risk / shared advantage cooperative would enable us all to be more experimental and to garner the results of those experiments more quickly. OK, maybe I'm being naive and overly optimistic. Before I close, though, I want to re-state one theme from my earlier musings: libraries are by their very nature cooperative entities. Our regional consortia provide ideal venues for experiments in coalition building around open source application support for those of use who are looking to do more than contract for services from CARE, LibLime, etc. Those consortia are business operations, non-profit, but commercial, and their business environment is changing as well, as OCLC repositions itself in the networked information landscape. They (the regional networks), too, are looking for new business lines and new opportunities. I suppose at some level I am saying let's create new cooperative contexts as the largest legacy cooperative we have, OCLC, begins to operate more like
Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
For some more background/ideas that might be useful in this conversation, just in case you haven't seen it, I highly recommend reading: www.ithaka.org/strategic-services/oss/oss-organization-for-open- source-software-study I found this a fascinating paper and while it's over a year old now and I personally question some of the conclusions, overall, it remains excellent reading for participants in this thread. Sincerely, Carl Carl Grant CARE Affiliates www.care-affiliates.com
Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
I agree with Jonathan's points below, and would suggest that a robust enough WorldCat API should be sufficient to allow any library that has the desire and the capacity to integrate everything available there with whatever else they wish. Roy On 11/9/07 9:42 AM, Jonathan Rochkind [EMAIL PROTECTED] wrote: Good points. If I wanted a drop-in in one-size solution for resource discovery, from a corporate supplier, for instance, I'd have to say that WorldCat local looks pretty darn interesting. But the kind of locally-iterable, modular, extensible toolkit that I think positions libraries well for experimentation and innovation. There's another important reason this kind of locally-iterable modular extensible toolkit is absolutely vital, in addition to positioning libraries well for experimentation and innovation. It's because we absolutely need to functionally integrate our various _different_ products from differnet vendors. Even if you go with WorldCat Local, you still have many products from other vendors that you'd really like it to integrate with (both on the end-user-interface, and on the backend staff metadata control and other interfaces). The path to accomplishing this is with that kind of modular extensible toolkit---dropping in an ostensible one-size solution often only creates more problems with lack of integration. We want loosely coupled, but we're currently often stuck with not coupled at all, which causes no end of problems. Jonathan Joe Lucia wrote: --
Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
On 11/9/07 11:24 AM, Joseph Lucia [EMAIL PROTECTED] wrote: At the recent OCLC Members Council meeting there was some strong support voiced from the floor during OCLC management's general presentation for such an API, but it is not clear where OCLC stands on the matter. The answers from OCLC officers about this were hedgy, though they hinted at some sort of development in progress. Others may know more. They (OCLC) are clearly focused on the market position of WorldCat Local and a robust and extensive API might undercut that -- but probably only with one market sector. We need to keep pressing the issue. * Joe Lucia University Librarian Villanova University 610-519-4290 Note that this is also a governance issue. Members Council is advisory, except for appointing six of the fifteen trustees; the remaining nine are self-appointed, and include the president of OCLC. Like many organizations, OCLC is struggling with its own issues of sharing and trust (I consider the recent, very excellent OCLC report to be on some level an unconscious roman a clef). OCLC throwing small bones such as we might make an API available while clearly not actually *doing* this is one reason why even people fully committed in principle to the idea of a global networked catalog--on paper, the *only* sensible model--remain a bit coy about throwing their hat into the WC Local ring. I do understand OCLC's fear--let go of the goods, and OCLC will cannibalize its own revenue stream--but I think they're greatly underestimating the extent to which they are a service, not a data, provider. I hope this isn't read as too critical. Many library organizations are struggling with similar change issues. Just wanted to bring up some of hte organizational complexities underlying decision-making. K.G. Schneider [EMAIL PROTECTED]
Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
Alexander: I don't think you're dreaming at all. Sounds like the same vision I know several OSS service firms are trying to pursue. Not to be self serving here (really, anyone who knows me will tell you that's not my style!), but in the spirit of making sure you are aware, I'll note the following: When CARE partnered with Index Data as our strategic partner, the support of Web Services was one of the criteria that we required and found in that partner. Index Data uses Web Services throughout their products.We'll be announcing other partnerships in the months ahead, and that criteria is a continuing requirement that we've found others in the open source service/development community are meeting (and by the way, using REST!). I would also note that we have some beginning recommendations for standardized Web Services practices as a result of the work of NISO (for which I'm the immediate Past Chair and James Neal is the current Chair). But in case you're not aware of it, please look at: NISO RP-2006-01, Best Practices for Designing Web Services in the Library Context (available at www.niso.org). I know NISO would welcome more work in this area if the market is willing to pitch in and help sponsor it. * Get some outside experts in to handle usability and interaction design, and open source the result. Create a consortium or interest-group for library systems usability and user experience. Again, here we totally agree. If you look at the About Us page of CARE Affiliates webpage, you'll see one member of our organization is Ezra Schwartz, whose resume in this area is pretty impressive. We've only begun to work out how his contributions will contribute moving forward, but we already know we're planning on Ezra being at ALA, in the Open Solutions booth (where you'll find CARE, Index Data and Liblime) area and we're planning on his making presentations about this very topic. If libraries are willing to put resources into work in this area, Ezra is ready to go. * Make sure we've got a *clean* cut of technology between business logic and the user interface. Enforce low-key semantically-rich XHTML and use CSS everywhere. The first major product we've pushed out with Index Data is MasterKey, which is a perfect example of what you're talking about here. A total division of the technology between the business logic and the user interface can be found in this product. Dreaming? Not at all. Like I said, we're out here and we're doing it because we share in the vision and we believe this is what the market wants. If people vote with their resources and back us, Index Data and LibLime we'll deliver more of the same. But I want to underscore the importance of what you said about how important that backing is. Everyone of the open source firms that'll be in the Open Solutions booth at ALA are, to the best of my knowledge, being financed solely by the company founders. This is specifically because these people don't want to be pulled away from their customer focus, their desire to do what they believe the market wants and needs. They don't want to be dictated to by large equity investors, venture capitalists or others who are, it seems these days, looking more for financial return than doing what is right for the customers. Until such time as those kind of money people remember that the way to make money is to treat the customer right, then we'll continue to grow through self-financing which means we'll grow slowly, organically and by hoping those that think we're right, back us by buying from us. We watched and admired all of you get the OSS movement underway and we believed the market needed companies like ours to take your ideas and software to the next level. We are certainly hoping and betting a lot, that we're right. Now it's time for the market to vote. Carl CARE Affiliates www.care-affilates.com
Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]
Hiya, On Nov 9, 2007 7:42 AM, Carl Grant [EMAIL PROTECTED] wrote: I'm seeking some help understanding here. From my perspective (again, that of a long time vendor of commercial software having recently moved to commercial service for OSS software) this is exactly what a number of us (LibLime, Evergreen, Index Data, CARE Affiliates) are *trying* to do. We're not only providing the services to allow libraries to adopt open source, we're also doing the marketing and selling that libraries seem to require before they'll even consider the option. I think this is extremely important for the library world right now, far more important than any current standard, model or prototyping exercise ; support the vendors going Open Source. Don't think about it for too long ; we must grab this opportunity *at all cost*, because, frankly, it's the only chance we've got to set ourselves straight again. The only way to get away from the suppressed and locked-down legacy-driven world we currently live in is to embrace openness, especially when it's coming from vendors (who's by that very token asking us to work *with* them this time instead of just buying their stuff). There's a slight clause here, though, for the vendors ; you *must* adopt web services for *every* part of your solutions. I know that this often goes against the grain of a proposed system (a system that holistically solves a problem space) but the truth of the matter is that you will never make your system work spot on for everyone, and we need the reassurance (even if we never use the option) of going in a different direction or using someone else's solution for a particular problem. By allowing a more open development model the library world will love you and gladly give you money for support and further development. Consider the openness even a token more than a reality option. Here's a quick list of things I see crucially happening ; * The library world has to come together to create a common language for these web services, an ontology if you will. We must decide on a few good (and possibly already existing) protocols and dictionaries. * Vendors must settle on a development model for web services (and I'd humbly suggest a REST model) and not be afraid of opening up or segmenting their holistic solutions into sharable / interchangeable parts. * Get some outside experts in to handle usability and interaction design, and open source the result. Create a consortium or interest-group for library systems usability and user experience. * Make sure we've got a *clean* cut of technology between business logic and the user interface. Enforce low-key semantically-rich XHTML and use CSS everywhere. Here's to dreaming. Alex -- --- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps -- http://shelter.nu/blog/
