It's probably most common for organizations to give developers a conference room and regularly slide pizza under the door, because a sprint's purpose is to put people in the same place to work concurrently on a problem. But other organizations embrace a more virtual approach. When company president Abizer Rasheed arranged for Netfusions, a division of Computers & Concepts in Keego Harbor, MI, to sponsor development on the open source security project SimWitty, he decided to orchestrate a two-week remote project whereby participants - in this case, primarily college students - worked from their homes. Rasheed set a budget of about $500 to cover logistics such as a file repository, collaboration tools, t-shirts and software.
"Remote teams" can be very remote indeed. In May, outsourcing company Globant organized a one-day hack-a-thon with the British Telecom (BT) Osmosoft Open Source Innovation Team to release an open source project called MediaWikiUnplugged, explained CTO Guibert Englebienne. Two teams, in London UK and in Buenos Aires Argentina, were connected full time with Skype and video, and well-supplied with a conference room, floor-to-ceiling white boards, pizza, and beer. (Do you notice a recurring beer theme?) Globant really got into the spirit of the thing: they brought champagne and gave away a balloon ride to one lucky developer.
Getting the community on board
Naturally, a sprint needs a clear objective that appeals to both your company and to the project at large. You won't attract open source developers to your office to work on a code component they don't care about, so your objectives must align with theirs.
Open to all or invite-only?
One issue in organizing a sprint is participant expertise. Do you want an event where all are welcome, but few deeply know the problem domain? For most sponsors, a better choice is a focused/open or a focused/exclusive sprint. In a focused/open sprint, the topic and possibly goals are defined by an organizer. These sprints are publicly advertised and all are welcome, but everyone is expected to have relevant interest and skills. "Community-building is important, but so is producing code," says Jon Stahl, director of web solutions at ONE/Northwest.
In contrast, a focused/exclusive sprint is small and invite-only, with a single goal. While it may be publicly advertised, Stahl says, it's usually expressed as "This is an invite-only sprint; here's what we're doing; if you think you should attend, please let us know."
For example, existing Drupal rich media support was serviceable but "not very elegant," says Whatcott. Some required enhancements were obvious, such as better video integration and third-party video hosting support (including Brightcove). "Everyone wants that to happen," says Whatcott. "They have some ideas… but the ideas haven't been fully developed and put into practice." That's exactly where a sponsor can step in. The company can share its own techie details with developers who know the open source application. "Our interest as a sponsor is to make it easier for the Drupal community to use our technology," says Whatcott.
The motivation does not need to be feature-specific. Rasheed's goals were to help local area college students who were finishing up their degrees. The resume-worthy programming experience would help the individual find an entry level job in IT security. It would also benefit the community (both IT and Detroit) by building an open source tool that could save potential companies more dollars, he says. "We're looking 25 years into the future," he explains. "We're thinking about the future of this industry, tomorrow's leaders. The success of that community is our success as well."
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."
One way to do that, suggests Whatcott, is to ensure your developers spend time in the bug queue fixing integration. To develop relationships, he recommends you visit the open source project community portal where people are talking (such as message boards and IRC) and track down people with an interest in your area (e.g. video). "Get a feel for who's who. Then reach out with an offer of help, rather than a request for free stuff. You'd be surprised by how many organizations don't offer with that basic rule."