Slashdot Mirror
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.'"'
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?
"We need feature X but we can't afford it so let's get someone to do it for free".
Nice strawman there.
Chances are a company is already using or is about to use an open source application, but just needs a few tweaks to make it fit well. The request is unlikely to come from the board room - it's probably by the IT or operational staff. A manager somewhere will need to sign off the operational or capital expense for the request - just as they would with commercial closed source software - and all the board will see is the P&L sheet.
Open source developers will develop your platform to develop the features they want. It happens naturally
That's a gross simplification. Developers are (usually) humans too, and often enjoy pleasing others and seeing their software adopted. The direction could be set via an online community forum, or specific users requests.
As for the actual request - depending upon the nature of the software and the developers, a "buy everyone pizza" code-a-thon might work. Alternatively the customer might put together a requirements spec, submit it to the developer and receive a formal quotation. The fact that they have to write the check to a .org versus .com makes little difference.
I currently work for a dotcom and love it. You can still find a good dotcom to work for if you have the talent.
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.
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.