Content

• To step
• Tips
• Warnings
• Necessities

Writing and using open software is not just a form of programming (also called "hacking" in the world of programmers), it is a kind of philosophy. While you only need to know a programming language to be able to code, this article is about how to join the community, make friends, collaborate on great projects, and become a respected specialist with a profile you can't get elsewhere . In the world of open software, you can quite easily be assigned tasks that only the elite, top-level programmers, are allowed to do in a company. Think about how much experience this can bring you. However, once you have decided to become an open software programmer, you must be willing to invest time in this goal. This also applies if you are already an IT student. Mind you, this article is not about how to become a hacker or cracker.

To step

1. Download a good Unix distribution. GNU / Linux is one of the most popular for programming, but GNU Hurd, BSD, Solaris, and (to an extent) Mac OS X are also commonly used.
2. Learn how to use the command line. You can do a lot more with Unix-like operating systems if you use the command line.
3. Learn some popular programming languages ​​until you reach a more or less satisfactory level. Otherwise, you can't contribute code (the most important part of any software project) to the open software community. Some sources suggest starting with two languages ​​at once: one system language (C, Java or similar) and a scripting language (Python, Ruby, Perl or similar).
4. To be more productive, you need NetBeans or a similar integrated development environment.
5. Learn to use an advanced editor, such as vi or Emacs. They have a higher learning curve, but you can do a lot more with them.
6. Learn about version control. Version control is probably the most important tool of the collaboration for shared software development. Understand how to create and apply patches. Most of the open software development in the community is done through the creation, discussion and application of various patches.
7. Find a suitable, small open software project that you can easily participate in to gain experience. Most such projects can be found on SourceForge.net these days. A suitable project should include:
   1. Use the programming language you know.
   2. Be active, with recent releases.
   3. Already consisting of three to five developers.
   4. To use version control.
   5. Have a part that you can get started on right away, without having to change the existing code too much.
   6. In addition to the code, a good project also has active discussion lists, bug reports, gets and implements improvement requests, and similar activities.
8. Contact the administrator of the selected project. In a small project with few developers, your help will usually be accepted immediately.
9. Read the rules of the project carefully and more or less follow them. The rules of programming style or the need to document your changes in a separate text file may seem ridiculous at first. However, the purpose of these rules is to enable shared work - and most projects work with them.
10. Work on this project for several months. Listen carefully to what the administrator and other project members have to say. Besides programming you have a lot of things to learn. But if you really don't like something, just stop and switch to another project.
11. Don't get stuck in the underground project for too long. Once you find yourself able to work successfully on that team, it's time to start looking for something more serious.
12. Look for a serious, high-level open software or open source project. Most such projects are owned by GNU or Apache organizations.
13. Because we are taking a serious leap here, you have to take into account a much less warm reception. You will most likely be asked to run without direct write access to the code repository for the first time. However, the previous underground project should have taught you a lot - so after several months of making a productive contribution, you can claim the rights you think you should have.
14. Take on a serious task and work it out. It's time. Do not be afraid. Continue even if you find that the task is much more difficult than you initially thought - in this step it is important not to give up.
15. If you can, apply to Google's "Summer of Code" to put some money into this adventure. But don't worry if the application is not accepted as they have far fewer funded positions than there are really good programmers.
16. Find a suitable conference happening nearby ("Linux days" or similar) and try to present your project there (the whole project, and not just the part you program). After you mention that you are representing a serious free / open source project, the organizers will often indemnify you from the conference fee (if not, the conference will likely be unsuitable anyway). Bring your Linux laptop (if you have one) and run some demos. Ask the project manager about the materials you can use to prepare your presentation or poster.
17. Search the Internet for announcements about a nearby installation event and try to participate as a user first (note all the issues that arise and how hackers fix them) and offer to install programs next time.
18. Complete the task, check your work with automatic tests and contribute to the project. You are done! To be sure, try to meet some of the programmers on the project in person and raise a glass of beer together on the result.
19. For a better understanding, look at a real example of the development history of an open software project (see above). Each rising curve represents a contribution (lines of code) from a single developer. Developers tend to become less active with age, but the project often speeds up even as new people join. So if you arrive with some useful skills under your belt, there are no reasons why the team should not invite you.

