On Jun 8, 2016, at 1:55 AM, Kyle Banerjee <kyle.baner...@gmail.com> wrote:

> My recollection is that in the bad 'ol days, c4l was much more about sharing 
> ideas to solve practical problems… Nowadays, the conference (which has become 
> like other library conferences) has become an end in itself…

In the spirit of open source software and open access publishing, I suggest we 
earnestly try to practice DIY — do it yourself -- before other types of 
formalization be put into place.

I was struck by Kyle’s statement, “the conference has become an end in itself”, 
and the more I think about it, the more I think this has become true. The 
problem to solve is not identifying a fiduciary for the annual conference. The 
problems to solve surround communication and sharing. A (large) annual 
conference is not the answer to these problems, but rather it is one possible 

Unless somebody steps up to the plate, then I suggest we forego the annual 
meeting and try a more DIY approach for a limited period of time, say two or 
three years. More specifically, I suggest more time & earnest effort be spent 
on local or regional meetings. Hosting a local/regional meeting is not 
difficult and relatively inexpensive. Here’s how:

  1) Identify one or two regional leaders - These are people who will 
initialize and coordinate events. They find & recruit other people to 
participate. Sure, they require “spare cycles", but they do not have to keep 
this responsibility past a single event.

  2) Create/maintain a Web presence - This is a Web page and/or a mailing list. 
These tools will be communication conduits. Keep the Web page up-to-date on the 
status of the event. Refer to it in almost every email message. Use it to 
record what will happen as well as what did happen. The mailing list can start 
out as someone’s address book, but it can grow to an mail alias on a Linux 
machine or even a Google Group. The Web page can live in the Code4Lib wiki.

  3) Communicate - Kind of like voting in Chicago, “Talk early. Talk often.” 
This is essential, and can hardly be done too much. People delete email. People 
don’t plan ahead. People think they are not available, then at the last minute 
they are. The reverse happens too. Send communications about your event often, 
very often. Use email to build a local/regional community. Share with them your 
intention as early as Step #1. Keep people informed. 

  4) Identify a venue — Find a place to have the event. Colleges, universities, 
and municipal libraries are good choices. Ideally they should be associated 
with the output of Step #1. The meeting space has to accommodate fifty people 
(more or less), but bigger is not necessarily better. The space can be an 
auditorium, a meeting room, many meeting rooms, or any combination. The space 
requires excellent network connectivity. A meeting space sans strong wi-fi is 

  5) Identify a time - The meeting itself needs to be at least one afternoon 
long. A day is good. More than two full days becomes a bit difficult. Starting 
at times like noon allows people to have traveling time, or for folks who 
arrived the night before time to get oriented. Starting at nine and ending at 5 
makes for a nice full day. Ending the meeting around noon makes it easy for 
people to travel back home. Host the event on a weekday and maybe ending on a 
Saturday. This is professional work, and it may be fun & interesting, but it 
should not require vacation leave.† 

  6) Outline an agenda - The agenda embodies "la raison d’être”. The agenda is 
a tool for facilitating the communication and sharing. Put it on the Web page. 
Allow others to fill it in. Outline show & tell sessions of various lengths. 
Recruit people who you know are doing interesting things. Be prepared to show 
one or two things from the local institution. Do show & tell on things other 
than computers in libraries. Give tours of local cool stuff, like an archive, 
special collection, museum, maker space, or even churches. These tours are less 
about the showing of the stuff as they are about enabling communication of the 
attendees. Do you really think people are not going to talk work while gazing 
at a painting? Identify concrete (library) problems to solve, and these form 
the basis of hack sessions. Do the “unconference” thing. Take hints from 
THATCamps. Do roundtable discussions and have reporting back sessions. Bring in 
people outside computing but inside the hosting community, and learning by 
everybody will take place.

  7) Identify how to eat - Going to one more more restaurants/bars for lunch or 
in the evening is a very good thing. When it comes to lunch, people can go out 
on their own, or the hosting institution may want to sponsor. Cookies and 
snacks during the day are good things, but not necessary. Shy away from 
caterers. They are expensive. Take the same money, go to the grocery store, and 
buy things to eat. Make reservations in restaurants for larger groups.

  8) Do the event - On the day of the event, make sure you have name tags, 
lists of attendees, and logistical instructions such as connecting to the 
wi-fi. Have volunteers who want to help greet attendees, organize eating 
events, or lead tours. That is easy. Libraries are full of “service-oriented 
people”. Use the agenda as an outline, not a rule book. Smile. Breath. Have 
fun. Play host to a party. Understand the problem you are trying to solve — 
communication & sharing. Let it flow. Don’t constantly ask yourself, “What if…” 
because if you do, then I’m going to ask you, “What are you going to do if a 
cow comes into the library?” and I’m going to expect an answer. 

  9) Record the event - Have people take notes on the sessions, and then hope 
they write up their notes for later publishing. Video streaming is expensive 
and over the top. Gather up people’s presentation materials and republish them.

 10) End the event - Graciously say good-bye, clean up, and rest. Put the 
coordination on your vita and as a part of your annual review.

 11) Evaluate - Follow-up with the people who attended. Ask them what they 
thought worked well and didn’t work well. Record this feedback on the Web page. 
This is all a part of the communication process.

 12) Repeat - Go to Step #1 because this is a never-ending process. 

Now let’s talk about attendee costs. A national meeting almost always requires 
airfare, so we are talking at least a couple hundred dollars. Then there is the 
stay in the “cool” hotel which is at least another hundred dollars per night. 
Taxi fare. Meals. Registration. Etc. Seriously, how much are you going to 
spend? Think about spending that same amount of money more directly for the 
local/regional meeting. If you really wanted to, coordinate with your 
colleagues and sponsor a caterer. Carpool with your colleagues to the event. 
Coordinate with your colleagues and sponsor a tour. Coordinate with your 
colleagues and sponsor video streaming. In the end, I’m positive everybody will 
spend less money.

What do you get? In the end you get a whole lot of professional networking with 
a relatively small group of people. And since they are regional, you will 
continue relationships with them. Want to network with people outside your 
region? No problem. Look on the Code4Lib wiki, see what's playing next, and 
attend the meeting.

Instead of centralization — like older mainframe types of computing — I suggest 
we embrace the ideas of de-centralization a la the Internet and TCP/IP. This 
way, there is no central thing to break, and everything will just find another 
path to get to where it is going. Instead of one large system — let’s call it 
the integrated library system — let’s employ the Unix Way and have lots of 
tools that do one thing and one thing well. When smaller, lesser expensive 
scholarly journal publishers get tired and find the burden to cumbersome, what 
do they do? They associate themselves with a sort of fiduciary who takes on 
financial responsibilities as well as provides a bit of safety. And then what 
happens to those publications? Hmmm… Can anybody say, “Serials pricing crisis?”

Let’s forgo identifying a fiduciary for a while. What will they facilitate? The 
funding of a large meeting space in a “fancy” hotel? Is that really necessary 
when the same communication & sharing can be done on a smaller, lesser 
expensive, and more intimate scale? DIY. 

† Here’s a really tricky idea. Do what the TEI people do. Identify a time and 
place where many similar people are having a meeting, and then sponsor a 
Code4Lib-specific event on either end of the first meeting. NASIG? DLF? ACRL? 
Call it a symbiotic relationship.

Eric Lease Morgan

Reply via email to