eIFL-FOSS Blog

Community Liaison - the intersection of FOSS users, developers, and businesses

The recent appointment of K.G. Schneider - prolific blogger on librianship, writing and everything else, since 2003 - as Community Librarian for Equinox marks a significant milestone. It is significant both for the FOSS development community behind the Evergreen integrated library system (ILS), and for the company that employs the majority of the Evergreen developers and provides installation and support contracts to libraries deploying Evergreen.

Karen describes her role at Equinox as chief blogger, presenter, evangelist, community liaison, birds-of-a-feather organizer, strategist, branding specialist, user-experience person, project management advisor, and whatever else happens to need doing. Sounds like fun. But in practice community liaison is hard work. Often you are interacting with volunteers, urging them to commit even more time to your project. Sometimes you are the only face or voice of a project that users come to know. Those not familiar with FOSS development and FOSS business communities will see you as merely a marketing person. Others will make assumptions about your intimate knowledge of the source code (and potentially be disappointed). You are always called upon to be enthusiastic, insightful, and, I think, slightly distanced from any corporate body that employs you. Your allegiances will constantly be scrutinized - are you there merely as a spokesperson for the support business, or do you represent the users' interests? So it helps if you are part of a project you are honestly proud of and enthusiastic about. From Karen's report, that seems to be the case here.

Fostering community could be the most important aspect of a successful FOSS development project. Some development environments, such as those found in the projects under The Apache Software Foundation umbrella, value community contributions as much as contributions of code. And since most Apache projects do not have a named person with the title community manager, everyone - both users and developers - is called upon to serve this function collectively.

I don't know when the community manager position was initiated. It seems like we have had people in those roles ever since the business community got involved in FOSS development projects. I suppose that makes sense since, as a paid position, the role of Community Manager needs some form of revenue stream behind it to make it viable. But that connection to the profit motive has also always required a delicate balancing act. When business does not play nice with FOSS development communities, relations quickly sour. Fortunately most FOSS-related businesses have a keen sense of what is and what is not appropriate.

There is a difference between a community liaison manager from a company that controls the copyright on all of the code in a project, and one in which the copyrights are diversified with only a shared licence holding the code together. A further difference arises between FOSS projects that are small, tightly knit communities - which, I suppose the Evergreen community is in many respects - and large communities full of volunteer contributors and, certainly, users - which might better characterize the Mozilla projects or the Ubuntu Linux distribution. A thoroughly unscientific bit of research using only a search engine (searching jointly for "community manager" and "open source") finds numerous entries, both job advertisements and company descriptions of their community liaison personnel. I might hazard that such a role is no longer an oddity - it is an essential part of how business interacts with FOSS development.

And in case you think I'm playing favourites by focussing on Evergreen's new Community Librarian, think again. Because of course LibLime - the largest installation and support company for the Koha FOSS ILS, and employer of a great many of Koha's most prolific developers - has its own community liaison person and open source evangelist in Nicole C. Engard. A sign, perhaps, that FOSS business and FOSS in libraries are developing nicely together :-)

Comments: If you can login to the eIFL.net website, then you can add comments to this blog post directly. If not, just write to me at randy.metcalfe[at]eifl.net and be sure to let me know whether you wish your comment to published and attributed (I'm also happy to receive comments that you don't wish to have published).

The Code4Lib Journal - essential reading

As readers of this blog will know, I am not a professional librarian, and I am also not, by training, a programmer. Fortunately for me, around the time I started working closely with librarians and (even more scary?) software developers for libraries The Code4Lib Journal was launched. Its mission is to foster community and share information among those interested in the intersection of libraries, technology, and the future. While it can be dangerous getting caught in an intersection, this journal perfectly captures where I'm at and what I need. It has, even with only two issues released, become essential reading.

The Coordinating Editor of The Code4Lib Journal is the estimable Eric Lease Morgan. It has a solid Editorial Committee, and welcomes input via its Google Groups discussion list. The journal welcomes new submissions and currently uses an editorial process rather than blind peer review. This a journal by librarians, for librarians. The editorial committee is looking for content that is practical, demonstrates how to exploit technology to create digital library collections and services, or offers insight and forethought regarding the use of computers in any type of library setting.

The current issue admirably displays the kind of content the editorial committee is seeking. I was especially drawn to Edward M Corrado and Kathryn A. Frederick's article on Free and Open Source Options for Creating Database-Driven Subject Guides. In this survey of resources, Corrado and Frederick canvas a wide range of FOSS applications, only a few of which I have seen in use previously. They also go on to non-library specific tools such as blogs, wikis, and course management systems that are often used to reach the same ends. All-in-all, a very useful summary.

Another article that caught my eye was Dan Scott and Kevin Beswick's report on their attempts to extend the usefulness of ICT hardware through a FOSS LiveCD, Quick Lookup Laptops in the Library: Leveragin Linux with a SLAX LiveCD. Scott and Beswick undertook a project to improve their users' experience using near-obsolete hardware (at least from a North American perspective) in the J.N. Desmarais Library of Laurentian University in Canada. The hardware wasn't up to the task of running its operating system (Windows XP) and installed software - or at least it was so sluggish as to be virtually unusable. The solution was to convert these machines to running a kiosk Linux LiveCD. The article describes the problem, the proposed solution, and then provides some of the code used to enact that solution. As I was reading it, I immediately wondered whether just such a practical solution might not benefit some libraries across out network. And of course related solutions are already being used in eIFL.net libraries to maximise the life of aging IT hardware.

Just an example of two of the articles I found useful in this new journal. But I've got it on my list now as essentially for me. You might want to consider it for your list of good library ICT reads.

NewGenLib - a new FOSS ILS ready for use

NewGenLib, which stands for New Generation Library, is an integrated library system (ILS) that some of you, especially those in India, Syria, Sudan, or Cambodia, will already know. It is the product of a 4-year collaboration between the Kesavan Institute of Information and Knowledge Management (KIIKM) and Verus Solutions Pvt. Limited (VSPL), both based in Hyderabad, India. Toward the end of 2007 a business decision was taken to release NewGenLib under the GNU General Public License (GPL). And thus NewGenLib was reborn as a free and open source software (FOSS) ILS.

The code - should you immediately want to begin investigating NewGenLib's functionality - is available from SourceForge, the repository of more than 170,000 FOSS projects: NewGenLib on SourceForge. Since NewGenLib is Java-based, it deploys straightforwardly on Linux or Windows platforms. Just follow the installation notes for the platform on which you will be deploying.

NewGenLib was already a complete ILS prior to going open source. It boasts modules for

