How to become a free software hacker

Writing and using free software is not only a kind of programming, it is a kind of philosophy. While knowing a programming language is all it takes to program, this article is about how to join a community, make friends, do great things together, and become a respected professional with a profile you can't get anywhere else. In a free software society, you can quite easily end up with tasks that, in a company, only top-level elite programmers are allowed to do. Think about the amount of experience this can bring. However, if you once decide to become a free software hacker, you should be willing to spend some time pursuing that goal. This is still true even if you are already an IT student. Also, this article is not about how to become a cracker.

Steps

Step 1. Get a good Unix distribution

GNU / Linux are some of the most popular to crack, but GNU Hurd, BSD, Solaris, and (to some extent) Mac OS X are often used.

Step 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.

Step 3. Learn some popular programming languages until you reach a more or less satisfactory level

Without it, you cannot contribute code (the most important part of any software project) to the free software community. Some sources suggest starting with two languages at once: one system language (C, Java, or similar) and one scripting language (Python, Ruby, Perl, or similar).

Step 4. To be more productive, learn Eclipse or another similar integrated development tool

Step 5. Learn and use an advanced editor like VI or Emacs

They are not easy to learn, but you can do a lot more with them.

Step 6. Examine the Version control

Version control is probably the most important collaboration tool for overall software development. Understand how to create and apply patches (text file changes). Most free software development in the community involves creating, discussing, and applying various patches.

Step 7. Find a suitable small software free project that you can easily join in order to gain experience

Most of these projects can now be found on SourceForge.net. A suitable project should:

1. use a programming language that you know.
2. Be proactive with the latest releases.
3. Already have 3-5 developers.
4. Use a version control system.
5. Have a piece that you think you can get started right away without making a lot of changes to existing code.
6. Besides the code, a good project also has active discussion lists, bug reports, accepts and implements improvement requests, and shows other similar actions.

