So, you want to start using that open source thing…

You’ve been reading Opensource.com and there’s a package that you’re excited about. You’d love to give it a try and maybe—just maybe—find a way to contribute to the community that made it (if, you know, it turns out as awesome as that article you found says it is). But where to start?

First-time installations

Every package is a little different—some run on different operating systems than your home machine, some have different dependencies, some expect a certain minimum level of technical expertise. Some are crazy-easy, like LibreOffice or WordPress. Some are much more challenging due to factors like high complexity, lots of moving parts, lots of dependencies, or that the community’s developers haven’t yet gotten the installers built like they want to. But as someone who’s looked at a lot of different packages out there can tell you, there are some pretty common lessons learned that you can—if you’re wise—learn from the easy way (by reading them here) rather than the hard way (wrestling with that installation at midnight when you should be doing something else).

“Plan to throw one away. You will, anyway.”

In 1975, Fred P. Brooks wrote this statement in his seminal series of essays on software development, The Mythical Man-Month, and it’s no less true for open source projects and test installs than it was for big-iron projects of that era.

When you’re installing an open source project for the first time, plan on doing it a second time (if you actually take it to production). Your first install is a prototype, nothing more. It’s a playground for you to try it out and see what works, and what needs more work for you to actually be able to use it in a production environment. So, with that in mind, make sure you have a disposable environment. For web-server-based applications, you can do this on a VM using your favorite desktop virtualizer. I typically use Virtualbox for this sort of thing, partly because if I take it the next step and plan for a live or development deployment, I’m likely to use Vagrant, which is very handy with Virtualbox. But long story short, don’t get too attached to that first installation; you’re probably going to want to toss it and start over at some point. Which leads to…

Don’t pollute your home base

Maybe you have a server in your home, or in a colocation, or you have your own VPS somewhere, running your family web server, your personal domain, your media server, or whatever. Until you’re ready to put your new toy out there for real, don’t even download it to that box. Dependencies can conflict with something you’ve got running already, and create more headaches than you’re really ready for. Making sure you understand the new application’s environmental needs before you shove it into bed with other things you have running can save you many, many headaches, not only at install time, but the next time that box reboots.

Read and follow directions!

I could make all kinds of cracks here about those of us who don’t ask for or follow directions, but we’ll just skip over that to say: “If installation instructions exist, read them, understand them, and follow them.” It is ironic that the packages that are easiest to install often have elaborate instructions for what to do in the highly unlikely event that their automation fails. Packages with less slick installers, one would think, should have very good install instructions, but they often do not. Find the best instructions you can, read them completely, and understand them thoroughly before you start your installation.

One special case here: If you’re, say, a Fedora fan, and the package you want to play with has instructions for Debian, or the reverse, or if you want to install it on Windows, or some other mismatch, it’s really important to understand the differences in how these different platforms install things. Copying and pasting an apt-get command on your Fedora box will get you nowhere fast! A cross-platform installation like this can quickly turn into a special sort of suffering, and that’s why I recommend installing on a virtual machine of the type the developers intended for the first go-around.

Hey, I like this thing, and want to join the community! Now what?

Check your awesomeness at the door.

You may be feeling pretty smug about this point. Without any help, you’ve installed this great new thing, maybe more than once, you’ve got it singing your song, and you’re ready to start fixing bugs and writing code! That’s quite an achievement, I’ll grant you, but the people already in the community have done it dozens or hundreds of times. Don’t forget that. If you come in the IRC channel all smug and full of salt about how you got this thing running, you probably won’t get the welcome you think you deserve. You wouldn’t believe how many times I’ve seen this happen, and the ending is always the same—the new person gets chased off.

Is that a fault of our communities? Partly. We do have some people, in some communities, who get a little short with newcomers. But it’s partly the fault of the newcomers who stroll in thinking an established collaborative community of people owes them something. They don’t, and you’ll do well to remember that. They will generally be happy to see someone new who cares about their passion, but show you care by doing your homework first!

Ask lots of questions

Make sure your questions aren’t answered in the instructions, on the Wiki, or in a “sticky” on the community’s discussion forums first! A little time spent reading can help a lot. If you frame your question like, “I looked on the forums, but I couldn’t find how to do X. Am I missing it?” you’ll probably get a better answer—and it’s totally in good form to offer to write it up once you learn how to save the next person who comes along the same hassles.

Know the landmarks (and the land mines)

It won’t take long to figure out the lay of the land, and the who’s-who in a project. Usually the about page or contributors list can give you some clues in that respect, and idling in the IRC and reading the backlog can quickly tell you who are the heavy hitters.

If you’re planning to contribute code, you should know the community’s process for doing that as well. Again, asking well-formed questions of the release manager or similar head honcho can get you a lot of knowledge–as well as a lot of political capital—that you may need later.

Many projects—it pains me to say—also have a political structure as well as a technical structure. Sometimes those are intertwined; one community I know of absolutely will not consider any code that leads towards database independence; the product is married to the database that it was originally written for, and that’s that. Patches have been submitted that could make the product more open, but those patches are not accepted. If you’ve fallen into a community that has those landmines, it’s good to know what they are.

To be fair, some of these mines may be technical limitations! If you phrase your ideas in the form of a question, you might ferret out some of that knowledge before you run afoul of them.

Socialize. All this work can be fun!

If the community has an IRC channel or other real-time discussion space, don’t be afraid to be a little off-topic now and then when chatting with people in the community. The people on the other end are people, just like you and I; they have jobs and kids and weather and their cars break down—all the joys and triumphs that you and I do. They just happen to share your excitement for this open source project that you’re now a part of. One of my best friends on the planet is a woman from Germany whom I’ve only seen in person a handful of times, but we talk almost every day via IRC. She’s been there for me through lots of rocks and shoals over the last 6 years, and I see little chance of her going away any time soon.

You could find friends from all over the planet, who are as close as your IRC client. Open source developers are great people, and if you’re in a project you’re passionate about that passion will show and you can quickly become a regular.