Acquisitions
Cataloguing
Serials Management
Circulation
Administration
OPAC, and
Reports.

The current release is version 2.1, but version 3.0 is under development with a targeted release date of April 2008.

The biggest challenge, of course, is whether NewGenLib will be able to transition itself to a FOSS development model. Releasing code under a FOSS licence is easy compared to building and sustaining a FOSS community of users and developers. Will NewGenLib make the leap?

One positive sign is the set of discussion forums that NewGenLib has set up on its SourceForge site. I don't find forums as easy to negotiate as an email discussion list, but clearly many people like them and these seem to be busy. (The downside to that is that multiple forums mean more work for people within the project that need to respond to queries in various fora.) By contrast, the mailing lists for NewGenLib on SourceForge show very little use.

Deciding to release the code under the GPL also means a significant shift in business model. Or does it? The licence fee-based model under which NewGenLib previously operated was essentially tied to service support contracts. Under a FOSS licence, support contracts continue to work in exactly the same way. The developers, however, have moved to clarify matters by setting up a separate IT services company - Verus IT Services Pvt. Ltd. - in order to take on the servicing of the open source deployments, as well as existing commercial licensees. The most significant change for the business model is that, as FOSS code, nothing prevents other companies form also offering support contracts for NewGenLib. But if hundreds more libraries take up NewGenLib on account of its FOSS credentials, then there will be plenty of room for multiple support companies in different countries. Even better if those competing support companies are able to contribute code to the further development of NewGenLib.

Changing a licence does not, in itself, change the software. So, at the moment NewGenLib is about the same product as it has always been. But joining the world of FOSS does make a difference. It makes a difference to the future, to the future of NewGenLib and possibly the future of the FOSS ILS. It's great to see another FOSS ILS joining the ranks of Koha and Evergreen. And it bodes well for libraries in developing and transition countries that so much choice is now available.

I will be following NewGenLib's management of its fledgeling FOSS community closely, and with good will. I really hope it makes a great show of it.

IRC: information on tap

Internet relay chat (IRC) is a familiar communication tool in FOSS development and user communities. It can be vibrant, fast-paced, friendly, exceedingly geeky, and ideal for getting a quick response to a hard question you just haven't been able to sort. If you have not tried it previously then now is as good a time as any.

You could start by exploring the IRC channels, or chat rooms, that support Koha or Evergreen development, or for the more daring amongst you, try the code4lib IRC channel.

IRC is real time, or synchronous, communication. So the people chatting on an IRC channel are doing it right now before your eyes. This puts their collective expertise and experience immediately at your finger tips. But of course it also limits you to just those who are in the room at any one time. The more people in the room, the more likely it is that there will be someone there who has dealt with precisely your question before. Be sure that your interventions are brief, to the point, and courteous. And in most cases you will get a helpful response.

Some people keep their IRC client open on various channels all day long (even all night). Just because you see the nick of someone you know listed as being in the channel, don't assume that they are necessarily monitoring the chat room at that moment. To constantly monitor all the IRC channels you might like to be in would take up every moment of the day. Even just staying up with the incredibly chatty code4lib channel can be daunting.

And that brings up logging. Most IRC clients (I use Pidgin - which has versions available for Windows and Linux) support some form of local logging of the channels you are in. So you might spot my nick - I usually show up as randym - in a channel, but I'm off doing something else at the moment, maybe reading or answering email, or writing a blog entry. Later I will review my local log of the activity in the channel to see if something especially interesting showed up. And if someone pings me, Pidgin will catch my attention.

Using IRC this way changes it from a synchronous communications format to a static information page. These pages won't be treasured for their brilliant prose, but they could reveal the most pressing problems confronting users of the software. Which could make them very useful indeed. Both of the projects above make their IRC logs publicly available and searchable: Koha IRC logs; Evergreen IRC logs (a recent addition).

The other great advantage of logs for IRC channels is that they make the discussions available to those who may be many time zones distant, or who may have intermittent Internet connections.

IRC isn't for everyone. Me, I love a good email list, especially one that is publicly archived and I am prone to enthusing about such lists. Some of the FOSS projects I've been involved with simply couldn't work in a coordinated way without email lists, either because there were too few people involved to make an IRC channel sensible (is there anything as sad as being the only person in an IRC chat room?), or because time zones simply made it impractical. On the other hand, you might agree with a friend of mine who once complained that, Email is so 20th century!

Maybe. In any case, there is plenty of room for multiple channels of communication serving different ends in FOSS development and user communities. And IRC has advantages that make it well worth learning how to use well.

OLA Super Conference: the profession of librarianship

This past Thursday and Friday I attended the Ontario Library Association (OLA) Super Conference in Toronto, Canada. It is a huge annual event in the professional librarianship calendar in Ontario (and beyond) with more than 1000 delegates and up to 29 parallel sessions running at any one time. It's all here and it is all focussed on the professional development of librarians.

Since I'm still very much an outsider to the world of librarians, I find myself noticing things that are probably taken for granted by my peers. Take, for example, the very idea of professionalism. Imagine 29 separate sessions, 3 to 4 of them per day, plus plenary sessions. And each of them on some specific aspect of the life and work of the library. The level of detail is remarkable. And all of it dedicated to helping each delegate improve their work, their library, and the service they provide to their patrons. I was just way impressed.

A good example came from the very first session I attended. Some of you reading this blog will remember Nasser Saleh. Nasser used to be the eIFL.net country coordinator for Palestine. For a number of years he contributed greatly to the growth and development of eIFL.net. Nasser now lives in Kingston, Ontario, and is the Integrated Learning Librarian at the Engineering and Science Library of Queen's University. (He's also doing a Ph.D. part-time, but if you know him, you won't be surprised at just how busy he keeps himself.) Together with his colleague, Sharon Murphy, Nasser was presenting a session entitled Colleagues: get out of the library. In it they detailed the efforts being made at Queen's to integrate librarians into the classroom, to reach out to students and researchers where they learn and in doing so facilitate their access to knowledge. Impressive. And the audience of assembled librarians thought so as well. There was plenty of discussion of how things were working at other universities, and ideas put forward of what to do next.

After such a bracing start, I was worried that the talk I was participating in that day, Open Source and Libraries in the Developing World, might not be equally well received. I should learn to relax more. Fortunately for me I was sharing the platform with Nasser himself, and with eIFL-FOSS' good friend, Bess Sadler of the University of Virginia. We had a packed room which was immensely satisfying. (Remember, there were 28 other sessions going on at the same time.) Bess gave the intro and overview about free and open source software; Nasser spoke about what eIFL.net does, and then I stepped up to tell people about our new eIFL-FOSS program. People were interested and enthused. For these librarians, what goes on in libraries in developing and transition countries is not some esoteric interest: the librarians in those countries are their colleagues, their peers, and often their friends. That's another one of those things I've learned. Librarianship is a profession, and professionals share a bond with each other no matter where you find them.

