So I’ve been checking out Tomboy, a lightweight Mono based note-taking application for Linux and was initially pleased with the functionality, only to have it kick out an unhandled exception error and not run after a reboot. Given that it’s a 0.1 version of the app, I didn’t think much of it – just submitted a bug notice via email last Sunday at 9:31 PM and figured I’d be waiting for a while. Come in Monday morning to find that a fix was posted at 2:32 AM (about 5 hrs later) by the primary developer, Alex Graveley.
Sounded great. Problem was, there was a hard requirement in the new version for a spell-checking widget that I didn’t have the right version of so the new package wouldn’t compile for me. So I submitted that to the list at 11:03 AM Monday and figured I’d check back in later. Meaning days – or weeks – later. Hopped my train down to NYC, spent Tuesday at Sun’s event there, and managed to sneak a few minutes of free time in to check my email using the W’s Wi-Fi.
What do I find? Updated version of the application with the hard requirement removed, posted at 10:29 AM, Tuesday. Installed beautifully, and I’m using it as my note-taker for the moment.
And that’s the beauty of the open source model; things happen quickly and transparently. None of this is news, of course – this same scenario is repeated thousands of time every day. Basically I’m a glorified tester – willing to try new software and provide feedback in return for functionality and early access to an application.
But it was interesting to me in that I participated in what amounts to the equivalent program with Microsoft’s OneNote product (please note, however, that the programs themselves are not comparable). Contrasting my Tomboy experience with the Microsoft OneNote beta program – anyone’s who’s talked to me about OneNote knows I love that application – is instructive. In the open source model:
1. I gave feedback to the actual developer(s), as opposed to an impersonal web survey
2. I received feedback/pushback directly from the developer in real time, versus no real feedback from my OneNote suggestions
3. I see the acceptance/rejection of my suggestions and the rationale behind them, rather than not having any idea why my requested features didn’t make it into OneNote
Now this is but one example, and I wouldn’t try to make the case that this single MS Beta program was indicative of their larger efforts, but it did illustrate, once again, the value of transparency. I heard similar comments at a Sun event in Burlington last week, where James Dobson from Dartmouth spoke glowingly of getting feedback on a bug report directly from the Solaris kernel developers.
What’s the takeaway? Seems to me that every ISV should think about mechanisms for tearing down the barriers between their developers and the folks that run the code. It’s an idea fraught with issues, yes – how does it scale? feedback quality varies, etc. But I’d much rather be too open than too closed at this point. Transparency rules.
Update: I should have mentioned, because I subscribed to his blog when he was posting frequently (unsubbed because the posts came less and less frequently), that Chris Pratley of the OneNote team has a blog here where he did post on many of the decisions behind certain features. This was a great augmentation to the impersonal beta emails I spoke of; but the problem was that it can’t match the real time nature of the email interchange. Microsoft – via Scoble’s evangelism and a general trend towards better transparency – does appear to ‘get’ blogs, and Pratley when he was posting more frequently was an excellent indication of this. But they need to do more to tear down those walls.
