I came back from OSCON this year with a new fire to contribute to an open source project. I’ve been involved in open source for years, but lately I've been more of an enthusiast-evangelist than a hands-on-contributor to an open source community. So, I started some thinking about what to do next. When I was involved in projects before, it was due to a clear progression from user to forum guru to contributor. It’s a great path to take but what do you do if you just want to jump into something?
Cast your net wide
Inspiration did not immediately strike from the skies, so I started searching the web for resources on how to get started with open source. I found resources from Opensource.com, GitHub, and Smart Bear, among many others. It's amazing how many different ways to contribute to a project there are, in addition to writing and documenting code.
After you do some initial research on the types of ways you can contribute to open source projects of all kind, take time to evalute what projects might be potential good fits for you. A great resource for this is OpenHatch—like a matchmaking service for your skills and goals.
When looking at various projects, start with a close-up of the community around it. Make sure it is healthy and active. Nothing is worse than choosing to invest your time and having the project stagnate under you. How active is the community? Does the repo publish commit statistics? As long as they are active, a small team can be a very viable project. How are they tracking issues and are they marking things that beginners can fix? Have they documented how to make contributions? If a community is making an effort to attract people, you will probably find more support as a newbie. Is there a mailing list? IRC channel? Google group? Forum? How can you get a feel for the community before you jump in?
Get in touch with the community and test it out. See how things flow, how questions get answered. Beginning can be awkward and scary, and if you leap into a community who’s main method of mentoring is not so thoughtful or approaches "management by Perkele"—you may be in for a rough time. A good health report card for the community and the project will help you stay interested and gain personal traction.
Mirror, mirror on the wall
Now that I've got a handle on how to evaluate a community, I needed to evaluate myself. I set aside my ego and reflected on what skills I have to offer, what I truly want to gain from working on a project, and how much of my time I would be willing to invest. Be as honest as possible about all three and you're likely to find a better match. These are the three open questions that have to be answered before jumping into the deep end of an active and healthy community.
In terms of time, becoming a successful and active contributor can easily consume a lot of free time. So, make sure you’ve got a good idea of how much time you can spend. Contributing your free time can also be a mental drain because you can begin to feel that you are always "on the job," especially if you are using the same skills you use at work. Try to treat a project like this as a new hobby: it can be as encompassing or not as you want it to be, but you need to commit to spending a few hours a week or it may not be worth it. You also need to make a decent estimate of how much time your new hobby will take. If you budget 4 hours a week, but you'll need to spend 6-8 a week getting up to speed lurking on IRC, you've got a time deficit. That mismatch will sap traction and joy.
Contributing and your $DAYJOB
If you're looking to get involved with an open source project on corporate time, talk to your manager first. You need to make sure there are no conflicts on interest with your current employer, and you want to clue them in to the work you are doing to learn new skills and/or practice the ones you're honing. Getting your employer on board with spending their valuable time (they pay you to work for them remember?) contributing to an open source project isn't tough, you just need to make the right arguments. What's in it for them? Good press? Better skills for employees? Think big picture, but know that there's a trade being made here and you need to frame the proposition correctly.
With my company, my boss and I set an amount of time I would spend on the project. My boss brought up the idea to set a priority for contributing to the project since a lot of what I do for the company is interrupt driven and spiky workloads. Making my contribution to a project a clear part of my job allows me and my employer to understand not just time spent, but impact made. It also means I have the flexibility to temporarily raise the priority if I’ve got a deadline. I can also use those standards to communicate to a team I’m working with if I’m going to have to go radio silent for a while, without disappearing into the ether.
After we worked out my expectations, my boss had questions about what project I would take on. What would I be doing exactly? How would my contribution to a project help the strategic direction and mission of the company? How might my behavior in an open source community reflect on the company? It can be difficult to separate your business persona from your personal life online, so employers can be sensitive to who you may reflect on them. Discuss these in detail, then, talk about intellectual property.
Free the code
Often, as a term of employment, the company holds the rights to anything you do on company time and/or with company equipment. Some open source projects on the other hand need the reassignment of the copyright from the contributor to the project through some agreement. You’ll need to discuss this to see what the process might look like to have that waived. Questions to keep in mind are: Is there a known review process for open sourcing code? Are you a trailblazer? Can your manager do it, or will there need to be a review of the project by General Counsel? Is email sufficient or will something have to go into your HR file so you don’t get in trouble if someone who isn’t privy to the agreement says something? If you work for a government agency, there may be policies and offices in place to handle these sorts of releases.
Skills
In my daily tasks, I deal with enterprise system architecture, using clouds, configuration and system management, operating systems, etc—all at a skilled user level, not a developer level. So, it’s possible I can help a project with infrastructure design and upkeep. I use Linux on a daily basis and still do a bunch of scripting so my bash skills are pretty proficient—I'm not a bash superstar, but pretty good. And from a more “normal” programming standpoint, my Perl and TCL are rusty, probably rusted shut. I’m ok with Python, probably a solid mediocre and it’s been my go-to when I need something other than bash. So, maybe something that uses or is based in Python. I also write, a lot. I do presentations, teaching sessions, blogs, rants, reference architecture with workflow guides. Documentation and how-to guides are good ways to contribute to projects and one that often gets overlooked.
Goals
Open source has the reputation of being about "scratching an itch," which is true in a limited sense. The perception of itch scratching comes from the volunteer basis of open source projects. In order to keep contributing, you need to stay interested. That level of personal traction in a project is key, so why I want to contribute is just as important as how. The obvious reason to contribute is to be a rock star! I want to be the guy walking the halls at conferences that everyone’s talking about. OK, maybe not. But recognition is a nice thing. Getting kudos from folks for submitting a patch feels good. And, I just want to contribute and help out. I believe in open source, and the best way to support the open source message is to do something. I’m out there with the message in front of my audiences, but contribution is key. Especially when you find a project you believe in. Projects survive on the backs of their contributors no matter how many users and how much press they get. I’m also in it to learn and sharpen some skills. I learn by doing, and if I want to polish a message, I need to deliver it. If I want better Python chops, I have to write more Python.
Check yourself
Hopefully you've got a better idea of how to get started looking for an open source project to join. Partially, it's about an active community but just as important is being clear about what you can and are willing to contribute. Next I'll look at applying this process of evalution to a few open source projects. Stay tuned to find out how well it works and what I choose!
8 Comments