I have been writing bits of code, large and small, for nearly 20 years now, and many of them are available somewhere on the web under more-or-less free licences. In recent years, especially since OSS Watch started, I have increasingly tried to get to grips with proper licensing and ownership, and now regard myself as “clean” as regards the licences. However, a lot of what I have produced has been in TiLi (Take it or Leave it) mode, under which I worked on changes at my own pace and in my own way. I know that in a proper open source project I will work according to a roadmap and to standards, but for my off-hand, part-time, work?
I have been using Operator recently; this is a brilliant Firefox extension which trawls each web page for microformats and shows you what it finds. It is written by Michael Kaply; he works for IBM, but it is fairly clear that this is a fun project he does on the side. You’d expect a TiLi mode of development for this type of work. Earlier this year, however, Michael published his personal Social Contract, which lays down the constraints he will impose on himself for Operator. For example, he says “I will modify the method I use to debug Operator to ensure that I do not accidentally leave debug messages in the extension when I ship”, and “I will not commit to any specific day to release an update to Operator” as well as the, perhaps expected, “I will take all bug reports seriously and attempt to solve them”. Marvellous. Precise rules which we users can understand, and which he can realistically stick to.
Read more about Kaply’s Social Contract at
http://www.kaply.com/weblog/2007/01/10/extension-development-and-social-contracts/
I think I too will write such a contract next time I publish some code.
Is your TiLi work your own or does it belong to your employer? And if the latter, then perhaps the ’social contract’ you will want to write is some kind of commitment to (internal, at least) openness and sharing of code within your workplace.
The Apache Software Foundation (ASF) has a brand new concept (about a month old) called Apache Labs. The idea is that ASF committers can create new projects that they do not, at this time, intend to develop into full blown Open Source projects with a community etc.
These projects are typically small projects that may be of interest to others, but which are unlikely to gain enough attention from the original author to become viable projects. In other words their TiLi projects. The idea is get the code out there and see if anyone else wants to pick it up. There is a single mailing list for all labs projects and very loose project guidelines that only really care about legal issues. No requirement for a website, complete documentation, community development etc.
The Apache Labs does not allow just any old project into its infrastructure, there are some controls, i.e. there has to be some complete funtionality. But there is very little requirement for ongoing maintenance of the code.
The benefit of labs is that it enables ASF committers to utilise the ASF infrastructure for their own TiLit work. Other people can get at the code and learn from it or work with it if they want. Should a project find a community is developing around it that project is moved to the Apache Incubator where there are requirements for creating a proper open source infrastructure.
Perhaps you should consider encouraging your employer to set up a “labs” project for you and your colleagues to share TiLi projects. After all, it won’t help anyone sitting on your hard drive.
The most interesting part of Kaply’s Social Contract is:
In other words:
Everyone who has any kind of software engineering or computer science training knows they should be testing, but seeing the actual order of priorities is interesting.