A year ago, I started a new chapter in life – pursuing a master’s degree in software engineering. My reason for returning to school: I could do a clean-sheet design for a piece of electronic hardware, but the same wasn’t so for software – and there was software in nearly everything I was creating. So, I left my cooshy job, turned in my comfy car and spent the year that followed studying my ass off.

As of yesterday, that chapter is over. My degree is finished, 64 credits and 12 months later. And I realize, in much the same way as I was never alone in my decade as a medic, that you never really start from nothing. In the software world – as in the engineering world in general – you build on the shoulders of the great people who came before you. Gauss, Tesla, Maxwell, Ohm and Shockley were all with me as I designed circuits, just as Gamma, Bass, Booch, Pressman and their cohorts have my back when it comes to creating software. Among other realizations, this past year has brought me the understanding that there’s no such thing as a clean-sheet design in the first place.

Next week, I’ll start a new job, working on new projects in the company of new friends and partners in innovation. It’s an exciting time, built not just on the foundation of intellect and creativity, but also on love and support: so my family and friends, and especially my Dad and Kelly, deserve the most thanks of all.

But something wasn’t right. My specimen of this particular chair didn’t feel quite the same as those ringing the conference room table. After 5 minutes, I realized the difference – the lumbar “support” piece – a D-shaped springy plastic affair upon which the chair’s poly-mesh back rested – felt like a yardstick pressed into my vertebrae. Far from the super-adjustable high-end version of the chair I’d first experienced, I realized I had purchased a much more basic model on which this lumbar support was fixed. And held in place by a T30 bolt.

Which is how I found myself at Sears an hour-or-so later, in search of a new set of Torx drivers. In order to remove the offending lumbar support piece, I’d need to remove the bolt through an opening too-small for my interchangeable-bit screwdriver. And as I surveyed the options in the “six-sided fastener-adjusting tools” section, I noticed a selection of various hex-key sets. Ever since my loose 5mm hex key – an essential tool for bicycle maintenance – went missing, I’d been meaning to remedy its absence. This is how men shop.

Hoping to avoid the loss of another loose 5mm key, I opted for a fold-up style set. I had two options: a SAE/metric pair from Allen brand (“The Original!” exclaimed the packaging) for $9.99, or the same array of sizes with Craftsman branding for $25.99. Both carried lifetime warranties. Both seemed durable enough. Both had ball-style ends. Both even had little accessory tabs that could be used to hang the tool from a pegboard. The difference? The former was made in China, and the later in Estes, Illinois.

I set down the set of Torx wrenches and picked up both of the hex-key contenders, realizing that this was fast becoming a “practice what you preach” moment. As far as “things we buy” go, there aren’t that many things sold that are still manufactured domestically. Our government has made it all-but-impossible to do business profitably in this country, and what roadblocks they haven’t put up, labor unions have. So when the issue of buying American-made goods comes up, I enthusiastically advocate for it – and even more so for “buying local” if one can. And now I had a simple choice: pay more or compromise.

I hung the Allen-brand wrench set back on its hook and headed to the checkout counter. The total bill for 10 American-made hand tools was $69.84. Just under $7 per tool, or under $3 each if you count each key on the folding sets individually. And while I realize that my purchase doesn’t affect much of anything on a global scale, it does amount to a single ballot in a very large game of vote-with-your-wallet.

And that new chair? Turns out it was made in Zeeland, Michigan.

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…

Critical Mass

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]

Ubuntu from Keith Kenniff on Vimeo.

Over the last couple of years, I’ve watched Linux advertisement competitions – such as the annual contest from the Linux Foundation – with interest. And every year, I’m hugely disappointed. The videos submitted are generally poorly-produced, based on obscure concepts or just downright cheesy. But this one – while it’s a little dated (Ubuntu 10.04 is out now, and we’re just a few months from 10.10) and not quite up to ad-agency quality – I think it’s the most competent thing we’ve seen in a long time. Of course, if you want to see what happens when the heavy-hitters take out their wallets, take a look at these legends:

As it turns out, the training time I put in this year paid off: I finished the sport class race in 52 minutes, 20 seconds – an improvement over last year’s time over almost 19 minutes! In all, it was a fantastically fun race, and it set the bar for how hard I can push myself. Jason showed some time improvement, too – he clocked in at 47:30, shaving several minutes of his 2009 time.

