by Unknown 09:12 0 comments hacks

How to Become a Free Software Hacker

Edited by Audriusa, Monica, Nicole Willson, KnowItSome and 32 others

Writing and using Free software is not just a type of programming, it is a kind of philosophy. While knowing a programming language is all you need to program, this article is about how to join the community, get friends, do great work together, and become a respected specialist with a profile you cannot get anywhere else. In the world of Free software you may rather easily get tasks that in a company only the elite, top level programmers are allowed to do. Think about the amount of experience this can bring. However, if you once decided to become a Free software hacker, you must be ready to invest some time into achieving this goal. This remains true even if you are an IT student already. Also, this article is not about how to become a cracker.

Steps

1. 1
   Get a good Unix distribution. GNU/Linux is one of the most popular for hacking but GNU Hurd, BSD, Solaris and (to some extent) Mac OS X are often used.
   Ad
2. 2
   Learn how to use Command Line. You can do much more with Unix like operating systems if you use command line.
3. 3
   Learn some popular programming language until you reach a more or less satisfactory level. Without this, you cannot contribute code (the most important part of any software project) to the free software community. Some sources suggest to begin at once with two languages[1]: one system language (C, Java or similar) and one scripting language (Python, Ruby, Perl or similar).
4. 4
   To be more productive, learn Eclipse or some other similar integrated development tool.
5. 5
   Learn and use advanced editor like VI or Emacs. They have higher learning curve but you can do much more with them.