7. 

   Step 8. Contact the administrator of the selected project

   On a small project with several developers, your help will usually be immediately accepted.

   

   Step 9. Read the project rules carefully, and more or less follow them

   Coding style rules or the need to document your changes in a separate text file may seem ridiculous at first glance. However, the purpose of these rules is to make collaboration possible, and most projects do have them.

   

   Step 10. Work on this project for several months

   Listen carefully to what the administrator and other project participants have to say. Besides programming, you have a lot to learn. But if you really don't like something, just go to another project.

   

   Step 11. Don't hang on to the undercover project for too long

   Once you understand that you are successfully working in this team, it's time to look for a serious project.

   

   Step 12. Find a serious free software project or open source project

   Most of these projects are owned by the GNU or Apache organizations.

   

   Step 13. Once you make the big leap, be ready for a much cooler confession

   You will probably be prompted to work for some time without direct write access to the code repository. The previous covert project should, however, teach you a lot - so after a few months of productive contributions, you can try to claim the rights that you think you should have.

   

   Step 14. Take and do a serious task

   The time has come. Do not be afraid. Continue persevering even if you find that the task is much more difficult than you originally thought. At this point, it's important not to give up.

   

   Step 15. If you can, take a serious challenge to Google's Summer of Code initiative to get some money out of this adventure

   But just don't worry if the application is not accepted, as they fund the positions much less than really good hackers.

   

   Step 16. Look for a suitable conference nearby ("Linux Days" or something similar) and try to present your project there (the whole project, not just the part you are programming)

   Once you show that you are a serious Free / open source project, the organizers often release you from the conference fees (if they don't, the conference is most likely inappropriate anyway). Bring your Linux laptop (if you have one) and run the demo. Ask your project administrator for material you can use in preparing for your talk or poster.

   

   Step 17. Search the Internet for an “Install party” event happening nearby and try joining it first time as a user (follow up on all problems and how hackers solve them), and next time as an installer

   

   Step 18. Complete the task, apply automated tests and your input to the project

   Done! It should be noted: try to meet some of the project's hackers in real life and have a glass of beer with them.

   

   Step 19. For a better understanding, take a look at the real-life example of the development history of a Free Software project (above)

   Each rise in the curve represents a contribution (lines of code) from one developer. Developers tend to become less active over the years, but the project often even speeds up when new people join. Therefore, if you are already coming with some useful skills, there is no reason for the team not to invite you.

   Advice

   • Before asking any question about working rules within a project, try searching the project documentation and the mailing list archives for the answer.
   • You will only be called a hacker after you are recognized as such by some true Hacking Community.
   • Always keep hacking what you started. Not building, not starting, crashing (crashing)? There are reasons for everything, and if you have the source code it usually means you can make the system do whatever you want, especially with a web search. This rule has its limitations, but it really never comes easily.
   • First, select a class, module or other block that no one is actively working on at the moment. Working together on the same class or even function requires more skill and a lot of attention from all sides.
   • Some hackers' employers seem to be motivated enough to allow "collaboration" during their working hours (usually because the organization uses a free / open source program that the hacker develops). Think maybe you can get at least some of the time you need this way.
   • If you still don't trust yourself enough, start with some piece of code that you think is missing and could be written from scratch. Changes to existing code are much more likely to attract criticism.

   Warnings

   • Don't start with small code optimizations, extra comments, coding style improvements, and other similar "small" stuff. This can generate much more criticism than any major contribution. Instead, collect them into a single "cleanup" patch.
   • In an informal project meeting (on beer) that you have never contributed to any code, you will have the unpleasant feeling of being quite ignored. Don't worry, some hackers become great friends later, after you earn respect for your code.
   • If you are planning to meet face-to-face with free software hackers, always leave your Windows laptop at home. Mac OS is a slightly better option, but not welcome either. If you have a laptop with you, it should be running Linux or another operating system they think is "Free software".
   • Your status as a hacker in the project community reflects your present more than your past. In particular, if you want a recommendation from a project manager or something similar, ask questions while you are still actively collaborating.
   • Do not start by starting your own project if you do not want to be left in splendid loneliness forever. For the same reason, don't start by trying to revive an abandoned project that has already lost its previous command (see why).
   • For the same reason, never expect an experienced hacker to write a detailed description of your task or even provide your loved one with a kind of observation. While open source projects can have many strict rules, they usually work by analogy with what is known as programming in programming methodology.
   • In the consistently operating world of free software, you code, and on rare occasions, even your team's entire project might be unexpectedly replaced by some other contribution. Examples of large-scale rewrites: Harmony or, for example, the more recent history of the GNU Classpath. Mature hackers say "welcome" and take advantage of the new code that becomes available - there is simply no better way to respond. This, however, does not come easily and needs to be learned. See an example of such a position.
   • Avoid asking any question related to programming fundamentals or software tools. The time of a free software programmer is valuable. Instead, discuss the basics of programming in the hobbyist or beginner communities.
   • Although the word "hacker" sounds respectful in most learning environments, for some uninformed people it can be associated with security breaches and other computer-related crimes that various social groups (crackers or crackers) commit. If you are not ready to explain, look at those to whom you are speaking this word. The real hackers in this article will never get involved in any programming activity that seems illegal to them. First, they take pride in adhering to the hacker ethic. Second, breaking the law doesn't necessarily pay better.
   • If your email client supports HTML messages, disable this feature. Never attach documents that only proprietary software (eg MS Word) can open properly. Hackers take this as an insult.
   • Do not offer your services to company-owned projects that do not release certain portions of their code under an approved Open Source license. In such cases, the really important parts of the project are likely to be “left behind closed doors” by the owner, preventing you from learning anything useful.
   • Already very successful projects may have a written or verbal policy to never return anything for your work (no money, no self-promotion opportunities, no high status regardless of contribution, etc. - see Wikipedia). if you disagree with this, stick to mid-range projects that cannot afford this position. Large free projects

   software, especially around the GNU domain, does not treat your work as your own business. After you get or change jobs at a software company, they will ask your employer to sign certain agreements [1] that you can sign or not. This can force you to choose a project with more loose requirements.