A simple opportunity to gain experience in IT

Anesthesiologist Con Kolivas developed his own version of the task scheduler for the Linux kernel , because the existing implementation was adapted for server tasks, but did not satisfactorily handle user tasks.

Alexei Kuznetsov, who by chance has turned into a Linux hacker , changed his profession from a theoretical physicist to a system programmer.

IT journalist Peter Semiletov, in addition to his main job, has been developing his open-source text editor Tea for ten years.
')
Lesya Novasielskaya, who received the specialty of the pathologist, is involved in testing the project with open source.

There are many similar examples. All these people are united by one thing - they realized their interests in open source projects and participated in them both for fun and for gaining experience. There was a certain myth that an open project is only for programmers, and those who already have extensive experience in development. But it is not. An open project is not only developing source code, but also testing, technical support, writing documentation, marketing, etc. And yet - a great chance to gain experience and enjoy the pleasure of communicating with like-minded people like you. According to the voting results, the main obstacle to participation in an open project is the lack of understanding of how to join the project. Therefore, in the article we will understand how and in what capacity one can join such a project.

Write a new code

Do not think that you need to be a genius to start working on a project. If you know the programming language used in the project, implement the new functionality and offer to take your work into the project. All developers in the project, regardless of experience and qualifications, can help you with the code. In some projects they are more loyal to beginners, in others less. But if your ideas benefit other people, your code will not go unnoticed.

Each project has its own internal technical processes, so learn more about them before proposing your own version. For example, in the PostgreSQL project, all processes are tightly regulated: changes in the code are sent in the form of a patch in the mailing list to all major developers, who carefully study all the changes. On the other hand, there are other types of projects, such as Parrot, where programmers can commit the main repository. If GitHub is used on the project, it is possible that the processes are delivered via pull requests, i.e. through requests to incorporate the changes made. Remember: no two projects are alike. Whenever you rewrite the code, do not forget that you work in a team, so do your best to match your style with the style adopted in the project. The part of the code that you add or change should not be out of the general code. You may have your own preferences in the design of the code, but your code must comply with the general standards adopted in the project. Otherwise, this is the same as saying: “I don’t like your style, and I think mine is better, so you should do as I do.”

Prioritize defects

Of course, the code is the basis of any open project, but writing it is not the only way to participate in it. Technical support is often not given enough attention in the pursuit of creating new features and fixing bugs. But it is precisely these areas that allow even beginners to enter the project.

For example, the OpenVZ project has a completely open system for dealing with defects - bugs.openvz.org , where all the known (corrected and uncorrected) problems have been collected for the entire life of the project (almost ten years). A bugtracker is one of the communication mechanisms between developers and users. Constant work with current requests provides an excellent opportunity to contribute to the project. To work with the system, you may need special access rights that the project manager will grant you, following the principles of meritocracy .

Test intermediate versions

A survey in the software testers community has shown that there is interest in testing open source software from professional testers. Many would like to participate in such projects, but do not know where to start. In turn, in any project (even a commercial one) there is always a lack of testers. Detecting and sorting bugs can save a lot of time for developers to search for problems. If the user writes: “The program does not work when I take such and such steps,” - do not be lazy to understand what caused this problem. The problem repeats? Can you demonstrate it by repeating a series of specific steps? To narrow the circle of problems to a specific browser or distribution kit? Even if you do not know the true cause of the problem, attempts to narrow down the range of possible causes will in many ways help the developers to deal with it. Regardless of what you found out, add your comments to the bug so that everyone can read them.

From my own experience I can say that open projects do not have enough resources to test new functionality well. Therefore, before adding major changes to the main branch of the source code repository, the project tries to attract as many people as possible for testing. This practice is called - call for testing. No project has the number of hardware and software configurations that the community of this project has. The OpenBSD project developers announce the appearance of new functionality in the news in order to attract the attention of testers and users to it. We do the same thing in the OpenVZ project - we publish a list of new functionality available for testing.

You can take part in testing and make sure that the product works on a particular platform. As a rule, you need to build and install a new “build” and test the product, but it is especially significant for a project if you use non-standard hardware. If you confirm that the build works under these conditions, it will greatly facilitate the task of project managers in determining the current release status.

Write tests

Most projects use software systems designed for testing code, but it is difficult to imagine such a complex that would not provide for the possibility of adding new tests to it. Use test tools like gcov for C to set up areas of the source code that cannot be tested with existing tests. Then add the appropriate test to be able to test the necessary functionality.

Fix bugs and add new functionality

