I’ve been using open-source software since the late-nineties – I can still remember the intrigued excitement I felt when my friend Seth first told me about a free system called “Linux”, and showed me the LRP box humming along in his attic. In April, nearly two college degrees, countless thousands of lines of code, and over a decade later, I felt that same excitement when I decided to launch my own open-source project. “Deacon” (short for Droid+Beacon) was on its way to becoming a library for Android developers who wished to add push-notification capability to their Android applications. The Deacon library would avoid requiring the use of any third-party server for push delivery, affording complete autonomy for app developers – and embodying the spirit of freedom and choice that the Android platform represents.
In my years as a member of the free software community, I’ve seen plenty of projects come and go, and even witnessed the rise and fall of an empire or two (yes, Gentoo was my daily-driver for a while). But I never really considered just what the creation of a community around a piece of software would entail. As I tend to do, I oversimplified the concept – just “hang out your shingle” (virtually, of course) and the magic of the Internet will unleash a throng of developers and users at your doorstep. Teamwork would flourish, bright people would contribute inspired code, and all would be right with the world.
In the first week of the Deacon Project’s existence, I pulled some late nights and scraped together everything that – in my experience – I felt an open-source project ought to have. I started with a WordPress-powered web site (deaconproject.org), a hosted repository and project wiki on GitHub, and a mailing list. The blog’s first post painted a picture of the project’s inception, and offered a simple vision for how the Deacon push library would take shape. Within hours, I had my first contributor – my good friend and fellow grad-student, Spencer. A few days later, I received an out-of-the-blue email with another offer to contribute – this time, from Toronto-area software engineer, Android-enthusiast and entrepreneur Faisal Abid. The library began to take shape, with plenty of commits and frequent new blog entries.
It’s been four months since I founded and announced the Deacon project, and the team and I have learned a few lessons about open source projects along the way. The project is admittedly still a fledgling, but if you’re interested in hearing a few impressions from our work so far, feel free to hit the jump…
After launching the Deacon Project, I quickly discovered that I’m far more comfortable wearing a software engineer’s lab coat than a marketer’s suit and tie. But as the founder of a nascent open source project, one must don many hats. You’re not only the chief coder, but also the chief promoter. You don’t just set up the infrastructure, you also set out and evangelize your work. Of course, making our first attempts at Deacon’s design and implementation, and taking a full course load, didn’t leave much time for self-promotion. I ventured back to all the web sites I’d found while initially searching for push options on Android, left comments and posted links. Today, the referral traffic from those links accounts for around a third of the hits to Deacon’s web site.
At some point, I still hope that Deacon will achieve some form of “critical mass” – a self-sustaining momentum fueled by contributions and propagated by adoption. But in software, the concept of “critical mass” is a lot more ephemeral than it is in nuclear physics. To date, the Deacon library files have been downloaded from GitHub a mind-blowing 36 times, but I have no way of knowing whether or not those downloads generated any interest or testing. The blog’s comments have been eerily quiet, though an issue or two has been logged (much to my genuine delight) on our bug tracker. Still, the fact that (potentially) 36 people have taken an interest in what my co-contributors and I have created is amazing to me in itself.
Expect the Unexpected
Not long after Deacon’s first proof-of-concept runs and initial battery impact testing, Spencer and I watched the IO 2010 Keynote #2 from the grad-student lab at RIT as Google announced the new features of Android 2.2, codenamed “Froyo”. One of those features – which had apparently been flying under-the-radar, since we never saw it coming – was Google’s on take on push notifications, called Cloud to Device Messaging (or “C2DM”). Using C2DM, app developers could deliver push notifications to their Android apps through Google’s infrastructure. We looked at each other, and tried to figure out what to do next.
As it turns out, Deacon’s value proposition wasn’t completely clobbered by Google’s announcement of C2DM. From the beginning, we set out to create a means to deliver push notifications that was independent of any third-party servers. The idea: your push notifications from your server, and having a choice in how you push-enable your app. Beyond that, Deacon is also usable in pure-Java form, so developers of Java apps can use it to deliver push notifications as well. And all those hundreds of thousands of handsets that don’t (and in all likelihood won’t) run the Froyo version of Android? Deacon can be used to push-enable apps on those devices, too.
The point? I’m not suggesting that open source projects start going gonzo with inception-phase due-diligence, market analysis and contingency plans. But having a solid vision of what you want to build, and why you want to build it, will help you stand your ground when the unexpected happens.
It’s about People
As it says on Deacon’s “core team” page, free and open-source software wouldn’t exist without the people and communities that make it happen. That means that at some point, you’re going to have to actually interact with some people in order to make your project happen! When the opportunity to give a lightning talk at Interlock Rochester (a multi-disciplinary maker-space and really cool group of people) surfaced, Spencer and I threw some slides together and spent our five minutes talking up Deacon. (If you want to check it out, the slides and talk are both online.) By the same token, it’s also people that ultimately use the Deacon library, so I thought a simple screencast on push-enabling your app with Deacon might also be helpful.
But more than just talking to people, and making things for people, and hopefully enabling people to do cool things with the cool things you’ve made, I think free software is about connecting with people. Android fan(atic)s have a shared passion, and I get a strong sense of it when I talk to Spencer and Faisal. In a lot of cases, that shared passion and motivation is the fuel that gets free software projects off the ground, helps them build momentum, and ultimately makes them successful. Sure, there are plenty of free software projects out there that are developed by an “army of one” (or two, or three), and that “boutique” status might end up being Deacon’s lot in life. There are also projects that get swallowed up by bigger ones – as could also happen with Deacon and the Meteor web server project to which it acts as client. And that brings me to my last thought on starting an open source project: trust your idea. It’s the same thing quarterback-turned-entrepreneur Drew Brees says of crazy business concepts. Even if your project never makes it past proof-of-concept, treat it like it’s the next Apache, or Subversion, or even the next Linux. That doesn’t mean “aim for the stars” or “you are a beautiful and unique snowflake” or any fuzzy stuff like that – it just means that you need to do the same thing that the people behind Apache and Subversion and Linux did when they started out: do something meaningful, do it with a purpose, and do it well.
[Teamwork image: Wikimedia Commons, Public domain]