Amongst the folks kind enough to attend our session was Ethan Zuckerman, founder of Geekcorps and co-founder of Global Voices On-line. We were all a little in awe since Ethan was the big keynote speaker at the conference that day. But I later learned he is a keen supporter of eIFL.net and his blog about our session couldn't have been nicer.

Ethan's talk itself was entertaining and enlightening. What I took away was his observation that, "homophily makes us stupid." And if you don't know what homophily is, you'll recognize it as soon as you do; it's that undirected but incessant grouping instinct we have to flock together with birds of like kind. Ethan's point was that we are seeing lots of instances of homophily on social networking sites. And while it's nice to hang with your "friends" a lot, you'll probably learn more, face more interesting challenges, and grow a bit more by encountering strangers. In a way, that's why I took up with eIFL.net. I figured I'd learn more here and more quickly. I was right :-)

The sessions on Friday were barely any less well-attended than the Thursday sessions despite an horrendous snowstorm battering south-western Ontario. Yes, this is Canada.

I was tremendously psyched to attend a session by Dan Scott of Laurentian University entitled, Evergreen: state of the open-source ILS. Dan is the project coordinator for Project Conifer, which brings together Laurentian, Windsor, and McMaster University as they investigate, pilot, and potentially migrate to the Evergreen ILS. Dan is immensely talented as a programmer, and has a great presentation delivery. Of course when you completely know what you are talking about, it probably helps :-) I finally think I have a good handle now on precisely where Evergreen is on its development curve and, especially, on the level of enthusiasm amongst Ontario libraries, both academic and public, for this venture. One of best things about FOSS is that nobody can constrain you from simply picking it up and starting to use it. So you run into situations, as in this session, where librarians were piping up and surprising Dan with announcements that they too were in the process of migrating to Evergreen. It got so that at one point I wanted to stand up and say that I too was Spartacus. Fortunately I contained my enthusiasm.

Systems librarians are, I suppose, a different breed than, say, reference librarians. Certainly the discussion at Dan's talk was considerably more technical than any I had heard the day before. And that got me wishing I were having more fun with source code than I am at the moment. But that's another story ;-)

Two final items from the OLA conference. The first is Erik Hatcher's presentation on Blacklight: Univeristy of Virginia's catalogue on SOLR. Erik is frighteningly clever and willing to give a presentation while things index and compile behind the scenes, live. No doubt that's because he trusts his own code :-) Blacklight is a little project that has huge potential. It is a "next generation library catalog written in ruby, using solr as the underlying search engine." But in layman's speak, it is a cool, faceted access to your catalogue. Naturally enough it is a FOSS project and, also not surprising, our good friend Bess Sadler is closely involved in the ongoing development of Blacklight. I intend to check out their subversion repository in the next couple days and take a look at the kind of code that super-coders write.

Finally, a nod to Our Ontario. This is a collaborative project delivering integrated access to digital collections of libraries, archives, museums, historical societies, galleries, and more. This year it deservedly won the OLITA award for technological innovation. You won't be surprised to learn that Our Ontario is built entirely on a FOSS stack using Cocoon, Lucene, and Solr. And if it is innovative technology for libraries in Ontario, wouldn't you expect to find Art Rhyno involved? So it won't come as a surprise to learn that Art is the Chair of the Steering Committee for Our Ontario. And thus I had the pleasure of meeting up with Art again.

OLA Super Conference was certainly a new experience for me, one that has confirmed my impression of librarians as a highly professional and committed group.

OLPC: open source, open access, open library - University of Windsor

Recently I had the good fortune to be invited along for a special evening celebrating, publicising, and enthusing about the One Laptop Per Child project organized by Mita Williams of The Leddy Library at the University of Windsor. I had been asked to speak on the significance of free software and to inform those assembled about the eIFL-FOSS program. A perfect opportunity for me to enthuse about subjects dear to my heart. But also - since an OLPC laptop was given away to an audience member during the proceedings - a chance to think a bit about what it means to create new possibilities.

I spent a lengthy drive to Windsor thinking about just what the relative significance of free software is. I wondered to myself (okay, maybe I was actually talking aloud to myself in my car; it happens!) what were the important breakthroughs in the past 100 years. The discovery of penicillin was certainly important. Is the creation of free software through the means of appropriate free and open source licences more or less important than the discovery of penicillin? I just don't know. But the fact that I don't know means I think it is at that level or beyond.

No doubt I spent too long in my talk enthusing about the possibilities created through the application of a legal instrument (in this case, the GNU General Public License) as a means of preserving four freedoms concerning software: 0) the freedom to run the program for any purpose, 1) the freedom to study how the program works and adapt it to your needs, 2) the freedom to redistribute copies so you can help your neighbour, 3) the freedom to improve the program, and release your improvements to the public, so that the whole community benefits. It was these four freedoms that Richard Stallman sought to preserve when he drafted the first version of the GPL. And in so doing, he changed the world.

I don't know how often people do things that change the world. Change it fundamentally. Fundamentally because the very possibilities of that world are substantially altered.

Is the OLPC project going to have that kind of effect? Maybe. Maybe some day we will look back on it and say that it was as important to the world as the discovery of penicillin. Or free software.

And what is the connection between free software and the OLPC? Well, this exciting device runs entirely on free software. The operating system is based on Fedora Core 6 Linux. The activities (OLPC-speak for programs) it runs are themselves all free and open source software. And for most them you can press a button and actually see the source code for the program.

I kept wondering as I drove to Windsor through the cold Canadian winter whether those geeky free software developers who contributed a line or two, or made dozens of lines, of code to the Linux kernel ever guessed that some day someone would be creating a whole new range of educational and social possibilities, in part due to the free software they had helped to create. I suspect not.

That's the thing about creating new possibilities. You just can't tell where things will end up.

It was a lovely evening surrounded by librarians, students, and researchers all fired up by the advent of possibilities. For which I'd like to thank Mita Williams, my co-presenters, Art Rhyno, Systems Librarian at the Leddy Library, and Dr. Dragan Martinovic of the University of Windsor Faculty of Education. And of course also the two sponsors, The Leddy Libary and The Essex Free Press.

Zotero - a FOSS tool for publishing and managing bibliographies