A patch with fixing a problem or adding functionality you need is a kind of classic way of engaging in an open project (if you remember, the whole movement for free software started with this ). This method is also recommended by James Bottomley , CTO Virtuozzo, for those who want to participate in a Linux project, but do not know how. Usually, he cites the example of a case when he had a need to change the functionality of the SIP client in Android. He found the lack of necessary functionality, made a patch and sent it to the SIPdroid project.

When creating a new functionality, it is also a good idea to add a test to test the part of the code that you fixed; Some projects require that all defect corrections be accompanied by appropriate tests. Keep a record as you master unfamiliar code. Even if you cannot cope with the bug, describe in the ticket what you managed to find out about it. This will help those team members who will work with bugs after you.

Help maintain project infrastructure

Are you interested in the DevOps area? This direction is now very popular. It is very difficult to find good DevOps engineers, we know this from our own experience. You can gain experience in projects in which an open infrastructure is being developed. These are projects such as Wikipedia , the Fedora Linux project. OpenVZ only takes the first steps in this direction.

Setting up a continuous integration process for project components, packaging components for Linux distributions, automatically setting up the developer’s environment — these are also DevOps tasks.

Write and translate documentation

Record keeping is a routine component of any project that is often neglected. In addition, problems with documentation can often be caused by the fact that it is written from the point of view of people who are familiar with the project, and not those who are just acquainted with it. If, while reading the documentation on a project, you have ever been visited by the thought: “It feels like it was written as if I already know how to use the program,” then you understand what it is about. Very often, a new view from the outside makes it possible to identify shortcomings in current documentation that the direct participants in the project may not notice. In addition, in dynamically developing projects, documentation quickly becomes outdated and needs to be kept up to date.

If for some reason you think that it is not serious to do this, then you are mistaken. There is no "serious" or "frivolous" contribution to an open project. For example, the OpenBSD developer (at the same time, and the CERN employee) Ingo Schwartz (Ingo Schwarze) wrote the mandoc utility, which is now used to format the documentation pages not only in OpenBSD, but also in FreeBSD, NetBSD, DragonFlyBSD and in the same way put in order the formatting existing pages of documentation in the project. He told about this at BSDCan 2015. So everything depends on what interests you. If interested - take it and do it!

Help other users with their problems.

The best way to rally a team is to help others. For the future success of the project, it is especially important to answer questions, in particular, questions from newcomers. This time will not be wasted, even if he asks a question to which you can find the answer by re-reading the necessary documentation. In addition, you will receive a new, grateful and active member of your team. Everything starts from something, and any project needs a constant influx of personnel in order for it to continue to develop.

Advertise your favorite project

If you have a blog, share your experience that you got in the project. Tell us about the problems you encountered while using the software and how you managed to solve them. Thus, you will be able to kill two birds at once: maintain attention to the project of your colleagues and create a useful information base for those who will join it in the future and will search the Internet for answers to the questions you have already described. A blog telling you about your technical achievements and research is also a great way to share real-world experience in developing and solving technical problems that might be useful to you when looking for a new job. In many projects, there are aggregators of entries from the blogs of project participants, traditionally called “planets”: the planets OpenVZ , Linux kernel , Perl , Freedesktop , Gnome , Debian , etc. Entries of people who are passionate about their business can be interesting even if you have nothing to do with the project.

Do the design

Design is the scourge of most open source projects. Boring sites, inconspicuous logos accompany projects simply because technical people are mostly focused on implementation, and not on how it should look. Therefore, the participation of designers is extremely welcome. StackExchange users tried to answer the questions “how a graphic designer can contribute to an open project , ” “what should a designer be motivated to participate in an open project,” but their opinions diverged. Designers from RedHat also realized the need for more active participation of designers in open source projects and tried to create a website that will help open projects and designers to find each other, but I have not heard about the facts of successful implementation of the project.

Look for tasks that are interesting to you and useful to the project and try to solve them. Ways to participate in a project may differ from project to project, therefore, a page with a description of options for participating in a project can be an excellent start: OpenStack , OpenVZ , FreeBSD , etc. The fact that the project has such a page says that it is open to the participation of other people.
In order to back up all our words with facts, we collected reviews from three people who gained professional experience in open source projects:

Alexander Yurchenko , developer at Yandex:

I came to my first serious work for money (developer of embedded systems) being more than a year the official kernel developer of the free operating system OpenBSD. Official - in the sense that I had access to write to the repository. And before that, even a year later, I was a “spectator,” sending patches to developers.

I must say that participation in such a project provides tremendous experience. In a good large opensource project there is everything that the developer usually requires at the interview: both competent design, and good coding, and the skill of working with the version control system and bug tracker, as well as peer review, teamwork, etc. etc. Thus, having cooked a year or two in such an atmosphere, one can easily grow to a level that corresponds to the position of Senior developer.