You can check out more photos from the race at dougrea.com.

Right around this time tomorrow morning, I should be biting into my second lap around the Fat Tire Festival course. And at the moment, it appears there will only be two laps in the race; an embarrassed-sounding e-mail from GROC, yesterday, revised the lap count back to last year’s tally. So, 10 miles of pedals, brakes, dirt and lactic acid…here we come!

This update will be brief, as my alarm is set – by necessity – to an ungodly hour tomorrow. Got the hydration pack all fixed up, tossed some Clif Bloks in my pocket and headed out for my final Fat Tire training ride. Three laps, 1 hour and 37 minutes. I was hoping for under 30 minutes per lap, but by the time I finished, I was just glad I’d gotten through it!

Apparently my GPS app (Google MyTracks) crashed a little ways into the second lap, so the map below – aside from looking a hell of a lot like all the previous maps – doesn’t really show the full extent of the agony…

Tomorrow and Friday I’ll be staying clear of the bike, and a few short hours after a big spaghetti dinner on Friday night, it’ll be time to hit the trails for the real deal! If I haven’t already badgered you by e-mail, consider this your invitation to come on out to the Fat Tire Festival, have some chow, enjoy some music, make some noise and watch Jason and I beat ourselves to a pulp! The show starts at 9:05AM on Saturday the 17th.

If today’s ride can be summed up in one word, I would have trouble choosing between “calamity” and “trainwreck” … It started off with my skipping the usual route through the sports fields, since some sort of day camp had transposed several hundred kids onto them. My start was interrupted by the realization that I’d forgotten to leave my wallet in the car, and my first climb by the realization that nature was calling. Crossing the fields at the highest point on the course, I went for a drink and realized the Nalgene-type bite valve on my hydration pack was in the “off” position – and managed to pull it clean off the hose when I hit a bump trying to twist it to “on”.

This resulted in a brief shower as I grabbed a handful of brake and dragged the bike to a stop, then pinched off the tube. After five minutes’ worth of searching left me empty-handed, I tried blowing air into the tube and pressing on – only to get drenched a few more times. After climbing the next hill, I opted to dump most of the water and cut the ride down to one lap of the course. About 50 ounces of water lighter, I pushed through the rest of the first lap.

• Date: July 12th, 2010
• Distance: 5 miles
• Time: 32:13
• Elevation gain: 645 feet
• Thoughts on starting: This is going to be a good ride. Has to be. It’s too nice a day for anything else.
• Thoughts on finishing: This is why we train! To work out the kinks!

Of course, when I got home, I checked out the Fat Tire Festival web site and made a startling realization: The sport-class race is actually three laps of the course, not the two I’ve been planning for! This weekend…will be very interesting!

(The middle photo shows my bite valve search effort…)

…is not what I had in mind for Fat Tire training ride 5.

We don’t get to control the weather on race-day, and that’s a perfectly good reason to go train in the rain, but with the amount of water hitting the ground today, I’d rather not tear up the trails. This weekend will bring a 45-mile skinny-tire hike around Keuka Lake, so unless things miraculously clear up before about 7PM, training ride 5 will be happening on Monday.

Far more prepared for a ride than when I set out on #3, yesterday’s training ride went surprisingly well – despite the 96° temperature outside! I made sure to prehydrate before hand, and took some extra time to stretch. Ride #4 was my first two-lap attempt.

Training Ride 4

• Date: July 7th, 2010
• Distance: 10 miles
• Time: 1:07:04 (including warm-up and two holy-crap-sweaty-eyes-can’t-see stops)
• Elevation gain: 1,544 feet
• Thoughts on starting: Just go slow. This isn’t the race. Just have fun. Really. I mean it.
• Thoughts on finishing: Yeah, two laps hurts about twice as much as one lap hurts…

Interestingly, I think I felt a true, honest-to-goodness “second wind” about 60% of the way through this ride. It didn’t feel like I expected – a big burst of “I can do anything!” energy – actually, it was more like a sudden transition from “not being there” to “being there”. I went from repeatedly reminding myself not to stare at the ground passing below my bottom bracket (“that’s history by the time you’ve seen it!”) to actually being in the ride again! Of course, it only lasted ’till about 80% of the distance, but that was enough to get me through the toughest of the climbs, and on my way to the final descent.