Contributing to F/OSS and Dogfooding
Scimatic, Tech ·Crossposted from the Scimatic Blog.
Jamie sent me a link to a great review of the Business of Software conference, and before you think I’m going to go off on one of my business-analyst posts, I’m actually going to talk about “dogfooding”. The aforementioned review post talked about the best way to build a software product, and one of the big take-aways is that you have to use your product to develop it well; you have to “eat your own dogfood.” It’s a well-known concept in software development, and we’re well aware of it here at Scimatic.
True enough, but what does that happen to do with open source software? Well, here at Scimatic, we use our fair share of open-source software. We’ve written blog posts about:
- NPlot
- NHibernate, Castle Activerecord and SQLite
- NUnit, SVN, Trac, and CruiseControl.NET
These are all tools and projects that we “dogfood” and use all the time. However, most of these tools are mature projects with teams of people working on them and are feature complete. NHibernate and the Castle stack are great out of the box, and are maintained by some of the best .NET open-source programmers in the .NET ecosystem.
Most open-source projects start out as a single programmer having an itch to scratch, and some of the projects that we are using are at that one- or two-programmer stage. I recently used an open-source C# library for a client project that had about 60% of the functionality that I needed. Since it scratched most of my itch, and I needed to implement the other 40% anyway, I polished up the unit tests a bit, and sent off a patch. Whether the maintainer wants to incorporate the patch … well, I’d be happy to work with him when that time comes. This was a good example of “dogfooding”; I knew exactly what I needed to add to the project, and it was a pretty painless process.
That piece of open-source code was directly usable for my client project, so in that case it was a no-brainer. However, there’s a set of very useful open-source .NET tools that I’m starting to use, but these tools don’t directly pay the bills. For example, here are two good Visual Studio Add-ins:
- Visual NUnit – runs NUnit tests within Visual Studio.
- Trac Explorer – provides an “explorer” view of Trac instances
Each of these projects meets most, but not all, of my needs. For example, I opened this bug report for Visual Nunit. And then I volunteered to try and fix it. It seems like a win-win: I need the fix, and the community gets an improved product.
The one difficulty that I am having is trying to determine how much time to devote to these open-source projects. It’s straight-forward to price out how much an hour of my time is worth in a monetary sense. And additional time with my family is worth just as much. Contributing to open source where there is a direct benefit to customers is also easy to evaluate. This case of developing tools is a bit harder to evaluate, because it’s more difficult to figure out what my “return-on-investment” is. Will running Visual Nunit in the correct configuration save me 30 minutes a day? I have no idea.
There are, of course, the indirect benefits. I get to
- improve my coding,
- read other people’s code,
- develop a set of sample code that I can show to prospective clients,
- hopefully develop a (good) reputation in the community.
And our company gains indirectly as well
- we garner attention for “contributing to the community”
- we can publicise our efforts (for example, through this blog – hey, see what I did there?)
So I will continue to work on these projects. But probably not for hours at a time. Any thoughts on how to evaluate how much time to invest in “off-the-clock” work on F/OSS projects? I’d love to hear from folks out there.
In the end, I hope that we can have a large sample of open source code that we contribute to, like the folks at Hashrocket and 37Signals. So you can see what I’m working on over at GitHub (and I’m learning git as I go). I hope that list of projects grows.