How to Become a Free Software Hacker

2024 Author: Samantha Chapman | [email protected]. Last modified: 2023-12-17 09:13

Writing and using free software is not just a way of programming, but a real philosophy in all respects. If knowing a programming language is (more or less) all you need to know to be able to code, this article will also tell you how to join the hacker community, find friends, do a great job together, and become a respected specialist with a profile impossible to create in other ways. In the world of free software you can easily obtain tasks that in a business context are instead reserved and granted only to the greatest experts, to the elite of programmers. Think about how much experience you will receive in the field. However, once you decide to become a free software programmer (or hacker), you need to be prepared to invest a lot of time to achieve this, even if you are already a student of computer science. This article is in no way about how to become a hacker (or cracker).

Steps

Step 1. Get a good Unix distribution

GNU / Linux is one of the most popular for hacking programming but often GNU Hurd, BSD, Solaris and (more or less) Mac OS X are also used.

Step 2. Learn how to use the command line

You can do a lot more with a Unix operating system if you use the command line interface.

Step 3. Learn some popular programming languages to a relatively satisfactory level

Without them, you won't be able to contribute by programming (the most important part of any project) for the free software community. Some sources suggest starting two programming languages at the same time: one for system (C, Java or similar) and one for scripting (Python, Ruby, Perl or similar).

Step 4. To be more productive, learn to use Eclipse or other similar integrated development tools

Step 5. Learn and use advanced editors like VI or Emacs

Learning difficulties are greater but you will be able to do a lot more with these tools.

Step 6. Learn about version control

Version control is arguably the most important cooperation tool for shared software development. Understand how to create and apply updates since most free software development in the community is done by just creating, discussing and applying the various updates and patches.

Step 7. Find a suitable, small-sized free software project that you can easily add to for experience

Most projects of this type today can be found on SourceForge.net. The suitable project must:

1. Use the programming language you know.
2. Be active with recent releases.
3. Already have three to five programmers.
4. Use version control.
5. Have some parts that you think you can start practicing immediately without changing the existing code too much.

