Apr 12, 2011

Some Takeaways from CodeConf

If you missed it, Github put together a conference in San Francisco last weekend called CodeConf. Unlike most of the conferences I attend, this one was not specific to any particular programming language. Instead the sprit was about open source code. Almost every talk was interesting and I learned and relearned a lot of things that I plan to implement. This is not a summary of each speaker's talks, but rather a few things from the various speeches that stood out. Don't take it to mean that it was the only interesting stuff.. there were too many great insights to sum up. (You'll just have to book a ticket next year and see for yourself!)

So with that caveat, here are my top 5 takeaways:

1. Fail faster (credit: Mike Krieger)
Failing faster really has two components that I liked. First, don't do anything you can't rip out easily. For example, if you are adding a feature to upload multiple photos and videos and then realize it doesn't fit into your core product, be able to remove that functionality quickly. Doing so probably means you'll be able to add it back faster if you need it.

Secondly, don't write any code until you sketch it out on a piece of paper first. I LOVE this. We made the mistake of starting to build something. And while our core concept is sound, we realized the implementation path we took was not ideal given what it will eventually look like on the screen. Having a UI sketch or wireframe in advance is a great tip I learned a long time ago from Jeff Casimir and I was happily reminded of it again.


2. Document Everything You Do. (credit: Jacob Kaplan Moss)
We've all seen projects where documentation is non-existent. This is a big problem and keeps people from using and maybe later contributing to your project. Github is great, but the wiki and readme is not sufficient documentation. This is especially true if your project is to be used by non-technical people.

a. Get a real website. Your project page on Github is familiar to those of us that are open source developers but might as well be a foreign language to those who are not technical. Have a web page with your own URL that documents what your project is, why it was started, what purpose it has, what makes it different than other projects, and how to download it and get started.

b. If the download/getting started links aren't enough then also write a few tutorials aimed as starting users. We'll be doing this for ClassyCAS later, talking about some things like integrating forgot password functionality with the central user store.

c. Have your developers provide documentation with their commits, especially if the commit introduces new behavior or changes existing behavior. Nobody is better qualified to document your project than the developers themselves!

d. Have a FAQ. Not just any FAQ, but one aimed at really angry users. Nobody wants to go read a FAQ for fun, we do it out of confusion. So don't answer questions like "What does foo do?" Give me answers to harder questions that might be causing frustration.


3. Be nice to initial contributors. (credit: Gina Trapani, Andy Lester)
The success of your open source project is not just about downloads and watchers. It's about community. Getting people involved and feeling welcome is critical. To do that, you need to be nice. Make people feel that their contributions are welcome. Don't just say "come back when you've written a test suite for that", instead work with the contributor in the way that they feel comfortable. Eventually they may end up becoming a significant addition to your project even if it doesn't appear that way to start.

Also, don't just judge people's ability to contribute to your project based on their coding skills. Everyone can help in some way whether it's translating, marketing, design, or even just complaining. Everyone can help you if you let them and your project will thrive as a result.


4. Abandon software (credit: Seth Fitzsimmons)
At some point, if you've lost interest in your project it's time to hand it over or shut it down. If it's not the only game in town, one easy way is to recommend an alternate project that you think does what yours does well. Or, find a current contributor and see if he or she would be willing to take the keys. If you've built a good community (see #3) then making yourself redundant should be easier. One big tip is that, when you publish your code, also publish your motivation. If you're scratching an itch then the expectations others have will be different than if you wrote it for a highly distributed mobile application as part of a contract with a Fortune 500 company.


5. Don't just think about open source as a software activity (credit: Ariel Waldman)
While almost all of the talks at CodeConf revolved around code, I particularly enjoyed Ariel's presentation about Hacking Space Exploration. She gave a lot of examples of how people who made amazing contributions throughout history would be considered amateurs by today's definition. She went on to talk about specific ways to get involved including Galaxy Zoo and Spacehack.org. Put another way "Your mobile phone has more computing power than all of NASA in 1969. NASA launched a man to the moon. We launch a bird into pigs." (credit: George Bray)



1 comment:

  1. Just as much i would want to know about a conf.
    enjoyed reading every line.
    -Jags

    ReplyDelete