What We Learned About Open Source By Building Our Accelerator On Github

There are solid engineering reasons for open-sourcing a project, so why are developers still afraid of being outrun by the competition? Our Target-sponsored app-building competition led us to a few hypotheses.

What We Learned About Open Source By Building Our Accelerator On Github

April 30 marked the end of entries for the Co.Labs & Target Retail Accelerator. Just two days before the contest closed, we had only two complete submissions. Being transparent about this process wouldn’t be hard, I remember thinking, since some of us were so blanched from anxiety we may as well have been ghosts. What was happening?


We had built the contest on top of Github with a weed-out philosophy in mind, thinking we might attract more seasoned devs and keep out people who wouldn’t be able to follow through in the second stage, which requires actual programming.

But the real advantage of building our app accelerator on Github was supposed to be the ability to collaborate. We hoped that incomplete teams might upload their specs to Github early, as a way to team up with other entrants and (presumably) submit a better entry. The more complete the team, the more robust the app, the better their shot at the prize purse: $75,000 buyout or $10,000 in seed money.

How We Imagined Our Github Contest Working

With only one other example I could find of a Github-hosted programming contest, this hypothesis was unproven. And since Github isn’t exactly meant for this kind of program, we knew we had to make the process developer-friendly. The contest flow worked like this:

  1. Developers would read about our contest from announcements like this one.
  2. Then they would proceed to this registration page, where we would collect their contact info and show them the rules of the game.
  3. After registering, they would be taken to this Github repo.
  4. Inside this repo were the rules and guidelines; they’d fork it and upload their submission.
  5. We’d accept their pull requests, showing all the submissions in the repo for the world to see.

How Our Github Contest Actually Worked

By sunset on the final day of the contest, we had received about 70 submitted projects, many of them incredibly well-conceived and illustrated to a level of professionalism that surprised everyone on our team. Considering the commitment involved in this contest, 70 actual projects submitted out of 400 registrations is actually a pretty good hit rate; but nearly all the entrants had strategically waited until the last possible moment to submit a pull request.

Whether our readers are mostly procrastinators or just paranoid about idea theft we’ll never truly know. But by acting as the contest’s de facto customer service rep, I got some insight into how people were thinking about this process.

What We Learned From Negative Feedback

Several developers I spoke to assumed the last-minute submission rush was what we intended–a dramatic “show your cards” throwdown. I assure you that’s not what we intended. But others emailed about serious discomfort with Github itself, and the generally nature of developing software in a public repo.


We tend to think these complaints originate from an old way of thinking–one that is not necessarily good for progress (however you define it). But I’ll list the more poignant complaints here:

Hi Chris, I was not comfortable placing our entry on github. We would like to offer this application to Target. If Target is interested, we would be very happy to discuss further. I did create an entry with email: [redacted]. I am sending you our proposal in this email. Best, [redacted]

This reaction would be expected if contestants were competing with each other in a zero-sum scenario, like competing firms in Mad Men pitching Heinz ketchup. But roughly half the prize purse is reserved for finalists–people who get to keep their IP. The idea here is not to give businesses a chance to pitch Target in public; after all, Target is a corporation which probably knows how to craft an RFP, if that’s what they wanted. And with some of the best tech and design talent in retail, they aren’t shorthanded.

Instead, the idea here was a group brainstorm meant to accomplish some incremental (but meaningful) improvement in the way we all think about software as a shopping and merchandising experience. It’s a call for prototypes, not an outsource job. The seed money, given to the semi-finalists, is a way of encouraging the continued development of great, nascent ideas for their own sake.


The top prize–a $75,000 buyout–is like a golden parachute for devs who built something awesome in less than 90 days, but can’t or won’t have the capacity to keep up the project after judging ends. (Winners can demur from taking the top prize if they prefer to keep their IP.) Admittedly, cash-for-IP trades aren’t characteristic of accelerators, but then, $75,000 wouldn’t be much of a consulting fee.

Another email we received:

Hi Chris, I am wondering if the current funnel or submission method via GitHub may be detouring some teams for submitting. I know that my colleagues said they rather just pitch Target directly than have the idea in an exposed space. I have seen a number of ideas ripped off from some accelerators around MIT where the founders felt like they just had their ideas bought in exchange for some free pizza. Their [sic] is good and bad transparency.

Even the Winklevosses have stopped beating this drum. Let’s assume your idea is worthwhile; that doesn’t make it worth dollars. As Steve Jobs said back in 1995:


You know, one of the things that really hurt Apple was after I left John Sculley got a very serious disease. It’s the disease of thinking that a really great idea is 90 percent of the work. And if you just tell all these other people “here’s this great idea,” then of course they can go off and make it happen. And the problem with that is that there’s just a tremendous amount of craftsmanship in between a great idea and a great product… Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently. And it’s that process that is the magic.

Secretive types had the option in this program to wait until the last minute to submit a pull request, and many did. And even cynics would agree that a $75,000 prize buys an awful lot of pizza.