6. In addition to code, a good project has active discussion lists, bug reports, welcomes and runs requests for improvement, and displays similar activity.

   

   Step 8. Contact the administrator of the project you have chosen

   In a small project with few programmers, your help should usually be accepted immediately.

   

   Step 9. Read the project rules carefully and try to follow them roughly

   Programming style rules or the need to document your changes in a separate text file might seem ridiculous to you at first. However, the purpose they have is to make shared work possible, which is why most projects use them.

   

   Step 10. Work on this project for a few months

   Listen carefully to what the administrator and other project members are saying. In addition to programming, there will be a lot of other things to learn. But if there really is something you don't like, feel free to just leave and look for another project.

   

   Step 11. Don't stick to the small project for too long

   As soon as you find yourself working successfully on that team, it's time to look for something more serious.

   

   Step 12. Find a serious, high-level free software project

   GNU or Apache organizations own most of the projects of this type.

   

   Step 13. As you are now taking the plunge, be ready for a much colder welcome

   You will likely be asked to work for a period of time without having direct access to the repository code. The previous minor project, however, should have taught you a lot. After several months of productive contributions you can then try to ask for the rights you think you should begin to owe.

   

   Step 14. Get serious work done and get it done

   It's time, don't be afraid. Go on even after you discover that the task is much more difficult than you thought at the beginning, right now, it is very important not to give up.

   

   Step 15. If you can, apply your serious work to Google's "Summer of Code" to get some money from this adventure

   But don't worry in any way if the application isn't accepted as they have far fewer funding options than really good programmers.

   

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

   After informing the organizers that you are representing a serious free / open source project, you should normally be exempt from paying conference admission (if they don't, the conference is probably not suitable anyway). Bring your laptop with Linux (if you have one) and run the demos. Ask the project administrator for material you might need to prepare your speech or presentation.

   

   Step 17. Search the internet for announcements about an install party taking place nearby and try to join, as a first time user (looking at the various problems and how programmers fix them), and as an installer the next one

   

   Step 18. Finish the job, complete it with automatic texts and bring your contribution to the project

   Are you done! To be sure, try meeting the other programmers on the project in person for a beer.

   

   Step 19. For a better understanding, look for a concrete example of a free software project (see above) in the development history

   Each growing curve represents a contribution (lines of code) from a single developer. Developers tend to become less active over the years but the speed of the project often even increases as new people are added. So if you already come with some useful skills, there's no reason the team would choose not to invite you.

   Advice

   • Before asking any questions about the rules of conduct in the project, try to find the answers in the project documentation and in the mailing list archives.
   • Always continue the programming you started. Doesn't work, does it crash? There is a reason for everything and if you have the source code available, it usually means that you can force the system to do whatever you want, especially with the help of web search. This rule has its limitations but, on the whole, it tends to remain valid.
   • Only call yourself a hacker after some real hacker community has recognized you as such.
   • In the beginning, choose a class, module or some other unit that no one is actively working on at the moment. Working together with the same class or even just the same function requires greater skills and a lot of care from everyone.
   • The employers of some hacker programmers appear to have sufficient motivation to allow contributions to open source projects during working hours (usually because the company itself uses the open source program the hacker is developing). Think about it, you might be able to get at least some of the time you need this way.
   • If you still don't have enough faith in yourself, start with some parts of the code that you think are missing and could be written from scratch. Changes to existing code are more likely to be criticized.

   Warnings

   • In informal project meetings (like a beer out in the evening) that you haven't contributed in any way yet, you may have the unpleasant feeling of being totally ignored. Don't worry, some hackers make good friends later on, once you get respect with your programming contributions.
   • Don't start with small code refinements, ancillary comments, programming style improvements, and other "small caliber" things. You risk attracting much more criticism than serious contributions. Instead, collect all of these items in a single 'cleanup' update (patch).
   • Your reputation as a hacker in the project community reflects your present more than the past. In particular, if you want to be recommended, referenced or anything similar by your project leader ask him to do so while you are still actively contributing.
   • Avoid asking any questions related to fundamentals or programming tools. The time of a free software programmer is precious. Instead, discuss the basics of programming in forums or environments for newbies and beginners.
   • While the word "hacker" commands respect in most academic circles, some uninformed person could be associated with illegal operations in security systems or similar cybercrimes committed by groups of people with different intentions (called crackers in jargon). Unless you're willing to explain every time, pay attention to the person you're using this word with. Real hackers, as understood in this article, never participate in programming activities that may even appear illegal to them. First, they pride themselves on following the hacker ethic and secondly, violations of the law don't necessarily get paid better.
   • If you are going to meet free software hackers face to face, always leave your Windows laptop at home. Macs are somewhat tolerated more, but still not welcome. If you take your laptop with you, it must have Linux or another operating system installed that is considered "free software".
   • In the cooperative world of free software when programming, in rare cases even your entire group project can suddenly be replaced by someone else's contribution. Mature hackers are welcoming and benefiting from the new code being made available, and there is no better way to react. However, this attitude does not arise spontaneously and must be learned and improved with time and experience.
   • For the same reason, never expect a more experienced hacker to give you a detailed description of your task or provide you with any kind of supervision. Although open source projects can often have numerous strict rules, they usually work on the guidelines of what is known as extreme programming in software development methodology.
   • If your email client supports html messages, please disable this feature. Never attach documents that only proprietary software (such as Microsoft Word) can properly open. Hackers take this as an insult.
   • Do not voluntarily contribute to projects owned by companies that do not release parts of the code under an approved open source license. In these cases, the truly important parts of the project are more likely to remain in the owners' private folders, preventing you from learning anything useful.
   • Don't start by starting your own personal project, unless you want to remain in proud solitude forever. For the same reason, don't start by trying to revive an abandoned project that has already seen its former team vanish.
   • Projects that are already very successful may have rules, written or not, that give you nothing in exchange for the work you do (no money, the possibility of self-promotion, prestigious positions, etc.) regardless of contributions, such as in the case of of wikipedia). If you don't like that attitude, stick to projects that are more medium-sized and can't afford such behavior.
   • Large free software projects, especially around the GNU domain, do not consider your (professional, paid) work a private matter. If you get or change jobs in an IT company, they often require your employer to sign some agreements [1] that they may or may not want to sign. This may prompt you to choose the project with the least demanding conditions.