Zotero (http://www.zotero.org) is a free, easy-to-use Firefox extension for managing and citing references and creating bibliographies. Zotero is the FOSS alternative for EndNote®, the product of Thomson ResearchSoft, a business of the Thomson Corporation.

I tested Zotero on Armenian Libraries union catalogue, on the PLoS and Birmingham Open Access repositories, and on the Library of Congress catalogue. It created bibliographic records with the needed metadata without problems. Moreover - you can create your citations and bibliographies inside of the OpenOffice. For this you need to download a small plugin from the Zotero page http://www.zotero.org/documentation/openoffice_integration . (Zotero is also compatible with the MS Word, but I haven’t tested that.)

As a result of exploring Zotero, I am planning to organize a series of training sessions for the students and young scholars in Yerevan. I found that Zotero is easy to install and manage. Within the word processing systems Zotero suggests a wide variety of citation styles, which can be used when creating citations inside of your documents.

Tigran

ILS Migration - the long game

This past Friday, I had the good fortune to meet up with John Fink at McMaster University in Hamilton, Ontario, Canada. John is Digital Technologies Librarian in the Mills Memorial Library at McMaster. Amongst his numerous responsibilities, 50% of John's time is devoted to managing McMaster's transition to a new open source integrated library system (ILS) – Evergreen. I wanted to discover where that project is at as well as a little bit about John's connection with free and open source software (FOSS).

A library's integrated library system (ILS) is the single most important piece of software in its infrastructure. The ILS touches nearly every part the library, from acquisitions to cataloguing, from patron management and lending to the OPAC and more. Libraries, as a rule, do not like to mess with their ILS. They tend to find one they like, deploy it, and then stick with it.

John came to McMaster in September after following up a job advert in the spring of 2007. What attracted him was the explicit mention of open source software in the job description. His first involvement with FOSS came while pursuing an undergraduate degree in English Literature in Ohio. In time he drifted in to IT support and then systems administration on unix-based machines, which in the late '90s and beyond were often being replaced with Linux boxes. One library science degree later and some intensive experience in a medical science library in California, and John was ready for the open-ended challenge that McMaster's libraries, now under the tender guidance of Jeff Trzeciak, University Librarian, present. (Some of you will remember that Jeff spoke at the eIFL.net General Assembly meeting in Belgrade, Serbia, this past November.)

So when exactly did McMaster decide to investigate Evergreen, and why? The decision was made before John arrived on the scene. The reasons are many: part of it had to do with the announcement in March 2007 by SIRI/DYNIX that it intended to phase out its Horizon ILS, the one that is currently in use at McMaster (or rather that was the way the announcement of introduction of Rome was taken). So that meant change was in the air. Part of it certainly had to do with the great strides that the Evergreen developers were making at the time. And no small part of it must have been the fact that at least a couple other Ontario universities were serious about Evergreen at the same time (more on that in a moment). No doubt there are other reasons in the mix. A large university library does not change its ILS whimsically nor precipitously. It takes a measured view. And it plays a long game since an ILS isn't something you chop and change every year.

It is worth noting that the libraries at McMaster are not overwhelmingly FOSS driven. When John arrived there wasn't anyone else using Linux on the desktop, and even today he thinks there are only three. The public-facing machines are all Windows boxes. And there are relatively few Macs to be seen. Where FOSS had a role to play was on the servers, which are typically Red Hat Fedora Core machines. John notes that there is also some FOSS in use in the document management system and in conferencing software, an example being Open Conference Systems from the Public Knowledge Project . The decision to move to Evergreen was thus not ideologically driven.

How has John been getting on with Evergreen?

Excellent. Five months into his post he has Evergreen up and running locally on a test machine dealing with a sizeable chunk of McMaster's catalogue. But there is ever more testing to be done. In fact John was about to wipe everything out and re-install on a clean Debian machine just to be certain he has the procedure down. It's no simple thing to evaluate a new ILS. Caution is the watchword. And care. And it helps to have a lot of support.

For support, it makes a big difference that both the University of Windsor and Laurentian Unversity are evaluating Evergreen at the same time as McMaster. Art Rhyno at Windsor and Dan Scott at Laurentian are both, according to John, much more into the code than he is. (John sees himself as a deployer of FOSS, not really as a developer.) They are making significant contributions to Evergreen's development, especially in the acquisitions and serials modules. Having them nearby and willing to lend an ear (via email or on Evergreen's IRC channel) takes a lot of anxiety out of such a big move. These universities effectively have created a support and deployment consortium. Eventually they will house their Evergreen deployment on a shared Linux cluster based at a fourth Ontario university, the University of Guelph.

If migration to a new ILS is a long game, just how long will it be before McMaster has made the switch? Apparently the target for migration is summer 2008, though some slippage has been allowed for. For a time thereafter Evergreen and Horizon will run in parallel. And then eventually, at some point approximately 2 years after the original decision to migrate was made, the migration will be complete.

Will anyone notice that McMaster is using a FOSS ILS once they've made the change? Probably not. John says that good software gets out of your way and lets you get on with what you need to do. But the decision to go with a FOSS ILS makes a world of difference to those behind the scenes, especially digital technologies librarians like John Fink.

Open Translation Tools, day 3

The final day of Open Translation Tools 2007 found us tired yet eager for more. We followed a similar pattern to day 2 with parallel sessions dominating, punctuated by another SpeakGeeking session. By this day, I had a much clearer idea of what I needed (at least in regard to the challenges ahead for the eIFL-FOSS ILS project). Nevertheless it was still a hard choice to decide which sessions to attend.

The first session I joined was on business models in the open content sphere. I thought I might have something to contribute to this discussion since I have a reasonable grasp of business models in the open source world. In fact I'm not sure I was able to contribute all that much. Most of the revenue streams in the open content projects represented were from grants from foundations or trust or government. That, of course, is a worthy model. But it has challenges when it comes to sustainability. The other model we discussed was primarily support/training. I think everyone present sensed that there is a potential publishing business model around open content tantalizingly close. But I didn't feel we were able to flesh it out. We were, however, fortunate to have a couple of entrepreneurs in our group. They kept us tied to the real world. This was useful because in the end the success of a business model is tied to your ability to meet your payroll month in month out.

In the second session I joined up with the software development folks to talk about localization of software. I confess I felt more at home in this group. Every one (which the possible exception of me) was an experienced FOSS developer, comfortable with the tool chain used for localization, and ready to discuss the challenges they were facing. Fortunately I had learned enough on Day 2 of OTT07 to at least follow the conversation. The key challenge for most localizers of software is upstream software developers who have not planned for internationalization from the start. Clearly that ought to be a prerequisite for any FOSS development project (I now understand). But even if the project has designed for future localization efforts, that still won't avoid the inevitable challenge of language itself. What is the best Serbian word for “Inbox”? How do you make an interface that is built around the memes of office culture (e.g. files and folders) accessible to a potential audience where office experience is minimal? Does that matter? Should you incorporate a jargon term from an English interface if there is no simple substitute in the target language? Or does that undermine the natural evolution of your language? Hard questions to be sure.