Actually, with me it was. I had no formal work experience (in terms of work), but they immediately took me as a senior developer. And after the first week the trial period was reduced from three months to zero :)

Kirill Gorkunov , project developer for OpenVZ and CRIU:

Got into OpenVZ quite by accident. At work, I was mainly engaged in application programming, which practically had no points of intersection with system programming. At some point I purchased my first 64-bit laptop (Acer with AMD Turion 64), and since Windows 64 was not at hand, I installed Gentoo. I almost didn’t have an acquaintance with Linux before that, so some ancient RedHat posed to play, but it didn’t impress much, and this operating system wasn’t suitable for solving current work tasks. Under Gentoo, the laptop more or less worked, but some drivers were not in the standard kernel package, so I had to build my kernel from source. Then I caught the first bug, though not in the kernel itself, but in the program for generating the kernel configuration. I rushed through the network - there is no solution to the problem, well, I decided to try to fix it myself. It turned out that I had to deal with a variety of related tasks (how the kernel is assembled, what tools are used, etc.). I made a patch, sent it to the newsletter. To my surprise, the kernel kernel maintainers reacted very favorably even to such a “crooked” patch (looking ahead, I would say that I had to redo it, because the patch was still disgusting, they just didn’t immediately give a “turn from the gate”), but there wasn’t any Laughing in the direction of a beginner: they explained what and how, and showed how to do it right.

Then the kernel itself became interested in how it works, what algorithms are used. In this regard, the “openness” of the project provides an invaluable service: you can see how certain tasks are solved (not some theoretical, but real ones). Often there was a question “why so, and not that kind”, and here it is extremely useful to have feedback with the author of the code. Open mailing lists not only allow you to ask the developers what and how, but more importantly, they serve as a kind of knowledge base - you can always search the archives for discussing problems and methods for solving them.

For a novice programmer with no work experience, such an environment is simply fertile ground to try your hand, to understand whether it is necessary for me.

Approximately it was the same with me: for several years, the rules were something in the code, sent patches, got their hands on the curve code, and of approval if the patch was correct and beautiful. Such an experience is virtually priceless. And you can be sure that if something starts to turn out for you, then job offers will immediately appear. I crossed paths with the developers of the Linux kernel from OpenVZ. Well, after that we decided to work together on the OpenVZ core and related programs, without forgetting of course the vanilla core.

The openness of the project is an extremely important help in teaching practical programming, but you should understand that the project is different to the project, and openness in itself does not guarantee the quality of the code (if you download your code to the github, it does not become a good code from this). As well as the opposite - the closed code is not a priori good or safe.

Alexander Polyakov , developer

I think in my story there is nothing original. As it usually happens, you start to use some kind of software and suddenly it turns out that I would like something in it to work not quite or something is missing or there are nasty jambs.
In the case of open-source, there is an opportunity to fix it yourself. So it was with the dwm window manager, in which I was annoyed with the configuration via config.hc recompilation: first I added the config via xrdb, then click to focus, etc. Such changes did not correspond to the minimal guidelines of the project, so I had to fork. DragonFlyBSD is about the same: enticing texts on the site sounded interesting, FreeBSD was tired, but suddenly it turned out that there was poor support for languages ​​other than English and power management (ACPI). I had to do the porting of the necessary sections of code from a more recent version of FreeBSD. Strongly helped by other developers from the IRC channel, explaining what was needed and helped to deal with the problems. There I got some experience developing the kernel and system libraries. I also managed to make some money on this - a man from Moscow was found who used DragonFlyBSD in production, and also wanted to tweak something in ACPI and some kind of raid driver (sort of). Found me through git log, contacted by mail.
In OpenBSD, I just threw some patches on the little things - I finished something in cwm for convenience (in wm, I was already special), in ksh I adjusted a couple of jambs and improved vi mode. In this project, the attitude towards new contributors is not the best - it is assumed that you will understand everything yourself and only after that you will write to the newsletter. The threshold of entry is high, only the most persistent survive, but the code is good.
I also participated in 9front : I finished the driver for WiFi and, already familiar to me, ACPI. They probably have the smallest working implementation of the AML interpreter. And the kernel itself is quite compact (compared to “normal” OS), so it's easier to understand. I boasted about it at the interview, I did not know how much it helped (or vice versa).

Well, so here you can get experience in open source projects. The main thing is not to be afraid to send a curved code (it happens with everyone), keep calm (when it is cursed) and choose projects that you are really interested in. And you will get experience and pleasure. There is still a chance that the employer will find you by commits or profile in the githaba (Hi, Google!).