The ultimate sprint incentive would be for companies to put up a bounty to fix bugs, or otherwise provide support for an open source project. This is the toughest thing to sell I think, but if Google can do it, why can’t other organizations? I have seen this attempted in the past with mixed results. I think it was a half baked idea, and that we can do better than that. The challenge is metrics, and making sure that everyone gets their fair share. I mean, at that point, sprinting becomes payment for work done, the sprinters are just hired guns for a weekend.
I think the challenge has been, and will always be metrics. How do you measure the work and who did it, and how much is each thing done worth? I think the sprint organizer is the greatest asset in this situation. He usually has the best idea about what needs to be done, what has been done, and ultimately who did what quantity/quality of work. So you can use him as your metric definer.
My idea is this: A sponsoring company provides the OSS organization with a certain amount of money, and what they would like to see achieved in an organized sprint. This money is given to the organization as a donation regardless of the outcome of the sprint. The donation may also be given to the organization with no stipulation of task, but the sprint organizer must choose a topic of interest in order to guide the sprint.
The sprinters all agree to a set method for dissemination of funding provided by the sponsoring organization. My suggestion would be to split all of the funding equally, but in a capitalist nation, it is hard to justify giving the same funding for a person who did a little work on a piece of documentation vs. someone who spent 40 hours putting together a full tutorial. Another method would be to allow the sprint organizer to disseminate the funding as he sees fit, but the sprinters would have to agree to this before work is started. The work would have to be completed by a certain deadline to obtain the funding, because project organizers do not have time to track down who did what 4 months after the fact, it’s just not practical. Finishing a week after a weekend sprint seems reasonable to me.
I am sure to see lots of comments about these ideas because when money gets involved, everyone gets uppity. (one of the great ideas behind OSS is that there is no money paid for the actual software)
So, there exists possibilities for setting up a sort of Round-up style sprint. The goal is to provide sprinters incentive for providing bug fixes, or even to document a part of the code that is otherwise hard to get anyone to document. I would love to open a discussion about this topic, as I see it as a completely different business model when it comes to software development.
But you have to ask yourself, “What’s in it for the company?” Well, first I think you have to ask yourself why Google has been running programs where they pay for OSS development, no questions asked, for 5 years now. But here are some insights while you ponder that. The easiest reason to understand is that the sponsoring company has some bugs in OSS software they use that they need fixed, and a team of experts can fix them in a weekend, or their staff can submit bug fixes, go through the rigamarole of OSS contribution, and things get done in months.
The next less obvious reason for a company to provide funding for a sprint is that they are using OSS software that could use a little help in the documentation department. By paying for documentation, they are getting a cut-rate deal on the experts that usually created the software providing documentation for those things that may be crucial to their business’s success. This also reduces their dependency on any one employee who may have in-depth knowledge on a particular software package. By ensuring the OSS software that the company uses is well documented, the company ensures that the intellectual know-how for that piece of software remains with the project, not with the employee that may leave at some later date.
The last simple reason I can think for a company to sponsor OSS is for recruiting reasons. Typically the people involved in the sprinting process are the ones that know the most about it. It is also be a chance to evaluate an employees enthusiasm for work in general. Those who are sprinters are more likely to work well with others and stay with projects for the long haul, in my experience.
If software development is described as herding cats, gathering and directing sprinters is like herding stray cats. I once had a stray cat visit me when I was in my potato-tuna days, and I gave it some of my tuna, because it looked in worse shape than was I. And you know what, that cat always returned for the tuna. Now, I’m not much of a cat person (current cat count: zero) but I think that if software developers are truly analogous to cats, they might show up at your door once, but it’s much easier to get them to come and visit regularly if you give them some tuna once in a while.
I spent last weekend in Sunnyvale, CA at the GSoC mentor summit. This was a great opportunity to rub elbows with a number of experts in various OSS projects. It was great to make connections with people in and out of the Python community. First off, I just want to thank Google, and Leslie Hawthorne for having us. Google was an excellent host, and I would jump at the chance to attend a Google-hosted event again. Google is using GSoC to promote the open source community. By providing funding for students to work for a summer on software instead of flipping burgers, they hope to save the world, one open source project at a time. I have my own take on what Google’s true intentions are, but I don’t really want to discuss that in this blog entry. That is to say, I don’t think Google’s intentions are in any way evil, but they are definitely self-serving. In any event, it is remarkable the amount of time, energy, and money that goes into this project, which is at this time one of a kind. Here’s hoping that other companies will consider the not-so-small buy in for sponsorship which could lead to even more OSS development.
Mark and I will be attending 
come up to speed on the state of the art, and see if I could find some folks to collaborate with on the Scientific Data Management front. I was not only surprised by the number of people in attendance, but also by the progress being made in forefront of Plone development.
Now that I am back from vacation/new project hell, I have been able to release a new module for TurboGears, tg.ext.silverplate, which is a plugin for TG2 providing User Management and Profile pages which are customizable. This all fits under the TGTools domain, which has become a home for tg.ext.repoze.who (Authentication for TG2) and tg.ext.geo (An upcoming library for Geographical support in TG2). If you get a chance, you might want to check out the new