Equinox Blog

This is what you may be used to with vendor-owned proprietary products:

1) A user group, in a private forum controlled by the vendor, periodically collects enhancement requests
2) Domain experts sift through the requests and put together a list for the membership to vote on
3) Members vote on the list and send the results to the vendor
4) The vendor decides which requests they want to implement, if any, with money gained from their annual fees, etc.

Equinox doesn’t work like that. Nor does Evergreen.

If an Evergreen-powered library needs a feature then they need the feature, and they can determine their needs in whatever manner works best for them. Internally, they may very well do something similar to the process above. But once they have determined their needs, then they have some options:

Option 1) Sweet talk the developers. Seriously. Open source development is a social phenomenon. With Evergreen, the developers aren’t hidden down in the bowels of some corporation, we’re right there in public view. We all volunteer our time to the community whether we’re directly paid to work on Evergreen or not.

Open source development communities are gift cultures that operate on merit, respect, and ego. If you pose a problem on the public mailing list, folks within the community are going to try to model a solution, if not actually implement one, just for the challenge of it and for any kudos they might get from their peers. We measure our worth in what we can give to others.

Tell us that another ILS does something better, and we’ll want to compete, and not only match the feature but do it better (and doing it better may mean integrating with another open source project that has already licked a specific problem domain, like how we’re using OFBiz for acquisitions).

Also, by participating thus in the community, you become a part of the solution. Your time and domain knowledge are valuable assets, and if you help us work through a problem in public, the problem gets exposed to a wider variety of eyeballs that can provide fresh perspectives and help rub off any rough edges on the software.

PROS: For some things, you can get changes made within hours, without jumping through hoops and going through a lot of red tape.

CONS: You have to be nice. You can’t really make demands in such a forum, and with volunteer development certain features might not get built on your timetable.

Option 2) Do it yourself. This need not be as daunting as it might sound. If you already have developers, perhaps among your IT staff, then they can grab a copy of the source code and/or a VMWARE image and start poking the code, asking questions on the public mailing lists, and learning Evergreen right away. It might take a few months to half a year to really start groking how all the pieces fit together, but the return on investment is high and there are no secret API’s or certifications with price tags attached. If you can’t afford a software developer, just providing what help you can (domain knowledge, etc.) to interested and like-minded community members, even if only a few hours a week, can work magic. The best way to find such community members is to ask on the mailing lists.

Now, on the subject of modifying source code, I want to take a moment to dispel a myth. Yes, the software is open source. That means you are allowed to copy it, make changes, and distribute those changes. But no one is obligated to actually add your changes to their copy of the software. Joe Random Developer can’t come along and trash Evergreen with sloppy code to the detriment of everyone else.

This is another reason why community participation is important. By working within the community, your changes get vetted by and hopefully adopted by the community. The community will help you make your changes work within the community, so as to not degrade the project.

The copy of Evergreen residing in a source repository at Open-ILS.org is what our community currently thinks of as the definitive canonical version of Evergreen, the home of Evergreen, but this is only by convention and social inertia. That repository is “governed” by a small group of core developers, currently the original developers who built Evergreen, plus one other, Dan Scott, the Systems Librarian for Laurentian University in Canada. There are other developers that submit “patches” to the community. Those patches get looked at and vetted by all interested developers. If things look good, the core developers apply the patches. If later testing finds a regression, those patches can be rolled back and re-worked. This is how quality control is maintained for the Open-ILS.org version of Evergreen. If a developer earns the trust and respect of the core group, they may be invited to join that group. This may sound elitist, but that’s okay, because open source culture makes this a meritocracy and not despotism. Developers are individuals, not companies; money doesn’t have a say in this. Also, if the governance of Evergreen ever begins to fail the community, the open source license used allows the community to fork the project. Basically, a new leadership can step forward, gain followers, and go off in their own direction with a copy of the software.

Now, to some folks a fork is a scary thing, and some open source traditions treat it as something to be avoided except under dire circumstances, because it can be a waste of resources and lead to duplication of effort. But as a threat, it’s actually useful, because it pushes folks to compromise and work out differences, and it tends to keep the leadership humble. A fork is bad when it divides a community and there are hard feelings. A fork can be useful if the divergent communities are still willing to collaborate and cross-pollinate, and when that happens, folks tend to not think of it as a fork at all. Even if effort is duplicated, one of the forks may actually prove to be superior, and will win mindshare on merit. For an example of a fork in the open source world, see the histories for X.org and XFree86. For more, look at the BSD’s.

This was a long tangent, but it does show how “Do it yourself” can actually work with open source software, if you do it within a community. Notice how it doesn’t work when you try it with a proprietary product. Because you’re not a part of a proprietary vendor’s internal development microcosm, you risk having your work rendered useless at every upgrade, unless you’re lucky enough for them to take your ideas, if not your implementations, and sell them back to you. An open API or database schema isn’t enough if you can’t join their development community as a peer, or if you can’t fork the software.

PROS: This is the ultimate way to control your own destiny. Software is information, and librarians are information architects. Open source is sharing, and so are libraries.

CONS: You may not be able to convince the powers that control your purse strings to let you do this, even if it might prove cheaper than going with a vendor.

Option 3) Go with a vendor. **cough**Equinox**cough** Or a consultant or developer already versed in Evergreen. What you’re paying for here is a developer’s time, expertise, and ability to get work done while staying in harmony with the community. You’re basically funding community development, but with concrete targets and deliverables that meet your needs, instead of paying some vague software tax or annual fee that grants you pseudo-voting rights on enhancement lists.

PROS: You’re still investing in software that can never be taken away from you, and this is a more traditional solution that might appeal to the powers that hold your purse strings.

CONS: We can’t think of any, but we might be biased here.
Wrapping this up…

From these options, I hope you’ve seen the real way progress gets made in open source. It’s through community. A mixed community of volunteers and paid workers, software developers, testers, documenters, users, domain experts, researchers, advocates, critics, fans, and other interested parties. Every little bit helps, and as the community grows, those bits add up faster and faster.

Thanks folks!

– Jason

Bookmark to:

This entry was posted on Tuesday, October 23rd, 2007 at 3:45 pm and is filed under Thinking about Evergreen. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.