Still, some people with perfectly great entries were just not comforted by Github’s spartan interface. It seems like people want extra feedback in a high-value task like this, so perhaps next time we might build a custom, unified submission process on top of Git. It’s hard to imagine someone with enough technical ability to proceed through the second stage of the contest–in which entrants build working prototypes–without knowing their way around Git. But we acknowledge that some of the team leaders handling logistics might themselves be designers or product managers, not developers.

Hi – I was a little confused on matching up my Retail Accelerator account to my submission. I signed up on // with email address [redacted] and sent a pull request from a gethub account with that same email – though the folder name I added is [redacted]. Just wanted to make sure I wasn’t missing some part of the process.

One reasonable criticism is that our submission process wasn’t centralized. Signing up took place on a page under a FastCompany domain, while the rest of the process was handed off to Github. Have you ever felt worried when you put your tax return in the mailbox? Will it get there? You can only trust the infrastructure enough to hope. People feel this way because there’s no feedback loop, and that’s understandable, so we started writing “received” in the comments of a submission to let people know that something happened and their files were received. In the future, we’ll create a Github webhook to do this automatically.


Thanks for all your help thus far. I’m new to GitHub and believe I submitted the entry successfully, but could you please check? Should be called [redacted]. I also just entered committed comment of “Entry Completed”.

Another email I received echoed the sentiment:

Just wanted to make sure it is OK for us to update our entry today by submitting a new Pull request? We revised our description document since we realized we have room to briefly cover the analytics features.

Because you can make as many pull requests as you want, this entry process obviously lacked the finality that people associate with a contest submission “SUBMIT” button. But then, this is more like a mini-accelerator than a contest; in an accelerator you’d want to have more feedback than just “your submission was received.” You’d want to hear other people talking about your work.

In architecture and design it’s traditional to have charrettes where a group of people come together and think about a problem. But people treated this program as a contest, and not an accelerator, perhaps because of the way the rules were constructed, and that’s something we’ll consider if and when we run another accelerator program in the future.


One contributing oversight on my part was failing to provide a channel for entrants to talk to each other and comment on one another’s entries. Git isn’t really designed for centralized conversations, and I’m still not sure which third-party platform I’d use to host a charrette. If you have suggestions for how we might accelerator discussions in the future, let me know with a tweet. We would have liked the first phase to be learning about the people and the proposals: Really get inside the participants’ process and learn about what they might do. What’s interesting is learning how someone reacts to feedback and real-world problems.

Here’s an entrant email (actually, many emails from this person) that caught me off guard:

I am trying to upload my .pdf description document my .jpg mock up images and my 30 second video , I have no idea what I’m doing, I’ve been at this for 2 hours now and I’m still completely lost, in addition, the way directory is set up (see attached images) it looks different from everyone else’s, I don’t even know if this is set up correctly, Can I just email you my 3 things needed for submission and you can upload them to Github for me? Or maybe can you call me up and walk me through this over the phone? I don’t want to mess this up, but I have no idea what to do.

Later, another odd message from the same entrant:


I am a developer, I’m sure I will be able to figure it out, just never used [Github] before and it was really confusing, plus I’m in a hurry to catch a plane which didn’t help. For Most of my clients we are using Dropbox or Basecamp to share files and info, so after being used to using collaborative platforms like that, GitHub was like stepping back into the DOS era.

Development is about problem solving. As a counter-example, another developer also had problems with Github, so he did what he knew–he uploaded images to Imgur and then, via the Github web interface, changed the Readme file in his entry folder to point to Imgur.

The Discomfort Around Openness

Software development is an imperfect process. Open source is a tacit acknowledgement that your software has bugs and blind spots, and it’s understandable that people wouldn’t want other developers to see their dirty laundry. But all the Co.Labs staff felt as if the value of the feedback you get from the community far outweighs the embarrassment of showing something imperfect.

I suspect that entrants might have felt more comfortable entering an open Github repo if the projects were more complex, and the teams were bigger–say, if we were hosting a contest to build software for a Mars rover, not a retail shopper. In the Mars rover scenario, the complexity of many moving parts might preclude a small, devilish team from ripping off the project and going in their own (closed source) direction with any velocity. The larger group of contributors to a complex project would easily outrun a small, private group.


But open sourcing a bunch of wireframes and a spec? That’s another sort of complexity that also can’t be outrun by a small, private group. Even if we had restricted this program with very narrow constraints–not just a “retail app” but, say, a shopping list app–even the most similar-sounding specs would turn out entirely different in the prototype stage, depending on the platforms, languages and design principles each team elected to use.

Disagree? Agree, but with caveats? Want to send us a backhanded compliment? We love those. Hit us up on Twitter @fastcolabs or find me personally @chrisdannen.

Important Dates

For readers with entries on the line, here is a summary of the important dates coming up:


May 13: Announcement of 7 Finalists
May 14-30:Finalists work with Target to build their prototype
June 3-24: Finalists present their final prototypes to Target
July 1: Announcement of the Grand Prize Winner

[Ghost Car: Flickr user Kevin Dooley]


About the author

I've written about innovation, design, and technology for Fast Company since 2007. I was the co-founding editor of FastCoLabs