Don Schenck is a Rackspace developer advocate, meaning he writes code, writes about code, speaks at conferences, teaches workshops, and helps customers. Prior to Rackspace, Don worked across a broad range of industries, from developing systems to reduce civilian casualties in military engagements to building software to control machines that cut and bend reinforcing steel.
Most recently, Don was involved in mobile and kiosk application development. When he's not coding, writing, or speaking at a conference, he likes to surf (waves, not the Internet), lift weights, and whine about things to his long-suffering wife, Patti. He often wears a kilt, hates the designated hitter rule, and loves anchovies. We reached out to him to get a sneak peek of his talk titled "OMG—How do I start an open source project?"
First off, why should someone start an open source project?
There are several reasons. If you have an idea for a utility or framework or whatever, and you would like the support of an entire community of developers, open source is a great way to go. If you want your code "out there" so it can be reviewed and critiqued (which will improve your skills), open source is a good solution. If you are just out of school and want to establish yourself and show off your coding skills, start an open source project. Finally, if you're altruistic and just want to help the software community at large, yes, please, start an open source project.
Are there any prerequisites or obstacles one should be worried about while thinking of creating an open source project?
There are considerations, sure, and I cover a lot of them in my talk. Having a GitHub account is pretty much mandatory. I'm hesitant to list things, because you're better off forging ahead and making mistakes and learning as you go as opposed to waiting for everything to be perfect before starting. Start. Now. Today.
What are the some important things every open source project must have?
Licensing; I recommend Apache 2.0. Cool thing: GitHub will add your license with just one click.
You need a good readme file; this is important. Make sure you include a description of the project. Not just, "This is a utility for using the cloud," or something nebulous, but give one or two use cases—even, say, what caused you to want to create the project in the first place.
Clear installation instructions. Have someone who is not you go through the installation—it's easy to make assumptions and gloss over things that are important. Let folks know how they can contribute, and invite them in. Remember: There may be a person just out of school who wants to contribute but, perhaps, lacks some confidence. Make it easy for them.
A glossary of terms is a good idea as well. There are other things; again, I cover them in my talk.
Let's say that a developer has a project in his head and just wrote some code on his local machine. When is the right time for him to release his code to the public?
Ten minutes ago.
Are there any standard tools a developer should use while releasing his code?
GitHub is the defacto standard (and git, of course). Other than that, I suggest keeping the use of tools and such to a minimum. Remember: Every "thing" you add to the project makes it that much heavier, makes it that much less likely that someone will be motivated to contribute. The last thing I want to do is be required to install a special documentation tool just because you decided you like it. Keep those things outside of the project, or as options.
Should a person be worried if nobody tries to contribute to his project at its early stage?
Not at all. In fact, in my talk I mention "the lull," a time when nothing is happening. What's amazing is that folks tell me they've experienced the same thing. That's where many projects die. At that point it's just work—no way to sugarcoat it. So don't worry if you're going it alone for a while; get something working, and as folks start to learn about and use it, it will attract contributors. Let me add, when you get your first pull request, that's a tremendous feeling of accomplishment and it's worth all the effort.
Speaker Interview
This article is part of the All Things Open Speaker Interview series. All Things Open is a conference exploring open source, open tech, and the open web in the enterprise.
Comments are closed.