Open Ed 09 just ended, and I’ve got lots of things to blog about. Here’s a quick one that came out of a conversation that I had this morning with some of the guys from UBC’s Office of Learning Technologies (Enej, Michael, and Alex, if I’m remembering correctly).
The conversation started off as a show-off session of the different things we were doing with the combinations of WPMu, BuddyPress, MediaWiki, and so on. After some oohing and aahing (that’s what I was doing, at least), we turned to the question of why we – groups of people doing such complementary stuff – aren’t in better contact with each other. Finished, polished stuff is pretty easy to share, through outlets like the WordPress plugin pages. Only sharing the big stuff, though, means only helping each other a fraction of what we could. After all, things that have been formally released are bound not to need as much input from the community as unfinished, rough code. Moreover, arguably, our days are consumed as much by the small hacks and workarounds as they are by the big plugin projects.
cc licensed flickr photo shared by Stevie Rocco | Drinking this coffee got me giddy about sharing code
Communication about code is a hard thing. On one end of the spectrum is internal communication. The gang at OLT keeps internal notes of the small hacks they do on their system, as do we at the CUNY Academic Commons. On the other end is end-user documentation, meant for a broad and largely non-technical audience. The kind of communication that’s missing here is the stuff in the middle, between groups doing similar sorts of work.
What are some good ways to get this kind of sharing moving? What we’re trying to do at the Academic Commons is to keep a development blog. The success of this strategy is limited by a couple factors, though. First, other people have to know where the blog is, and add its feed to their readers, to glean any benefits. Second, a dev blog is only as good as what you post to it, and I for one have a real tendency to think that lots of things are simply too small to bother with. As a result, only the big things tend to get posted – but then we run up against the problem I mention above.
So here’s a rule that I’m setting for myself: If an issue/hack/workaround/patch/spitshine takes more than two hours for me to figure out, I’m going to blog about it. The more I put out there – even if I think that it’s not all that significant – the more likely someone else is to find it and make use of it.