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.'"'
But developers have no reason to just work for someone for free.
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.
Esther Schindler is a name I haven't seen in a long time and not one I expected to turn up on Slashdot! I'm pretty sure I can see my "Teach Yourself REXX in 21 Days" book over on my bookshelf from here!
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.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
"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."
I've seen this usually in reference to agile programming. I've seen agile programming used, and I have seen it used badly. Sprints are time boxed units within a scrum format. They're fixed length, start and end at set times, with goals specified within that format. I don't consider "code jams" to be sprints, and it's hard for me to picture 3-5 days as an effective sprint for the newly initiated. One of the first things you're told is the effective percentage of utilization of resources who are new to the sprint, new to the team or new to scrum format is reduced. It is through the iterative process that the people become better, that means multiple sprints to improve and streamline your process. Sprints are a way to prioritize work via planning sessions at the start, and view the good, bad and ugly in the retrospective at the end.
For larger projects this means 3-4 week sprints, with continuity from 1 sprint to the next. It not only requires leadership discipline, but team discipline. It just doesn't seem to be conducive for drawing volunteer work. It isn't a magic glue that allows new people to come together to make code happen.
The security app is actually called SimWitty. It is a security information management system. We got our alpha release sprint sponsored, with t-shirts, tech support, and the like. Getting the app off the ground has been a lot of fun.
As soon as we can figure out how to integrate Redmine with Subversion and Visual Studio, source code will be online. Which reminds me, thank you to the Slashdot audience for the discussion on bug trackers. It was a big help and we tried several before setting on Redmine.
Regards,
J Wolfgang Goerlich