Those who know me personally know that the past year was a bit of an uphill struggle. In addition to battling my Crohn’s disease last year, I was the lead on a project to implement a learning object repository here in B.C. based on some code another university had created. The partnership did not work out as hoped, and after 7 months we finally decided to cancel our involvement in the project.
We’ve moved on and should be announcing our choice of software to implement that same LOR in the not too distant future. But when things go the way they’ve gone, the least one can do is try and learn from the mistakes, and hopefully share that learning.
Hence this post. The lesson is exactly what’s stated in the title, and I certainly feel all the more boneheaded for admitting I had to learn it the hard way. And the lesson is this – at the moment you declare a project to be “open source” the source code better be available for download somewhere. Period. None of this “well, we’re just going to get it to this certain point before we release it, but really, it’s open source.” Sorry, no. I understand the desire to get things ‘just right’ before others see it, and the desire to take code that’s been written for a specific instance (and thus probably has all sorts of shortcuts and not-so-great practices in it) and make it more ‘generalizable’ before the public gets their hands on it. But these urges need to be resisted. If you’re serious about something being ‘open source’ then realize that part of the openness means a development practice that’s literally ‘out in the open,’ open for scrutiny (and also for people to pick up on their own, without having to enter into political or economic relationships with you ahead of time.) It’s clear that releasing something that works, or that at least is comprehensible, provides a big leg up for open source projects that are just starting up, so by all means get your code to that point before you declare it’s an open source project. Just don’t declare it to be ‘open source’ and then keep developing it in secret.
I expect there’s a lot of folks who will read this and go “well duh!” Like I said, it feels boneheaded to have to admit to learning this the hard way. I fell for the argument that one could talk about releasing something as open source “when it was ready” while all the while toiling away in private. And yet, the number of projects I continue to come across, that keep doing exactly this (“Yes ours is an open source project” “oh, so where can I download the code from” “oh, it’s not ready for release yet”) leads me to believe I’m not the only one who’s ever been sold this bill of goods. It’s important to do this, not just because literally it’s the very definition of “open source,” but because it recognizes that fundamentally, “open source” is as much about a form of software development practice and social organization as it is about a form of software license (which in the end is simply the precondition for the phenomenon). And while you may feel awkward about making your mistakes out in the open, it’s easier to work that way if you’re already working that way, instead of having to invent a process and openness that wasn’t there from the start. – SWL