Tips

• Before you ask a question about the practical requirements within the project, look for the answer in the project documentation and mailing list archives.
• Always keep trying to finish any programming work you have started. Can't be built, can't run, system crashes? There to be reasons for everything, and if you have the source code, it usually means you have the system well can force you to do whatever you want, especially with the help of some online research. This rule has its limits, of course, but it is indeed important to never give up too easily.
• Only call yourself a programmer (or hacker) after you have been recognized as such by some of the real hacker community.
• In the beginning, choose a class, module or other unit where no one is working very actively at the moment. Collaborating on the same class or even a position requires more skills and care from all sides.
• Employers of some hackers / programmers seem motivated enough to allow contributions during working hours (usually because the institution uses the free / open source program the programmer is developing). Think, maybe you can get at least some of the time needed this way.
• If you still don't have enough confidence in yourself, start from some part of the code that you think is missing and can be written from scratch. Changes to existing code are much more likely to be criticized.

Warnings

• Your hacker status within the community project is more a reflection of your present than your past.If you would like a recommendation or similar from the project leader, please ask if you are still actively contributing.
• Don't get into small code optimizations, extra comments, coding style improvements, and other similar "small-scale" things. This can meet with far more criticism than a serious contribution. Instead, you can include these changes in a single "cleanup" patch.
• If you plan to meet the open software hackers in person, leave your Windows laptop at home. Mac OS is slightly more tolerated, but it is not really welcome either. If you bring your laptop, it must be running Linux or some other operating system that they consider "open software."
• If your email client supports HTML messages, you may want to disable this feature. Never attach documents that only commercial software (such as Microsoft Word) can open properly. Hackers consider this offensive.
• Do not volunteer on projects of a company whose code is not covered by an approved open source license. In such cases, the really important parts of the project are likely to remain behind closed doors from the owner, preventing you from learning anything useful.
• Avoid any question about the fundamentals of programming or programming tools. The time of an open software programmer is precious. Instead, discuss the basics of programming in amateur or beginning programmer groups.
• Established and highly successful projects may have written or unwritten policies about never reimbursing your work (no money, no ability to promote yourself, no elevated status regardless of your contribution, etc. - see: Do_not_expect_reward Wikipedia). If you can't agree with this, stick to more common projects that can't afford such an attitude.
• Don't start your own project unless you always want to spend in proud solitude. For the same reason, it is better not to embark on an attempt to revive an already abandoned project that its previous team has already lost.
• In the case of an informal meeting about the project that you never contributed any code to, you will have the unpleasant feeling of being completely ignored. Don't worry, some hackers can become good friends later on after you earn their respect with your own code.
• Large open software projects, especially those around the GNU domain, don't treat your job as your personal business. After you get the job within a software-related company, they ask your employer to sign certain agreements [1], which the company will or will not sign. This can force you to select a project with less stringent requirements.

Necessities

• Linux. Many open software projects are more complicated to build on Windows, or are not build correctly at all. This is especially true for advanced projects dedicated to the programming of cell phones, USB keys and other devices.
• A computer with a relatively good internet connection. If you want to keep dual boot with Windows then a second hard drive or partition for Linux could be a good solution.
• Basic knowledge of at least one programming language and a strong intention to learn more. The most popular languages ​​currently seem to be C and Java.
• A significant amount of time, at least five hours a week (a typical hardcore programmer contributes a whopping 14 hours).
• While formal IT education will make your way a lot easier, this is it not a mandatory requirement and no real hacker community will ever ask you about it. Programmers / hackers judge each other by someone's programming, not fake criteria such as grades, age, race or position. Mind you, at least 60% of the open source hackers who assess your patches have the "correct" college degree and will not allow you to contribute nonsense to the project.
• During the final steps (conference and "install party") you can benefit from your own laptop. But it's not okay to work on it at home, so only buy one if you can afford the second machine.
• The path described to become an open source software "hacker" takes at least two years to complete.