6. 6
   Learn version control (CVS, Version control is likely the most important co-operation tool for shared software development. Understand how to create and apply patches (text difference files). Most Free software development in the community is done creating, discussing and applying various patches.
7. 7
   Find a suitable small Free software project which you could easily join to get experience. Most of such projects now 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 developers.
   4. Use version control.
   5. Have some part you think you can immediately start implementing without modifying the existing code too much.
   6. Apart from the code, a good project also has active discussion lists, bug reports, receives and implements requests for enhancement and shows other similar activities.
8. 8
   Contact the administrator of the selected project. In a small project with few developers your help will usually be immediately accepted.
9. 9
   Carefully read the rules of the project and more or less follow them. The rules of the coding style or necessity to document your changes in a separate text file may first appear ridiculous to you. However the purpose of these rules is to make the shared work possible - and the most projects do have them.
10. 10
    Work in this project for several months. Listen carefully that the administrator and other project members say. Apart programming, you have a lot of things to learn. But if you really do not like something, just go away to another project.
11. 11
    Do not stick with the underground project for too long. As soon as you find yourself successfully working in that team, it is time to look for the serious one.
12. 12
    Find a serious, high level Free software or Open source project. Most such projects are owned by GNU or Apache organizations.
13. 13
    As we are doing a serious jump now, be ready for the far cooler acceptance. You will likely be asked to work for some time without direct write access to the code repository. The previous underground project should, however, have taught you a lot - so after several months of the productive contribution you can try to demand rights you think you should have.
14. 14
    Take and do a serious task. It is time. Do not be afraid. Go on even after you discover that the task is lots more difficult than you initially thought - in this step it is important not to give up.
15. 15
    If you can, apply with your serious task to the Google's "Summer of Code" to get some money from this adventure. But just do not care if the application is not accepted as they have far less funded positions than really good hackers.
16. 16
    Look for a suitable conference happening nearby ("Linux days" or something similar) and try to present your project there (all project, not just the part you are programming). After you tell you are representing a serious Free / Open source project, the organizers frequently release you from the conference fee (if they do not, the conference is likely unsuitable anyway). Bring your Linux laptop (if you have one) and run demos. Ask the project administrator for the material you may use when preparing your talk or poster.
17. 17
    Search the web for announcement about the install party happening nearby and try to join it first time as a user (watch for all problems and how hackers solve them) and next time as an installer.
18. 18
    Complete the task, cover with automatic tests and contribute to the project. You are done! To be sure, try to meet some hackers of the project physically and have a glass of beer.
19. 
    19
20. 20
    For better understanding, look into real example of the development history for a Free Software project (above). Each raising curve represents a contribution (lines of code) from single developer. Developers tend to become less active over years but the project frequently even accelerates as new people join. Hence if you already come with some useful skills, there are no reasons why the team would not invite you.
    Ad

Add your own method

Save

Tips

• Before asking any question about the working rules inside the project, try to search for the answer in the project documentation and mailing list archives.
• Only say you are a hacker after some true hacker community recognizes you as such.
• For the beginning, select a class, module or some other unit under which nobody is very actively working at the moment. Working together on the same class or even function needs more skills and a lot of care from all sides.
• If you still do not trust yourself enough, start from some part of code that you think is missing and can be written from scratch. Changes in existing code are much more likely to attract criticism.
• The employers of some hackers seem motivated enough to allow contributions during their working time (usually because the institution uses the Free/Open source program that the hacker is developing). Think, maybe you can get at least part of the needed time this way.
• Always continue the hacking you started. Does not build, does not run, crashes? Thereare reasons for everything and if you have source code this usually means that you canforce the system to do whatever you want, especially with the help of the web search. This rule has its limits, but, indeed, never yield easily.

Ad

Warnings

• If you plan to meet Free software hackers eye to eye, always leave your Windows laptop at home. Mac OS is tolerated somewhat better, but also not welcome. If you do bring your laptop, it must run Linux or other operating system that they consider as "Free software".
• Do not start from small code optimizations, extra comments, coding style improvements and other similar "small-scale" stuff. It may attract far more criticism than any serious contribution. Instead, collect these into a single 'cleanup' patch.
• In cooperative world of Free software you code and in rare cases even all project of your group may be unexpectedly replaced by some other contribution. Examples of large scale overwrites could be the now forgotten Harmony or more recent history of GNU Classpath, for instance. Mature hackers say "welcome" and take benefits of the new code becoming available - there is just no better way to react. This, however, does not come naturally and must be learned. See an example of such an attitude.
• If your mail client supports html messages, turn this feature off. Never attach documents that only proprietary software (like MS Word) can open properly. Hackers understand this as insulting.
• Already very successful projects may have written or unwritten policies never return anything back for your work (no money, no possibility to self - promote, no elevated status regardless of the contribution, etc - see Wikipedia). If you do not accept this well, stick with more mid range projects that cannot afford such attitude.
• While the word "hacker" sounds with respect in the most of the academic environments, for some uninformed people it may associate with breaking into security systems and other computer-related crimes that a different social group (crackers) do. Unless you are ready to explain, look to whom are you telling this word. Real hackers as they are meant in this article never join programming activities that seem for them illegal. First, they are proud of following the hacker ethic. Second, the law violations are not necessarily better paid.
• Do not volunteer to the company-owned projects that are not releasing some parts of they code under approved Open Source license. In such cases the really important parts of the project are likely to stay behind the closed doors of the owner, preventing you from learning anything useful.
• Avoid asking any question related to fundamentals of programming or programming tools. A Free software programmer's time is valuable. Instead, discuss the basics of programming in communities for amateur or new programmers.
• For the same reason, never expect an older hacker to write a detailed description of your task or even provide any kind of supervision for you. While open source projects may have a lot of strict rules, they usually work along the lines of what is known asextreme programming in the programming methodology.
• In the informal meeting like beer event of the project to that you have never contributed any code you will have unpleasant feeling of being highly ignored. Do not worry, some hackers are great friends later, after you earn respect with your code.
• Do not begin from starting your own project, unless you want to stick in a proud loneliness for ever. For the same reason, do not start from the attempt to revive the abandoned project which has already lost its previous team (see why).
• Your hacker status in the project community reflects your present more than your past. In particular, if you want a recommendation from the project leader or anything the like, ask till you are still actively contributing.
• Big Free software projects, especially around GNU domain, do not treat your job as your personal matter. After you get or change the job in a software - related company, they ask your employer to sign certain agreements [2] that these may or may not sign. This can force to select the project with looser requirements.