The SpeedGeeking session on Day 3 was just as exciting as that on Day 2. Again, I will hold off describing all of the relevant projects here. But do expect to find posts on many of them in the coming weeks.

The final parallel session of the event saw us dividing into the original two groups: tool and open content. Contrary to what I had done on Day 1, this time I went with the tools folks. The focus for each group was on practical next steps. What emerged in the tools session was that a number of the developers had discovered possibilities for future development through collaboration with other projects present. The first tentative steps towards these were already taking place. Only the constraints of time, resources, and other commitments can hold back exciting new developments around the corner.

Open Translations Tools 2007 was an excellent event. Everyone participating came with knowledge and experience to share, and found others with knowledge and experiences from which they could benefit. The constant focus on participation (much spoken of elsewhere but rarely achieved) made the days exhausting but highly rewarding. To close out the day, Gunner asked us all to look around the room and really see each participant there. Definitely a group I was honoured to be a part of.

Open Translation Tools, day 2

Day 2 at Open Translation Tools started bright and early. And just as interactive as day one. Now that we all had a bit more knowledge under our belts, it made sense to go around the room again and ask each participant to identify something specific they definitely wanted to get to before the end of the next day. For me that was easy. I wanted to at least have set up an environment on my machine where I could potentially participate in localization of source code.

If you've never done that kind of thing previously you wouldn't even know where to begin. But now (or at least by the end of day 2) I understand that for most FOSS projects what you are really doing is taking a .pot file - effectively the list of all the strings of text in the program's interface - and translating each of those strings into the target language. The completed set of translated strings is saved as a .po file. So, one .pot file, many .po files, one for each localization. There are other systems, of course, but this describes the norm in FOSS projects.

Gentle reader, I'm delighted to say that by the end of day 2, I had indeed installed a .po editor (I used poEdit), downloaded a .pot file from a FOSS project and tried at least a few translations of some of the text strings in order to create a localized .po file. I learn in very small steps :-)

Once again this day we broke into parallel discussion groups. The choices were hard, since I have so much to learn, but for the first one I went with the group discussing challenges and opportunities in managing a volunteer translation community. There, I was inspired by Danilo Segan's account of managing the 300+ volunteers contributing to the Serbian localization of Gnome (one of the familiar desktop environments for those using a Linux distribution). In the same vein, Dimitris Glezos explained how the Greek localization of Fedora (the Linux distribution, not the institutional repository) works. At least on the surface, it was clear that the localization of software seems to be organized differently than the volunteer communities translating open content manuals or other text.

The second parallel session I participated in was focused on quality assurance, or quality assessment. Here the differences between localization efforts for software interfaces versus translation of free text again came to the surface. Professional translation of text always involves a careful layer of proofreading and editing. Our discussion concentrated on how to get at least some of that built into the workflow for community-led translation efforts. I doubt we fully cracked this problem, but at least everyone involved got a much sharper view of where the challenges reside.

The first SpeedGeeking session of the OTT07 took place immediately after lunch. Since very few will ever have experienced SpeedGeeking, I'll describe it briefly. Take 7 people with fabulously interesting projects or software tools. Give them each a table and whatever communications tools they desire. Divide the remaining participants between each of the tables (about 3 or 4 people per table). Then begin. The SpeedGeeker gets 4 minutes to describe his or her project. When time is called everyone (except the SpeedGeekers) moves to the next table. Repeat. In about 35 minutes you have been introduced to 7 exciting new projects. It is exhausting, especially for the presenters, but you will certainly have identified one or two people you absolutely must follow-up with later. Very efficient, and lots of fun.

I'm holding back here from describing each of the projects lest this post become impossibly long. Instead I'll do an individual post on each of the projects that impressed me later.

After a short break we went back to the parallel session format. The one I attended concentrated on workflow for translation in an open content project. What was clear was that most workflows were ad hoc, created through trial and error rather than on the tried and tested model of the professional translation industry. But of course the conditions are different.

The second day concluded with another communal meal and lively conversations that extended far into the night (and, for a few participant, in to wee hours of the morning).

Open Translation Tools, day 1 concluded

Day 1 finished off the way it had begun, with plenty of interaction amongst the participants. We started by dividing into two groups, those who had use-cases describing content in need of translation, and those who had translation tools to discuss and enumerate. I was in the group attempting to characterize clearly differentiated use-cases. The challenge with such work is to be as granular as possible since this is the only way that an accurate mapping will be made later between the use-cases and the tools available.

One of the things I've liked best about this event has been the focus on documenting what we are doing. Four separate documenters are participating in the event. One is continuously adding content to the event wiki. Another is specifically responsible for gathering and characterising the variety of use-cases. Another is doing the same thing with the range of tools available. And finally there is another documenter videoing the proceedings who will also conduct video interviews with each of the participants. It's all about openness and these various documentation methods and tools should guarantee that outcomes from this event will be available widely and not just for the participants.

The final session of the afternoon took three of the problem areas that we had brainstormed in the morning and made them the focus of a discussion. For this I joined the “Translation 101” group in order to get a crash course on the translation industry (which I was shocked to find is a 12 billion dollar behemoth). This session was facilitated by two professionals in the field of translation (though admittedly they got very little notice that they would be facilitating a session): Ed Zad of dotSUB and Dwayne Bailey of Translate.org.za This session was absolutely priceless for me. I am now considerably better versed in the correct terminology. For example, I now know the difference between internationalization and localization, and between translation and interpretation. I understand the traditional model (translate - edit - proofread) used in the industry and why that is changing. I learned about the all important component of any successful computer assisted translation tool or CATT, namely translation memory TM, not be confused with MT, machine translation. I also learned of the emerging XLIFF standard which encompasses po, the string set format typically found in software translation cases. To say it was a lightening class is an understatement. And this has made the likelihood that I will get something even more valuable out of day 2 an almost certainty.

Open Translation Tools 2007, day 1

I am in Zagreb, Croatia, today with a fabulous collection of folks passionate about open content and FOSS translation tools. Open Translation Tools is organised by Aspiration and the Multimedia Institute [MI2]. It brings together software developers working to develop translation tools with projects that have particular use-cases for translation. Together we are going to learn from each other and seek to bridge the gaps, if they exist, between use-cases and available tools.

