How to Get Started as an Open Source Programmer
by Seth Kenlon
Looking out at the world of technology is exciting. It has a lot of moving parts, and it seems the further you dig into it, the deeper it gets, and then it's turtles all the way down. And for that same reason, it can also be overwhelming; where do you start, if you're keen to join in and help shape the way the modern world functions? What's the first step? What's the 20th step?
The first thing to understand is that **open source** is open. That might seem obvious, but the phrase "open source" is thrown around so often these days that sometimes people forget it's just a description of a cultural phenomenon, not the name of a Fortune 500 company. There's no interview process, there's no sign-up sheet or registration form to become an open source programmer. All you do to become an open source programmer is *program*, and share your code, ideally with a guarantee that the code remains open regardless of how it's used.
That's it. You're an open source programmer!
So there's the destination, but what about the logistics?
Skill Trees
Have you ever played an RPG? In video game RPGs, there's a concept of linear "skill trees": you acquire basic skills, which you build upon to level up and get new skills.
Becoming a programmer is a little like that. You get some basic skills, you practise them until they're second nature, and then you get new skills and progress along your chosen skill tree.
The tricky thing is, there's not just one skill tree; there are many entry points and too many individuals with their own unique strengths, talents, and interests. However, there are certain definable skills that contribute to being a programmer, and a few things to keep in mind when getting involved with open source.
Scripting
[IMG]
One of the biggest advantages of a POSIX system like Linux or BSD is that every time you use your computer, you've got the opportunity to practice a little programming. If you have no idea where to start programming, then start there: find repetitive tasks that you perform every day, and start automating. It can be something simple, like converting or re-sizing batches of photos, or checking email, or even just getting the five applications you use each day launched with one click. Whatever the task, make yourself take time out to automate something for yourself.
If you can do something from a terminal, then it can be scripted; learn `BASH` or `TCSH` and let system scripting be your introduction to writing code and to how your system works.
Sys Admin
[IMG]
From this point, you can continue on to become a programmer, or you can cross over to a different skill tree entirely: that of systems administration. There's some cross-over (a good sys admin ought to have at least a little programming experience, and should be ready to weild Python, Perl, or a similar language to develop unique solutions), but a **programmer** is someone who builds with code day in and day out. Continuing along that path, in an effort to stay focused, the next skill level is...
Programmer
[IMG]
Open source is a great way to learn programming skills; you get to look at other people's code, you get to borrow ideas and technique, you get learn from their mistakes, you get free critique of your own code, and if you use Linux or BSD, the *whole* stack is open to you. As far as the eye can see; it's all yours for the taking.
That's what the travel brochure says, any way. The reality is that you're probably not going to start digging into the source code of a project and come out the other side with the sudden realisation that you accidentally learned to code. Programming is hard work. If it wasn't, everyone would do it.
Luckily, programming is logical and structured, so it builds upon itself. You might not fall into programming, but the more you poke at it, the more you start to understand it.
Understanding how to control and automate a computer is one thing, but knowing how to write the stuff that other people want to automate is the point that you cross over into the realm of *programming*.
Polyglot
[IMG]
All programming languages aim to do the same thing: make computers compute. Choosing one is a mix of what you think you want to do, what (if any) language is in common use in the industry you are targeting, and what language you happen to best understand given the materials available to you and your own personal learning style.
With a little bit of research, you can get a good idea of the complexity of a language, and then decide what to try first based on your own level of comfort.
Another way to choose a language is to look at your goal, find out if other people are working toward the same thing, and then look at what they're using. If your aim is to develop desktop tools, you might find learn C and Vala for one, or C++ for another.
At the end of the day, though, don't get overwhelmed with all the choices. The thing about languages is that they stack well. Once you learn one programming language well enough to fall back on it when you need to get something done, then you'll find it a lot easier to pick up a new language. A "language" is just a set of syntax and rules, after all; learn one, and it's fairly trivial to superimpose new rules over the same theory.
The primary goal is to learn a language. Pick the one that makes sense to you, or the one that's most appealing to you, or the one that your friends are using, or the one that has the documentation you understand best, but focus on one and learn it.
Open Whazzit?
Whether or not you're just learning to program or you're an old pro just getting into open source, before jumping head first into this brave new world, you need to learn what makes "open source", well, *open source*.
It's gotten trendy lately for software vendors to claim they've gone "open source". Unfortunately, some vendors just mean they've released a public API, or that they're "open" (receptive) to suggestions from their users. The word "open" isn't a trademark; there's no committee that governs how or when it's used. There is, however, an
Open Source Initiative
, co-founded by the late Ian Murdock (of Debian Linux). The OSI
defines
what open source means (licenses that "allow software to be freely used, modified, and shared"), and formally approves and
tracks
licenses deemed truly "open".
Apply one of those licenses to your code, and you're an open source programmer. Congratulations!
[IMG]
Ask any open source enthusiast and they'll tell you: the most important thing about open software is the people. Without people, software stagnates. Computers need users, bug reporters, designers, and programmers.
If you want to join or cultivate the global open source community, you want to become a *part* of the community, even if you're not generally a "people person". This usually means subscribing to mailing lists, or joining IRC channels, of forums, at the bottom of the totem pole. Any mature community has been around long enough to see prospective members come and go, so you have to understand that when you saunter in ready to change their world, that before they all agree to your master plan, you have to prove that you're not going to disappear after 3 months when something sparkly on the other side of the Net catches your eye. So be ready for the long haul, if you aspire to something big.
If you're just around to lend a hand, that's acceptable, too. I myself have submitted small patches to projects, and sometimes the project leads think it's a good thing and other times they reject it. If it's important to me, I maintain a patch for myself and clients, otherwise, I move on.
It's part of the process.
Where do these communities exist? It depends on the project. Some projects have dedicated community managers who help bring everyone together in public spaces for everyone to see, other projects form around forums, others use mailing lists, or even issue trackers. Look for the communities, and you'll find them.
Just as importantly, though, is to look at the code. They call it open **source** for a reason, so find the code and take a peek. Even if it's still above your level of full comprehension, it gives you an idea of how the software project organises itself, and possibly where they might need assistance. How's the documentation? is there a README, a LICENSE or COPYING file? how's the code organised? does the code have comments? is it tidy and does it have a consistent style?
Don't under estimate the importance of following through on the promise of open code. It's the reason you're getting involved, so look at it critically from every angle, to see what you can learn from it and how you might contribute back.
Finding "your" community is a lot like dating, but specifically it's like dating in **Groundhog's Day**. It takes time, and the first couple of tries might fall flat. The more you go through it, the more you start to feel déjà vu. Eventually, though, you learn enough about yourself, your interests, and you find the right combination of other people, and you settle in somewhere. Have patience, and let it happen naturally.
Actions > Words
[IMG]
Being an open source programmer is about the code (the "source" part of *open source*), and ideas are a dime a dozen. What speaks volumes is source code; it shows you know what you're doing, that you're willing to get your hands dirty, that you're willing to spend your time on the project, and that you can back up your ideas with something that compiles.
To do that effectively, of course, you should do your homework on the project itself. How does the project prefer to receive submissions? which branches are the stable and development branches?
Here are some general rules for how to approach getting started:
- Get familiar with a project and its development culture, and be respectful of it.
- Write patches, bug fixes, or small features that have been requested, and submit them.
- Don't get discouraged if your work is rejected; it's not a personal rejection, it's a call the development teach must make, whether you agree or not.
- Don't get discouraged if your work is accepted but changed beyond recognition.
- Rinse, repeat, and try new and bigger changes.
There is no leaderboard in open source.
[IMG]
Some sites try to make it seem like there is, but there's no high score. Participate, contribute, add to the pool of ideas, and the stash of commits, and you're doing it right.
Develop
[IMG]
Programming in any environment is always, ultimately, about personal development. Whether you're finding new ways of solving problems, new ways to optimise code, learning a new language, or a better parser, or trying a new data storage format, or learning how to deal with other people better, you never want to stop growing. The more you develop yourself, the more the project benefits.
This is final item on the list, but it's actually the one that persists through the whole process. Becoming an open source programmer isn't like getting a government job; it's a process. You learn, you share, you keep learning, you get distracted and write a Game Of Life implementation, you learn some more.
That's what open source is about: the freedom to develop, in every sense of the word. So go find your skill tree, choose your super powers, pay your dues, level up, and get involved.
Image attribution, all CC-BY 3.0: caesar.png: delapouite, game-icons.net all others: lorc, game-icons.net leaderboard: cc-whatever, opensource.com