How to Sponsor an Open Source Sprint
Your company's IT department probably depends on at least one open source application. The software does the job, is budget-friendly, and it has an active open source community which is constantly upgrading the application. But few applications are perfect, whether proprietary or open source. While the software may do most of what your business needs, you may consider having a few in-house developers add customizations. That's a perfectly reasonable idea. But there may be a better way that benefits the community, is dirt cheap, and oh yeah - is also fun.
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.
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. "The whole idea is to have a focused group of people make progress by the end of the week," explains Jeff Whatcott, senior vice president of marketing for Brightcove.
An open source project may organize a sprint on its own, but it's also possible for your company to sponsor such an event. Doing so is easier, faster, and less expensive than an IT manager may imagine. Here's what's involved, based on input from several sponsoring organizations. Perhaps you'll be inspired to sponsor a sprint yourself.
It cost how little?!
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.
That's because a sprint's basic logistics are fairly simple. For example, the sprint being organized by Brightcove's Whatcott will be held at the online video platform company's offices in Cambridge, MA. Brightcove, which wanted to help the Drupal community improve its video support in the content management system, will give the open source developers a conference room, provide a projector and Internet access - and then will mostly get out of the way.
As another example, ONE/Northwest, a Seattle nonprofit that provides technology and communications strategy assistance to environmental advocacy organizations, organized a two-day sprint to focus on adding specific functionality to an add-on module for the Plone content management system. The half-dozen or so developers were local, with one exception. "We covered travel expenses to bring lead PloneFormGen developer Steve McMahon to Seattle from his home in Davis, CA," says Jon Stahl, director of web solutions at ONE/Northwest. "Our total 'hard' cost was on the order of $300." ONE/Northwest provided the office space and beer.
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.
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."
The sprint's goals must be clear and well-understood, especially since so much is to be accomplished in a few days. "Some sprints encourage each member to bring their manifesto to the sprint," says Whatcott - a personal statement of what should happen, so they aren't staring at a blank white board.
Many projects already have a priority-setting process in place. During the leadup to the sprint organized by Stahl, he says, organizers used UserVoice.com to capture, discuss, and rate ideas from the user and developer community. "While we strongly suspected our highest priority ideas were both uncontroversial and popular, UserVoice helped us validate this, and also surface a bunch of great, complementary ideas that we worked on during the sprint," he says. "It opened a channel for people who couldn't participate [in person] to have some input on the process."
Mostly, it's important for the sprint sponsor to help the community create software. "You don't need to dictate a lot of rules," Englebienne says. "We're just helping the existing virtual group getting together and letting them do their thing," adds Whatcott.
One area in which the sponsor can help is technical guidance and coaching, particularly when the sponsor has expertise to be integrated into the open source project. "You can do tech talks to get them to a certain level on a particular technology," suggests Englebienne.
Every sprint has its specific goals, and enthusiasm can encourage a lot of productivity. In 24 hours, says Globant's Englebienne, the hack-a-thon produced three pieces of software: a mobile application using J2ME, a library management system in Python and Django, and something for the Travelocity portal. While they didn't finish everything intended, the teams noted all known issues and released the software. It's open source, after all; others can add more functionality later.
Stahl's sprint goals were to add a handful of specific features to PloneFormGen to better support features the company is building, among them online donations and online advocacy. A few weeks afterwards, PFG 1.5 was released, including work accomplished during the sprint. "We're now using PFG 1.5 in production with our clients," Stahl says. Not bad for a few hundred bucks worth of investment - for functionality the Plone community already wanted.
Making the Sprint a Success
Your company needs a champion to organize the sprint's logistics and connect with the community. Although Whatcott is a marketing guy, he says the right person ideally is an engineer, as techies often are better received by the development community. (But there's a role for marketing here, too; we'll get to that in a bit.)
Most sprints have 5-10 participants. Globant's sprint had 6 people in Buenos Aires and 12 to 15 in London, for instance. But multiple sprints can happen concurrently. When I participated in a sprint a few years ago, sponsored at Google, two teams worked side-by-side.
Assign a local host to be with the developers most of the time - "someone who can go grab pencils," explains Whatcott. Among other logistics to consider: Make sure the developers have great Internet connectivity with access to the guest network. Provide a war room where the sprint team can work in privacy; don't make people jump from room to room. Don't forget access cards so developers can get into the building. Rasheed also cautions patience and commitment. "A key thing is to listen, define the requirements and create clearly measurable results," he says.
Some sprint organizations may be managed by the developers themselves. For example, during Englebienne's project, one person acted as scrum master, setting objectives, and running hourly stand-up meetings and hourly sprints to track goals and celebrate progress. Developers organized into groups: one in charge of bug fixing, others to design and build the project site, yet other developers to buzz the experience.
The "buzz" can be important. Englebienne recommends that one participant serves as the sprint's recorder, managing blogging, Twitter, Facebook, including pictures and video. The blog lets people follow the process, and it gives the community a way to remember the event.
Buzz is important for the sponsor's marketing, too. Whatcott recommends a company representative (perhaps the champion) write about the sprint in the corporate blog and its Twitter stream. "It should be part of the face of your company," he says. "One of the objectives is to increase your credibility (without tooting your horn too much)."
The most obvious benefit for a company to sponsor a sprint is that it can help the open source project upon which it depends get the functionality the company desires - for dirt cheap, really. But the ROI is much deeper, even without considering the karmic payback to the open source community. If you attract the project's top developers, it gives your in-house developers access to smart people they can learn from. Also, says Englebienne, a sprint is a good way to detect talent in your organization. And if you've been wanting company management to expand its software development methodology consciousness, they'll see a new paradigm for developing software.
"It's not just about the source code," says Englebienne. "It's the experience and the process."