Developers at the Concord Consortium work on a wide variety of grants, and in the process we create reusable pieces of code. With a little work some of these reusable bits of code can be turned into spin-off projects that have a life of their own. In my opinion these spin-off projects have the best potential for broad long-term impact.
Recently I was reminded about these types of spin-off projects when Richard Klancer relayed a conversation he had with Jeremy Ashkenas. Jeremy has been very successful in this area during his work on DocumentCloud.
We strive to make our individual projects successful, but often their technology is complex and not easy to re-use. The impact of the individual project is the research enabled by the technology, or demonstrating the usefulness of a new concept. However, the collection of technologies used in the project normally becomes a one-off: it is no longer used once the project reaches its 2-5 year end.
Alternatively, within these complex projects are reusable pieces of code that are simple, easy to maintain, and solve a common need. Because of this they have potential to be popular outside of our organization. We do have some partial successes with spin-offs like this.
- MozSwing – mostly abandoned, though it was used in at least one commercial product
- Java Sensor Library – collection of JAR files for communicating with a variety of sensors available in schools
- RaphaelViews – SproutCore 1.x library for creating fully fledged SproutCore 1.x views with Raphael
- SproutCore TestDriver – ruby gem for running SproutCore Jasmine and QUnit tests on a CI server
None of these has become a successful open source spin-off project. To be successful, such a project needs an active community that includes both developers and users. And the amount of work required to maintain it by Concord Consortium developers needs to be small enough that it doesn’t prevent us from reaching the goals of individual grant projects.
The MozSwing project would require too much maintenance. The Java sensor project is too intertwined in our other Java code. RaphaelViews and CapybaraTestrunner don’t have the above problems, but they have not been polished and announced to the right audience. I don’t think the polishing would take a lot of effort, but making the time and finding the support to do so is hard. We are always working on the next big thing, so it takes discipline to really finish up what is already working internally.
There are more potential open source spin-off projects within the technology at the Concord Consortium that have wider audiences than the ones above. With luck, we can change our culture to encourage this work more and make more of this great stuff accessible.
Do you agree that we should be spinning off more projects? Do you have experience with spinning off projects like these? Any tips?