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. For that very reason, technology is also 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 twentieth step?
The first thing to understand is that open source is open. This 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. Unlike other jobs or groups, you don't have to interview or complete a sign-up sheet or registration form to become an open source programmer. All you do to become an open source programmer is program and then 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!
You now have your destination, but what about the logistics?
Skill trees
Have you ever played an RPG? In these games, there's the concept of linear "skill trees". When you play, you acquire basic skills that you build upon to "level up" and get new skills, which you use to acquire new ones and "level up" again. And so on.
Becoming a programmer is a little like adding to your skill tree. You get some basic skills, you practice them until they're second nature, and then you get new skills, and so on, and then you are progressing along your chosen skill tree.
You'll find you'll encounter more than one skill tree. Open source has many entry points and many individuals with their own unique strengths, talents, and interests. However, certain definable skills contribute to being a great programmer, and developing them is an important part of participating successfully in open source projects.
Scripting
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 begin with how you work. Find repetitive tasks that you perform every day, and start automating them. This step can be something simple, like converting or re-sizing batches of photos, checking email, or even just getting the five applications you use each day launched with one click. Whatever the task, take the time to automate something for yourself.
If you can do something from a terminal, then it can be scripted. Learn bash or tsch and let system scripting be your introduction to writing code and to how your system works.
Sysadmin
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. The two careers have some overlap (a good sysadmin ought to have a little programming experience, and should be ready to wield Python, Perl, or a similar language to develop unique solutions), but a programmer is someone who builds with code day in and day out.
Programmer
Open source is a great way to learn programming skills; you get to look at other people's code, borrow ideas and techniques, learn from their mistakes, get a critique of your own code, and if you use Linux or BSD, the entire 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, anyway. 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 realization 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
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 learning style.
With a little bit of research, you can get a good idea of a language's complexity, 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 learn C and Vala for one, or C++ for another.
At the end of the day, though, don't get overwhelmed with all the available choices. Languages stack well. Once you learn one programming language well enough to fall back on it when you need to get something done, you'll find it a lot easier to pick up another one. 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."
Claiming software is open source is the latest marketing approach some software vendors are wielding. Unfortunately, some vendors just mean they've released a public API or that they're receptive ("open") to suggestions from their users. The word "open" isn't trademarked and no committee governs how or when the word is used. However, the Open Source Initiative, co-founded by the late Ian Murdock of Debian Linux, 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!
Community
Ask any open source enthusiast and they'll tell you the most important thing about open software is the people. Without motivated contributors, software stagnates. Computers need users, bug reporters, designers, and programmers.
If you want to join or cultivate the global open source community, you need to become a part of the community, even if you're not a people person. This usually encompasses subscribing to mailing lists, joining IRC channels, or hopping onto forums, and starting 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, before they all agree to your master plan, you have to prove that you're not going to disappear after three months when something sparkly on the other side of the Net catches your eye. Be ready for the long haul if you aspire to something big.
If you're just around to lend a hand, then that's acceptable, too. I myself have submitted small patches to projects, and sometimes the project leads think these are good and other times they reject them. If the rejected patch is important to me, I maintain it for myself and clients, and otherwise I move forward.
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, use mailing lists, or even issue trackers. Look for the communities, and you'll find them.
Just as importantly, though, look at the code! They call it open "source" for a reason, so be sure to 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 organizes itself and possibly where they might need assistance. How is the code organized? Does the code have comments? Is it tidy with a consistent style? Review the documentation, particularly the README, LICENSE, or COPYING files.
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.
Finding the best community is a lot like dating, but specifically it's like dating in Groundhog Day. It takes time, and the first couple of tries might fall flat. The more you go through the process, the more you start to feel déjà vu. Eventually, though, you learn enough about yourself and your interests, you find the right combination of other people, and you settle in somewhere. Have patience, and let it happen naturally.
Actions > Words
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 producing. You need to show you know what you're doing, willing to get your hands dirty, spend your time on the project, and can back up your ideas with something that compiles.
To do that effectively, of course, you should do your homework on the project itself, including learning how a project prefers to receive submissions and which branches are the stable and development ones.
To approach getting started:
- Get familiar with a project and its development culture, and be respectful of it.
- Write patches, bug fixes, or small, requested features, and submit them.
- Don't get discouraged if your work is rejected. You are not being rejected personally, your work was evaluated and the development team made a call.
- 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. Some sites try to make it seem like they have such a thing, but there isn't one. Participate, contribute, add to the pool of ideas, add to the stash of commits, and you're doing it right.
Develop
Programming in any environment is always, ultimately, about personal development. Whether you're searching for new ways of solving problems, looking for new ways to optimize code, learning a new language, or learning how to deal with other people better, you never want to stop growing. The more you develop yourself, the more a project benefits.
Growth, both personal and professional, is the final one on the list, but it actually persists through the entire 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, and you learn some more.
This process is 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.
8 Comments