by The two of us have seen aspects of the evolution of the Evergreen software ecosystem that was at once surprising and then obvious once it started to arise: the evolving superconsortium in the Evergreen community. This notion first occurred to us independently in early 2009 and, curiously, we each invented the same word to describe it: the Evergreen Superconsortium. Events since then, particularly one just before the Evergreen International Conference in Grand Rapids, have served to confirm our observations.
What is the Superconsortium? It is varied elements of Evergreen community working in concert to develop capabilities within the software and within the community. A library that is a member of a consortium may give up a bit of freedom of action but in return enjoy increased services for its users by cooperating and sharing resources with other consortium members. In the Evergreen Superconsortium, different consortia are cooperating on developing capabilities for Evergreen. It is another arrow in the Evergreen quiver.
The Evergreen Superconsortium
In the first case of superconsortial cooperative development, two systems joined in paying for development of capabilities that were given to the community through the GNU General Public License (GPL). This case was shepherded by Equinox.
Given the changes in the state of Evergreen—for instance, there are more groups using it now—superconsortial cooperative development recently started via independent action of several consortia (Bibliomation, King County, SITKA, and PINES) that are working together to develop a Kids’ Catalog for Evergreen and contracting with FGI, a Seattle based firm. This was a signal event in the history of Evergreen.
Even though these different consortia are doing different things and in different places, they are working towards common goals and the Kids’ Catalog—and Evergreen—will be stronger for it.
We can, then, expect more software development as Evergreen’s capabilities increase through this method as well as more traditional methods. Just last week, Amy Terlaga sent out an email about two enhancements Bibliomation is seeking to have developed and asked if others in the community wanted to help. The trail has been blazed.
Where we are
The Superconsortium arises out of two necessary but not sufficient conditions: open source development and a Consortial Library System. The two separately each create tools to increase the capabilities of libraries through the software they use. Of course, we in the open source communities believe that open source development will provide robust software with a rapid development cycle. What joined the two factors to create the Superconsortium are the strength of the community’s actors and their vision of a new way of doing things. Superconsortial cooperation will lead to even more rapid and better software development and information exchange (data? techniques and practices?) than we have seen so far.
Quo Vadis Evergreen Superconsortium?
It is hard to peer into the future and see what is next—certainly more development with the newer consortia and as members of the community get to know each other better.
There are also possibilities for Superconsortial purchases, for example. These consortia have to move items around from library to library. If they used RFID tags, they could maintain the control over their items that UPS and FedEx can: these companies know where everything is. Can libraries do worse? It would seem to be an easy argument to make in these times that this is a matter of fiduciary responsibility. However, RFID tags are expensive.
At ALA last year, one of us asked a vendor how much it would cost to buy 10 million RFID tags? Well, he said, we would have to bid it but I would guess they would be around 17 cents a piece. This year, the number would be lower. Perhaps a Superconsortium of Evergreen consortia could consider such pooled purchases thus making it resemble the purchasing consortia that are so common in libraries. Of course, we do not have an entity to manage such purchases. And 10 million would not be near enough.
Bob Molyneux and Mike Rylander