The remarkable Allen "Gunner" Gunn, Executive Director of Aspiration, has been facilitating a highly interactive day which has included an analog opinion differentiator (not as high tech as it sounds!), small group brainstorming, concept grouping and, of course, lots of opportunity to meet new people and learn about their projects. Since I am a complete newbie to the world of translation tools, I am finding that nearly everyone I speak to has something to teach me. And of course they are equally interested to hear about what eIFL-FOSS is proposing to do with its ILS support documentation project. I'm especially looking forward to the Speedgeeking session tomorrow.

I will report further as time permits (I'm on short lunch break at the moment!) with links to some of the tools that stand out.

FOSS policy: personal and public

Should I have a personal FOSS policy - a set of principles by which my software decisions are made? I suppose in some sense I already do. I use Mozilla Firefox all day long, every day. I use OpenOffice wherever possible. I use GIMP for my photo editing. I use Pidgin for IRC, and a host of other FOSS packages. But do these choices I have made amount to anything more than a set of preferences, or, less charitably, prejudices? Is there any coherent policy that could be distilled from them?

Maybe it's just me, but this is a question I ask myself on a regular basis. And it is also a question I frequently ask universities and colleges.

I suppose in theory the way to go about things would be to come up with your policy first and then implement it in practice. But that isn't the way life generally works. Instead we tend to have a practice that gets modulated or modified as we take up the policy challenge. And that explains why it is so useful to come back and ask the policy question again and again.

In practice I find that I am a pragmatist, but a principled one. For example, I'm not averse to using a proprietary operating system (no prize for guessing which one). But I would also be just as happy using Ubuntu. Over many years I have structured my work environment so that I use the same set of programs regardless of which operating system I'm using. My pragmatism forces me to use whatever operating system is available to me. My principles help arrange it so that I'm (mostly) using a FOSS suite of programs regardless of operating system.

When institutions approach the FOSS question they also tend to strike a pragmatic balance. Some like to have an explicit FOSS policy that lays out how FOSS ought to be factored in to the IT decision-making process. Others will have no explicit FOSS policy at all, subsuming all such matters into a broader IT strategy. I know of one ICT Strategic Plan which is 111 pages long, 3 years in the making, yet contains no mention of open source software or free software in the entire document; in fact, the word software is not used at all. This, despite the fact that FOSS is used across the IT infrastructure at that institution.

Policy can also find a home at a much higher level, of course. It's the sort of thing governments are good at generating. It would be a worthwhile mini-project to gather data on just how many of the eIFL.net member countries have national policies concerning FOSS.

What I most want to know, however, is not merely whether a country, or an institution, or a person has a FOSS policy. What I want to know is how that policy (whether it is publicly accessible or not) is affecting real decision-making on the ground. Not, "Do you have a FOSS policy?", but rather, "What has been the practical impact of your FOSS policy?"

The space between policy and practice - that's where I'm headed. But first, I think I'd better get my personal FOSS policy written down :-)

What's the impact of your FOSS policy on your practice?

Getting started with a new FOSS community: user email lists

How do you get started with a new FOSS community? Perhaps someone recommended a software package to you. Or it came up in a news story. Or someone spoke about it at an event you attended. Or someone has told you (your boss?) that you need to get familiar with it. Or maybe you are just curious and want to learn something new (hey, it's possible!). What do you do?

No doubt your first step is going to be to go grab the software, install it, and give it a whirl. Sure, that's a good idea, but I'm focusing here on your first steps in getting to know the FOSS community that is using, developing, and supporting that software. How do you get to know a new community?

One starting point is the user email list. If there isn't a user email list, then I would go straight to the developer list. Some projects do not separate their user list from their developer list, or at least not until the volume on the unified list becomes unmanageable. But assuming there is a distinct user email list, the first thing I usually do is sign up to that list.

And then I listen.

And listen.

I might sit on a user list for some new FOSS community I am joining for months before I make my first intervention. A user list is not the service window in a repair shop. It's (usually) a community in the midst of a conversation. I want to listen to the way this new community talks to itself before intruding.

What are its typical concerns? How are queries handled? Is it friendly? Is it tolerant of new members who may ask naïve questions? Just a few of the questions I'm going to have foremost in my mind. In reality I want to know whether this is a community I want to be part of, to spend time in, to contribute to.

Is the user email list active? What is the frequency of questions being asked, and how long until someone offers an answer? Who usually answers questions on the list? Is it one of the key developers, and, perhaps more important, is it the same person all the time (which might be a sign that knowledge is overly concentrated in one individual)? Do people who have asked questions in the past ever start answering questions later? More questions here about whether there is a progression from user to supporter. And if that isn't the case, why isn't that happening?

When someone asks a question, are answers given in a form they are sure to understand? Are they regularly referred to user documentation, maybe a project wiki or manual that ships with the software, where the asker can both find the answer to this question and others they are likely to have? Great if this documentation is already in place. But why hasn't the user found their answer there already?

If the user email list isn't publicly archived, that is a bad, bad sign. And if it is, then I've got a fabulous resource available to me as well as to web indexing services like Google. By investigating the archive I can see how this community has acted and reacted over time. I may even get a sense as to where it may be headed in the future.

Why is all this important? Because in many cases the user support email list will be the first port of call if I run in to difficulty deploying software. That, even if my institution should choose to take out a support contract from some company. It might even be a factor (though perhaps not a deciding factor) in my institution's choice between competing FOSS alternatives.

For the past 3 months I have been lurking on the user email lists of both Koha and Evergreen.

Koha mailing lists
Join the main Koha user mailing list (Koha also has a number of specialized lists available including lists in French and German, see above)
Web archive for the main Koha user mailing list
Evergreen mailing lists
Join the Evergreen (Open-ILS) user mailing list
Web archive for the Evergreen user mailing list

What have I found? Well, that's a subject for another day. I am more interested in what you have found, if you too have been lurking on these lists.

I invite you to share some of your impressions of the Koha or Evergreen communities based on your participation on their respective user mailing lists. We still haven't sorted our spam control for comments, so please just write to me at randy.metcalfe[at]eifl.net and be sure to let me know whether you wish your comment to published and attributed (I'm also happy to receive comments that you don't wish to have published).

One final thought: FOSS communities evolve. Your participation on a user mailing list can impact, even transform, the nature of that user community. And that is a heartening prospect :-)

Free Software & Open Source Software Symposium - Toronto (day 2)

Day 2 of this conference started better than day 1 since I didn't get lost getting here. First up for me today was a talk entitled The Development Commons: A Virtuous Circle of Software Production for Virtuous Organisations. The presenters for this were Jason Cote and Julian Eglestaff, both of Freeform Solutions. They provide IT solutions for not-for-profit organisations. They use free software in their work, and they ensure that any software development they do as a result of their work is also contributed back to the commons. Essentially what not-for-profits pay for when they come to FreeForm Solutions is time - time for Freeform staff to find a viable solution to their problem set. One of the positive features of their business approach is that, knowing their client base, they aim for solutions that require zero maintenance for the client, and which adhere to strict budget constraints. Jason and Julian know that not-for-profits usually only have a very precise amount of money allocated for a specific IT solution, and that there is no tap they can turn on to make more money flow later. So the solution they provide effectively has to be able to run forever. Jason also pointed out that they have a business policy of not dealing with any client that wants to have an exclusive development relationship with them. If the client isn't happy to have the code that gets developed for the their problem contributed to the wider commons, they can find someone else.

The next talk I attended was David Eaves' presentation on Community Management as Open Source's Core Competency. This is a subject close to my heart so I was keen to hear David's take on it. David has a great presentation style that keeps the audience interested and gets them involved. He is also somewhat sceptical about claims to the collaborative nature of open source, but perhaps he was merely playing devil's advocate in order to provoke discussion. In any case, he offered some suggestions on how to facilitate collaboration that he imported from his experience in the realm of politics and international relations. I don't have any disagreement with his suggestions, but I find myself somewhat sceptical of his basis for some of his sweeping generalisations about open source development communities. I find that nearly every FOSS development project I engage with is unique. It takes me a fair bit of time to get a strong sense of how the community works, to pick up on the explicit and implicit rules of engagement. Even two different projects in the same development "house", so to speak, for example two projects from The Apache Software Foundation, will have slightly different ways they do things, different expectations of participants perhaps, and of course, different real people with different real personalities that are struggling to cohere. It takes time to learn the particularities of communities. Since David's initial insight into the importance of community is definitely on the mark, I'd love to talk to him after he has more experience with actual FOSS development communities and has taken the time needed to engage with one or more of them in a serious way.

I'll pass over Jesse Hirsh's talk on The Problem with Open Source: Know Your History quickly since I didn't feel there was sufficient content there to grapple with, but maybe this is just another example of me being the wrong audience for this talk.

Yesterday, lunch was a pleasant surprise meeting new people. Today I spent my lunch hour with those same people and about 50 others. David Eaves and Mark Surman ran a Birds of a Feather (BOF) session on Open Source, Open Communities? At tech conferences, BOF sessions are usually unscripted opportunities for people with a shared interest to get some quick interaction. With so many attending this BOF, I wasn't certain David and Mark would be able to do much at all. I was wrong. It was great! Having marked a line across the room with a "yes" at one end and a "no" at the other, they got everyone up on their feet and asked them to "place" themselves on the line in response to a series of provocative statements made by Mark. David then went up and down the line asking people why they either agree or disagree with the claim. In this manner we explored such questions as the role of democracy in open source projects and the importance of collaborative skills for a project leader. Stimulating and thought provoking.

After lunch I went to hear Rory McGreal talk about Copyright control and open access: From Queen Anne past Bill 60. Rory knew his stuff and spent the hour exploding 10 myths about copyright. I thought I knew this subject inside and out, but I learned a fair bit, especially about how we treat copyright in Canada (well, to be fair, I've been away for 13 years so I've sort of lost touch). One thing I've learned is that whenever two or more people gather in Canada to talk about copyright, the first person they mention is Michael Geist :-)

The final talk of the day was again a plenary session. This time the keynote speaker was Dirk Riehle, who leads the Open-Source Research Group at SAP in California. Dirk was speaking on Open Source Economics: Stakeholder Perspectives. This was an excellent presentation, filled with succinct clarifications of terms, clear statements backed up with actual data, and sensible conclusions: a model. Dirk's analysis traced the path from "traditional" Community Open Source (think of the Linux Kernel), to Commercial Open Source and its business models (think MySQL), to New Community Open Source which is similar to the traditional model but has significant integrators involved in the development (think IBM and Eclipse). Dirk's thesis, based on an economic analysis, favours the New Community Open Source Model. Fascinating stuff - I could learn a lot from Dirk.

And that rounds off what for me was a thoroughly enjoyable conference. It's always a treat to meet up with others you've only seen on some project's mailing list, or even just to see how enthused young people are about FOSS and FOSS development communities. It's a positive sign for the future.

[Just a reminder: if you would like to comment on any of these blog posts, please just write to me at randy.metcalfe[at]eifl.net. We'll get the real commenting facility sorted in due course.]

Free Software & Open Source Symposium - Toronto (day1)

I have the good fortune, for once, of living close enough to Toronto to participate in this year's Free Software & Open Source Symposium. Two days of talks on subjects ranging from Open Content: Shared Curricula in a Web 2.0 World, to Reading and Reviewing Code, to Open Source Education in South Africa, and Community Management as Open Source's Core Competency. All that as well as the opportunity to mix and mingle with some of the folks I've only admired virtually to date, such as Louis Suarez-Potts from OpenOffice.org, and Bob Young co-founder of RedHat. With so much accumulated wisdom on hand, I'll certainly be making a point of attending Jesse Hirsh's talk entitled The Problem of Open Source: Know Your History tomorrow.

Day 1

The first talk I was able to attend (misunderstood the driving instructions to the venue - don't ask!) was Code Reading and Reviewing presented by Benjamin Smedberg who is a Platform Developer in the Mozilla Corporation. The talks were running in three parallel stream but this one was a great way for me to start this conference. I'm not a software developer by training or by inclination, so reading code is a real challenge for me. Benjamin did a good job explaining both why reading code is important and how to set about it. You might think that the why there is too obvious for words. But what if I'm primarily wanting to deploy this software as opposed to develop it? If the software is a substantial part of my institution's infrastructure, then knowing how it works ought to be important to me. And understanding how it is written is a key part of knowing how it works. But how should I start reading code in a project I am new to? Benjamin had some good advice. He noted that you need to learn by doing. Start small. Read patches. Try to see how a particular patch works. If possible, follow the code of a single contributor to a project over time. Follow his or her contributions and you will begin to see how someone who understands the code better than you is thinking about the code. Of course it is always an advantage to know your tools. And, you won't be surprised at this last one - learn your coding languages! If you are reading to learn (and this after all is precisely what FOSS always provides, i.e. access to knowledge), then Benjamin suggests that you try to get clear on what it is you are trying to learn, then get the big picture, read the unit tests, try writing a test program, follow the rules, break the rules, ask questions. In short - get involved!

The next talk I attended was Mike Beltzner's Embracing the Chaos: designing for and with community. Mike also works with the Mozilla Corporation as Director of User Experience, so it was an all-Mozilla morning for me. One thing Mike was able to convey perfectly succinctly was why community is so important for Mozilla. Mozilla has about 40 paid staff. But it has a further 100 people contributing code daily on a volunteer basis; there are more than 1000 who are periodic contributors, submitting a bug report or a patch and following it through to its implementation (or rejection); there are at least 10,000 people around the world who test Firefox builds on a daily basis; there are more than 500,000 people who count as beta testers; and finally, there are more than 40 million users of Firefox worldwide, and Mike considers them part of his development community as well. That's a lot of community effort as against the total number of employees from Mozilla. Thus community is important to Mozilla, no question. So how do you go about working well with such a far flung community? Mike had three pieces of advice that he went on to elaborate: 1) listen to your community; 2) lead your community; and 3) let your community play and experiment. Great advice.

