How To Sponsor an Open Source Sprint

Esther Schindler writes "Does your favorite open source project need just a little extra functionality? As Esther Schindler explains in this IT World article, your company can encourage the developers to add the features you've been yearning for — for far, far less money than you imagine. She interviews companies who have sponsored 'code-a-thons' for Drupal, Plone, simwiddy, and a set of applications for British Telecom, and provides specific pointers. From the article: 'To ensure that the event happens and that it meets its goals, you must connect with the right members of the community and motivate them to work with you. "It's not like these people are paid to work for your interests," points out Brightcove's Whatcott. If your business already has project committers on its staff, then it's just a matter of leveraging existing relationships. But, says Stahl, "Someone less 'core' in the community might well have a harder time.'"'

Comments

um

[Brian Gordon]

Courting OSS developers is good when you do it like Google: give them exciting tools and let them solve their own problems with it. Problems get solved, code gets written, and Google gets free work done!

But developers have no reason to just work for someone for free.

your company can encourage the developers to add the features you've been yearning for â" for far, far less money than you imagine

This should never happen in a board meeting: "We need feature X but we can't afford it so let's get someone to do it for free". Open source developers will develop your platform to develop the features they want. It happens naturally; you can't just buy everyone pizza and sit them down and tell them to get to work.

Re:um

[ushering05401]

The whole article seems wrongheaded in exactly the way you point out.

Let's see how many people can figure out the target audience of this article... So lets see..

1. We are targeting an audience that doesn't know what a Code Jam is:

A sprint (sometimes called a Code Jam or hack-a-thon) is a short time period (three to five days) during which software developers work on a particular chunk of functionality.

2. This audience doesn't know why an IT manager might want a code jam, but hey, it might be cheap! :

For many IT managers, the most compelling reason for the company to sponsor a sprint is financial, because you just might be able to cover the costs out of petty cash.

3. The target audience is likely to relate to a comparison of the cost of this 'Code Jam' to monthly marketing costs, specifically, client
dinners :

In short: In an open source sprint, you can add new functionality to your most important application for less money than your marketing department spent last month on a single fancy client dinner.

Any guesses on who this author wants to start trying to exploit the OSS dev webs?

Re:um

[physicsphairy]

It happens naturally; you can't just buy everyone pizza and sit them down and tell them to get to work.

I totally agree. We have our pride, dammit!

But, um, just between you and me... what sort of toppings are we talking about?

Re:um

[gujo-odori]

Instead of pizza, I would suggest cash.

Some years ago, I was working for an ISP that was looking to replace its webmail interface, which was not only aging, creaking, and proprietary, but had a one-off hack grafted onto it by someone who no longer worked there in order to make it work in Japanese. That hack prevent upgrading, and since the person who'd written had left under, well, less than ideal circumstances, there would have been zero interest on either side in getting him to update it. It was so badly written that no one could even figure it out.

So, the decision was made to replace it and I was tasked with finding the replacement. Working perfectly in English and Japanese, and having (at least) an E-J bilingual UI out of the box was a core requirement. After looking at a lot of things, IlohaMail (http://ilohamail.org/) seemed like the best choice, except for one problem: at that time, it only supported IMAP, and POP3 access was also a core requirement for us.

So, I went to the engineering manager with the recommendation that we choose IlohaMail and pay the developer to add POP3 support and GPL it as part of the main IlohaMail package. I got a greenlight for that, and that's how POP3 support came to be in IlohaMail. I don't recall the exact dates of this, but I left that job in the Fall of 2002 and IlohaMail had already been up and running for some time before I left.

The point of this narrative is that if a company likes some Free software project but it lacks one or more features they need or want very badly, going to the author(s) and paying them to implement those features in the mainline of the project can be very effective. Not many things are better in work than to get paid for working on a project you like so much you do it for free anyway, especially when you are getting paid to work on it in complete freedom. It's sort of like being a professional fisherman or poker player, minus the grueling life on the tournament circuit. OK, the BASS tour is probably more grueling than the the poker circuit, but both are life on the road.

So rather than a sprint, done by people who may have no prior involvement in a project, funding development of features you want may be the most effective way to go. Will it cost more than a sprint? Probably. Will it yield better results? Certainly. You're not only getting the work done by those most familiar with the project, you're getting done exactly what you want done.

In case of objections along the lines of "But if we fund Free development, our competitors will be able to use the same features we do!" the counterarguments are:

-Yes, in theory, but we will still have the jump on them because we are funding these features and will be prepared to use them as soon as they are available because we know they are coming. This is true even for competitors who are already using it;

-That assumes that our competitors not only know about this project, but will want to use it in place of whatever they are using now;

-It also assumes they can execute on these features better than we can. Since we want these features and already know how we are going to use them, that probably won't be the case; ...

-Your concerns are well-taken and prudent, but for the reasons outlined above, even if our competitors pick up on these features and use them, we will execute more effectively, and may also gain a certain amount of good will in some quarters as the funder of these new features.

Will code for Pizza

[Archangel Michael]

you can't just buy everyone pizza and sit them down and tell them to get to work.

Have you seen the job situation? Nearly 10% Unemployment!

The glamor days of the DOTCOM era are long ago gone. I know a few code monkeys who'd code for free if it meant getting a chance at a real paying job, and to get a pizza for dinner.

Only for trivial stuff, or you'll get junk.

[Animats]

This isn't likely to work for anything that needs to be architected, or is at all complex. What you're going to get, at best, is a collection of un-integrated features in search of a design. Of course, for some applications, that's good enough.

PyPy, the Python implementation written in Python, was developed in big "sprints". Six years on, it still doesn't work well enough to be used for anything.

There are too many bad programmers out there for "crowdsourcing" to work well. I put a moderately simple job on Rent-A-Coder once - I wanted an open source Python program to read WHOIS data from any registrars. This requires a tiny module for each registrar, and after writing a few myself I decided to outsource the next hundred registrar-specific modules. Four "Rent-A-Coder" programmers failed on that job.

Sprint considered harmful

[Ckwop]

Can we stop letting hypsters and random pointy-haired bosses define the language we use in our field?

I know "sprint" is meant to conjure up images of panting programmers tired after 3-4 days of grueling labour; togeether, they stand there at the end of the sprint feeling triumphant for winning the race and standing proud with the little, tiny, piece of the system they've built together.

However, to me at least, the term just sounds monumentally stupid. It's one of those "smoke and mirrors" kind of business words, where you re-label all the terminology everyone already uses to make it sound like you're doing something new and exciting. It's the kind of newsspeak that allows business people to find each other. Am I the only person who cringes when they hear the term "Scrum Master?"

I have a very useful "time box." It's called a week. It lasts seven days, two of which I rest in. It's quite a useful timebox because it is constant across all development teams, everywhere in the world! Fancy that.