Two messages yesterday – both on the harm (intended or unintended) of using the word “open”. It’s one of those cuddly, comfort-making, words like “healthy” or “green”. Unless it’s clear what it means , it means anything-you-like, so I use “glorious” after Humpty-Dumpty in Alice TTLG.
Here’s Ed Chamberlain, library colleague and now formal collaborator in Cambridge (http://edchamberlain.wordpress.com/2011/10/12/fogging-up-in-the-cloud/ ):
Amongst a flood of product updates and familiar faces, the undoubted highlight for myself was a one hour debate on the merits of open source and proprietary software ownership models, with specific reference to library usage. The formidable but agreeable Carl Grant (EL [Ex Libris, a library software/content company] chief Librarian and former OS guru) and independent library tech consultant Owen Stephens (the MashFather himself) took the floor.
[…]
It was a fantastic thing for the UK user group and Ex Libris UK to host. Ex Libris have gone to great and commendable efforts to expose functionality in their systems to developers, so it seemed like a natural thing to do.
However, I’ll refrain from referring to their platforms as ‘open’ as they are wont to do. For one thing, their model does not match the definitions of the term espoused by the Open Knowledge Foundation and others. OKFN advocate Peter Murray-Rust has had a lot to say on this recently. Ex Libris are a company with great integrity, they don’t need to resort to mis-using words like ‘open’ for marketing purposes. Public facing works fine for me, and the functionality sells itself.
One way to improve things would be to provide public documentation on the API spec. Right now, its for customers only. Having to pay to get access to documentation on closed source software is hardly open in any sense.
Ed says it all, but here’s my own take. About a year ago EL presented their system. I make no comment on whether it’s good or not as I have no experience. But the salesperson (and it was one of those academic-presentations-where-the-purpose-is-actually-sales – “product placements” – where objectivity is replaced by marketing) said something like (the spirit is correct, but the verbatimness is frayed):
S: “Our system has an Open-API”
PMR: “Can I use it?”
S: “Not if you haven’t purchased it”
PMR: “So how is it Open?”
S: “Customers who have purchased it can use it.”
PMR: “Can I see the documentation?”
S: “Not if you are not a customer. It’s confidential”.
PMR: “Can one of your customers show me the documentation?”
S: “No, that would breach their contract”
So here “glorious” seems to mean: “documented”. EL sell their customers software. In the past it wasn’t documented and may not have had hooks (API). Now it does.
So, EL, please do not use the word “open”. Use “documented”.
Here’s another. From a private correspondent who is upset about “Open” as used by VertNet: http://68.111.46.217/pres/PresentationServlet?action=home (the content is to do with vertebrae, I think)
The project is described as:
VertNet is an open, collaborative network. Data providers interested in joining this effort can find out about software and related information on the VertNet project web site.
Their data policy
Disclaimer and Use of Data retrieved through VertNet
Data records provided through VertNet may be used by individual researchers or research groups, but they may not be repackaged, resold, or redistributed in any form without the express written consent of the original institution where those records are held.
My correspondent objected to “open” being applied to the data. The problem arises in that here it isn’t clear what “open” means. I think it means that anyone can participate, or at least ask to participate. It clearly does not apply to all parts of the project. What would be a good word instead? I can’t immediately think of one – something like “community”? “meritocratic”? I don’t think so – I think it means the project information is exposed as “look-but-don’t-touch”. “weak-gratis” might be a reasonable guess.
“Open-glorious” does more harm than good. Unless you are deliberately deceptive, in which case it’s a great concept. Like “healthy green natural free”.
I raised exactly the issue of Ex Libris (and indeed the libraries using Ex Libris products) to be more open with their APIs – unfortunately this was the last point I was able to raise in what was a full hour of discussion and debate – both Carl and I had more to say!
I’ve always felt the Ex Libris have sold themselves short by being so protective of their documentation – while I understand that there is IP wrapped up in the system architecture and workings that are exposed by the documentation, having been an Ex Libris I really think the value they bring goes well beyond any particular aspect of their products.
I also think (although I may be wrong) that there is confusion between requests to see their API documentation vs their core product documentation. Or I may simply be prone to misreading this because I find the concept of having an API but not publishing the details completely baffling.
It is, of course, worth recognising the steps towards being open the company have taken – with the support and encouragement of their customers – in the last few years. Specifically the opening of parts of their ‘Codeshare’ wiki to all. While here the documentation is still protected, all customer contributed code is openly shared. This is to be welcomed, but does lead to the rather odd situation where I cannot see their API documentation but by looking at customer code I can work out many aspects of the API. I only hope that at some point the company will be persuaded that publishing the API documentation will open up even more possibilities.
Oops – that should say “having been an Ex Libris customer” in the second para
oh – and the URL for the codeshare wiki is http://www.exlibrisgroup.org/display/CodeShare/Home
“While here the documentation is still protected, all customer contributed code is openly shared.”
Are you sure? If it were OPEN it would have to be licensed as Open Source. depending on what licence is used, that could affect the rest of the code. I suspect what this means is that paying customers can get to see otehr paying customers code. And EL gets to get all the code and control it.
I imagine that the individual bits of code contributed are useless outside an EL environment. If so this makes it a walled garden where the vendor sucks up freely donated contributions and controls them.
” This is to be welcomed, but does lead to the rather odd situation where I cannot see their API documentation but by looking at customer code I can work out many aspects of the API.”
This is not Open. It is open-glorious by being closed. Few people would release Open Source code that ran against an unpublished and secret API. It’s clear that “open-glorious” sameAs “proprietary secret”.
Let’s at least get the language clear.
To clarify. Ex Libris support a web site where customers can share code that interacts with or somehow extends Ex Libris products. The licensing of the s/w contributed is not controlled by Ex Libris, but by author/contributor of the code. It is not limited to paying customers.
Clearly it is existing customers that stand to benefit most from this, but this is surely true of any code written to enhance/extend other software – if you don’t use the original software, any additional code is of limited use to you. From my perspective, this is not a ‘walled garden where the vendor sucks up freely donated contributions’ – it is the community of users who ultimately benefit, and I believe this to be a good thing.
I wasn’t disputing your, or Ed’s, point about the nature of ‘Open’, nor disagreeing with the assessment of Ex Libris in regards the Openess of their software or platform. However, despite trying to be careful above, I note I used ‘open’, ‘opening’ and ‘openly’ in a rather loose way – it wasn’t my intention to confuse the concepts that you try to separate in your post, but that’s language (or at least, my use of it) for you
Thanks,
I understand what you say. However if, as Ed says, the contributors write modules that depend on a central, possibly undocumented, infrastructure, then it must almost ipso facto be specific to that system. It must almost certainly use the proprietary undocumented/proprietary data structure. It is difficult enough to write generally re-usable (software) libraries – I have spent years doing it in chemistry – and it’s a complete prerequisite that the whole stuff is Open. To write re-usable code in the context of a vendor’s system is effective impossible outside that vendor’s system (maybe Matlab modules might have some hope, but even there).
The test for re-use is: could someone take the code and re-use it without the vendor’s system. Could the author ditch EL and find they had a useful set of modules? I’d be very surprised if that were possible here. For a start it would require an agreed documented data structure.
The contributed code enhances the vendors functionality but only in the context of people who already buy the vendors system. That’s what I call lockin.
P.
Guess my ‘stealth blogging’ cover is blown!
As an aside, Serials Solutions API documentation is here, no login required:
http://api.summon.serialssolutions.com/help/api/
Nor do they call it open, its just an API, and still a good sales incentive in its own right 😉