Lunch at most conferences is usually a desperate affair for me. Terminally shy, I find it hard to simply strike up conversations with strangers. I was in luck today. I happened to sit down beside Mark Surman who is an Open Philanthropy Fellow at The Shuttleworth Foundation. By a happy coincidence I had a long telephone conversation with Mark about the eIFL-FOSS program and eIFL-FOSS ILS project only a few weeks ago. So it was easy to say hello and meet face-to-face for the first time. Mark's philanthropy extended to introducing me to others over lunch, so I got a chance to meet James Humphreys from Seneca College and David Eaves, who is a prominent blogger, public speaker and consultant on negotiation, strategy, and public policy. I was already planning on attending David's talk tomorrow on Community Management as Open Source's Core Competency so it was nice to meet him in advance and discover he's also a nice guy.

In the afternoon I skipped Mark Surman's talk on Open Sourcing Education in South Africa in order to go to a talk from Ross Turk who is Community Manager at SourceForge.net. That was a mistake. Alas Ross didn't have anything to say about community at all, although I did learn a great deal about how the back-end of SourceForge is cobbled together. Fascinating, but not terribly useful for me (it wasn't that the talk was bad; I was just the wrong audience).

Next up for me was Matt Norwood who is Legal Counsel at the Software Freedom Law Center talking about Licensing Strategies for Cross-Project Collaboration. I was wondering if this might be relevant to the kinds of cross-project collaboration we see these days in Sakai, Moodle, Kuali, etc. But it was really just a thin talk about paying attention to the legal niceties when combining code that is permissively licensed (such as BSD or MIT licensed code) with GPL code. Matt didn't have much to say about licensing strategies. So, once again, I was probably the wrong audience for this talk.

The final talk of the day was a plenary session with Bob Young, co-founder of RedHat and founder of Lulu which provides a platform for self-publishing. Bob is always good value, full of tales of the early days of RedHat and his difficulties in convincing people that giving software away was a plausible business model. He is passionate about freedom but not, as he says, an ideologue. Mostly he is a self-described entrepreneur and so that is what his talk focused on. However, his passions rose to their heights (well, he didn't actually throw anything) when someone asked him his opinion of software patents. I'll give you the short version of his extensive reply: he doesn't like them :-)

It was a good day. I have plenty of praise for the organiser of this event. They've left me very keen for what will come tomorrow.

By the way, photos from the day and video of most of the talks is available from the conference website. So I'll be able to go back this evening and see the talks I should have gone to.

Welcome to the eIFL-FOSS blog

First blog posts are notoriously content-free. But not this one. Instead of just saying, "Hello, world!", I will try to outline how I will be using this blog in future, the kinds of posts you can expect to find, how this blog relates to projects within the eIFL-FOSS program, and how to respond to blog entries. But first, let me tell you who I am.

My name is Randy Metcalfe. I am the Program Manager for eIFL-FOSS.

eIFL-FOSS is a program of eIFL.net which advocates free and open source software (FOSS) use in libraries in developing and transition countries. It aims to raise awareness and understanding of FOSS, facilitate eIFL.net member engagement with FOSS development communities, and undertake projects of special significance to eIFL.net members.

The project of special significance to eIFL.net members that we are undertaking, is a project supporting evaluation of and migration to FOSS integrated library systems (ILS), in particular Koha and Evergreen.

If you decide to follow this blog, perhaps by adding its feed to your favourite blog reader (you can find the urls for the feeds in the top right corner of the main blog page), then you will hear a lot about Koha and Evergreen. You will also hear about various aspects of free and open source software, and of FOSS development, that strike me as particularly salient. You may even have to suffer a few personal posts about conferences I attend, or libraries I, or one of my colleagues, visit. I will be pointing to shining examples of excellence in FOSS deployment or development. I will also be ruminating on the lessons to be learned from less shining examples. But mostly the posts will keep coming back to core issues in the eIFL-FOSS ILS project.

Together with my colleague Tigran Zargaryan, who is the Project Co-ordinator for eIFL-FOSS, and an entire cohort of eIFL-FOSS country co-ordinators, we will be exploring the software available from these FOSS development communities. We will be testing it, piloting it in libraries in different countries, investigating the support documentation currently available, writing some of our own documentation to help each other evaluate our current setups, and eventually migrating to either of these FOSS ILSs. Or not, as the case may be. The goal here is not to migrate to a FOSS solution merely because it is a FOSS solution, but rather because in some particular case it is the best solution. Just how "best" is cashed out there, of course, is likely to be a subject of numerous blog posts.

I will be learning right along with everyone else. In fact, you will quickly discover that I know less about how libraries work than anyone else involved in this program. Some of the folks involved also know considerably more about the technical end of software than I do. Others know considerably more than I do about writing code. But that's not surprising. Any vibrant community - and I hope and trust the eIFL-FOSS community will become one - is made up of people with different histories and skill sets, and probably also differing personalities and preferences. What we share is a common interest in learning how to engage with and participate in FOSS development communities to serve a particular end, our shared itch if you will, to help our libraries serve their users even better.

I hope the above sounds like the kind of blog you might want to stay in touch with. If it does, be sure to add the feed for it to your blog reader. I expect to be posting here at least once per week. And I promise they won't all be as long as this one :-)

Comments for this blog are currently constrained only to registered users of the eIFL.net site. We will probably open that up as soon as we can ensure that we have a way to avoid blog spam. But you can still send me your comments by email, and I will be sure to make mention of them on the blog. You can write to me at randy.metcalfe[at]eifl.net. I look forward to hearing from you.

Oh, and one last thing...Hello, world!