Alexey Kuznetsov who happy-go-lucky "turned" into the hacker's Linux replaced the profession from the physicist-theorist with the system programmer.
The IT journalist Pyotr Semiletov in addition to the main work develops ten years the text editor of Tea open source.
Lesya Novaselskaya who received profession of the pathologist participates in testing of the project with an open source code.
Similar examples set. All these people are integrated by one — they implemented the interests in projects open source and participated in them both for pleasure, and for receipt of experience. There was a certain myth that the open project is only for programmers, and that who already have a wide experience in development. But it not so. The open project is not only development of the source code, but also testing, technical support, writing of documentation, marketing, etc. And still — excellent chance to gain experience and to derive pleasure from communication with the same adherents as you. According to results of vote the main obstacle for participation in the open project is absence of understanding of how to join the project. Therefore we will understand article as well as as whom it is possible to join such project.
Write a new code
Do not think that you need to be a genius to begin to work on the project. If you know a programming language which is used in the project — implement new functionality and suggest to take your practices in the project. All developers, irrespective of experience and qualification, can help with the project to you with a code. In one projects are more loyal to beginners, in others less. But if your practices bring benefit to other people, then your code will not remain unnoticed.
The internal technical processes therefore learn about them more are characteristic of each project before offering the option. For example, on the PostgreSQL project all processes are strictly regulated: changes in a code go in the form of a patch in mailing by all of the main to developers who carefully study all changes. On the other hand, there are also other types of projects as, for example, Parrot where programmers can "kommitit" the main repository. If on the project GitHub, perhaps is used, processes are put through pull request'y, i.e. through requests for inclusion of the made changes. You remember: two identical projects are absent. Every time when you rewrite a code, do not forget that you work in command therefore do everything possible that your style matched the style accepted in the project. The part of a code which you add or you change should not be beaten out from the general code. You can have preferences in a design of a code, but your code has to conform to the general standards accepted in the project. Otherwise it the same as to tell: "I do not like your style, and I think that wash better therefore you have to do as I".
Certainly, the code is a basis of any open project, but its writing – not the only way of participation in it. Often pay to technical support not enough attention in a pursuit of creation of new functionality and correction of errors. And it is also those areas which allow even to beginners to enter the project.
For example, the OpenVZ project has completely open system of work with defects — bugs.openvz.org where collected all known (corrected and uncorrected) problems for all the time of existence of the project (almost ten years). The bug tracker – one of communication mechanisms between developers and users. Permanent job with the current requests gives the excellent chance to make the contribution to the project. Special access rights which to you will be provided by the project manager can be necessary for you for work with system, following the principles of a meritocracy.
Test intermediate versions
Poll in community of software testers showed that interest in software testing open source from professional testers is. Many would like to participate in such projects, but do not know what to begin with. In turn in any project (even in commercial) there is always a shortcoming of testers. Detection and sorting of bugs can save considerably time to developers on search of a problem. If the user writes: "The program does not work when I take such steps" — be not too lazy to understand what caused this problem. The problem repeats? You can show it, having repeated a number of specific steps? To narrow a problem circle to the specific browser or a distribution kit? Even if you do not know an actual reason of a problem, attempt to narrow a circle of the possible reasons in many respects will help developers to cope with it. Regardless of the fact that you managed to find out, add the comments to a bug that all could study them.
By the experience I can tell that open projects do not have enough resources well to test new functionality. Therefore before adding serious changes to the main branch of a repository of the source code the project tries to attract as much as possible people to testing. Such practice and is called — an appeal to testing (call for testing). Any project has no that quantity of hardware and program configurations which the community of this project has. Developers of the OpenBSD project announce emergence of new functionality in news to draw attention of testers and users to it. We do the same and in the OpenVZ project — we publish the list of the new functionality available to testing.
You can take part in testing and be convinced that the product works at this or that platform. As a rule, you need to collect and set new "билд" and to test a product, but it is especially significant for the project if you use non-standard hardware. If you confirm that assembly works and under such circumstances, it will significantly facilitate a task of project managers in determination of a current status of release.
In the majority of projects the program complexes intended for testing of a code are used, but it is difficult to imagine such complex which would not provide a possibility of adding in it new tests. Use such test tools as gcov for C to set those areas of the source code which cannot be tested the available tests. Then add the corresponding test to have an opportunity to test necessary functionality.
Fix bugs and add new functionality
The patch with correction of a problem or adding functionality necessary for you is some kind of classical method of involvement in the open project (if you remember, all movement for free software began with it in general). This method is recommended also by James Bottomli, CTO Virtuozzo, that who wants to take part in the Linux-project, but does not know how. Usually it cites as an example a case when it had a need for change of functionality of SIP of the client for Android. He found lack of necessary functionality, made a patch and sent to the SIPdroid project.
During creation of new functionality it is also quite good to add the test for testing of that part of a code which you corrected; some projects demand that all corrections of defects were followed by the corresponding tests. Keep records as you master an unfamiliar code. Even if you cannot cope with a bug, describe in a tiketa what you managed to find out about it. It will help those participants of command who will work with bugs after you.
Help to support infrastructure of the project
The DevOps area is interesting to you? This direction is very popular now. It is very difficult to find good engineers of DevOps, we know it on own experience. It is possible to get experience in projects in which open-cast mining of infrastructure is conducted. These are such projects as Wikipedia, the Fedora Linux project. OpenVZ only takes the first steps in this direction.
Setup of process of continuous integration for project components, batching of components for Linux of distribution kits, automatic adjustment of an environment of the developer — all this too problems of DevOps.
Write and translate documentation
Maintaining documentation – a routine component of any project which often neglect. Besides, problems with documentation can be often caused by the fact that it is written from the point of view of the people well familiar with the project, but not those who only get acquainted with it. If when reading documentation on the project you were visited sometime by thought: "Such feeling that it was written as if I already know how to use the program", you understand what the speech about. Very often new view from outside allows to reveal shortcomings of the current documentation which direct participants of the project can not notice. Besides in dynamically developing projects documentation quickly becomes outdated and she is required to be supported in an actual status.
If you for any reason think that it is "frivolous" to be engaged in it, then you are mistaken. There is no "serious" or "frivolous" contribution to the open project. For example, the OpenBSD developer (at the same time and the employee of CERN) Ingo Schwartz (Ingo Schwarze) wrote the utility of mandoc which is used for formatting of pages of documentation not only in OpenBSD now, but also in FreeBSD, NetBSD, DragonFlyBSD and in passing put in order formatting of the existing pages of documentation in the project. He told about it on BSDCan 2015. So all depends on what is interesting to you. If it is interesting — undertake and do!
Help other users with their problems
The best method to rally command is to help others. For further project success it is especially important to answer questions, in particular, on questions of beginners. This time will not be spent in vain even if it asks a question on which it is possible to find the answer, having re-read necessary documentation. Besides, you receive the new grateful and active participant of the command. All begin with something, and permanent inflow of frames that it continued to develop is necessary for any project.
Advertize the favourite project
If you have a blog, impart experience which you received in the project. Tell about problems which you faced when using software and as you managed to solve them. Thus, you will be able to kill two hares at once: to support attention to the project of the colleagues and to create useful base of information for those who will join it in the future and will look for answers to the questions which are already described by you in a network. The blog telling about your technical achievements and researches is also excellent method to share real experience of development and a solution of technical issues which can be useful to you by search of new work. In many projects there are aggregators of records from blogs of participants of the project, traditionally they are called "planets": planets of OpenVZ, Linux kernel, Perl, Freedesktop, Gnome, Debian, etc. Records of the people who are carried away by the business can be interesting even if you are not connected with the project in any way.
The design is a scourge of the majority of open projects. The boring websites, ordinary-looking logos accompany projects just because technical people are generally fixated on implementation, but not on how it has to look. Therefore participation of designers is extremely welcomed. Users of the website StackExchange tried to answer the questions "as the graphic designer can make a contribution to the open project", "what the designer for participation in the open project has to be based on", but their opinions dispersed. Designers from the RedHat company also realized need of more active participation of designers for open projects and tried to create the website which will help open projects and designers to find each other, but I did not hear about the facts of successful application of the project yet.
Look for tasks which are interesting to you and are useful to the project and try to solve them. Methods of participation in the project can differ from the project to the project therefore pages with the description of options of participation in the project can be excellent start: OpenStack, OpenVZ, FreeBSD, etc. The fact that the project has such page says that it is open for participation of other people.
To buttress up all our words by facts we collected responses of three people who got professional experience in open projects:
Alexander Yurchenko, the developer in the company of Yandex:
For money (the developer of the built-in systems) I came to the first serious work being already more than a year an official developer of a kernel of the free OpenBSD operating system. – in sense at me access to record to a repository was official. And before still for about a year I was the "viewer" sending patches to developers.
Has to tell that participation in the similar project gives enormous experience. In good large opensource the project there is everything that usually demand from the developer on interview: both competent design, and good coding, and skill of work with the monitoring system of versions and bug tracker, and also peer review, team working, etc., etc. Thus, "having boiled" year - another in such atmosphere, it is possible to grow to the level which corresponds to a Senior developer position easily.
Actually, with me and was. I had no formal experience (on labor), but I was taken the senior developer at once. And after the first week the trial period was reduced since three months to zero :)
Kirill Gorkunov, developer of the OpenVZ and CRIU projects:
Got to OpenVZ rather accidentally. On work went in for generally application programming which almost does not have crosspoints with system. At some point purchased the first 64-bit notebook (Acer with AMD Turion 64), well and as Windows 64 bit at hand was not, delivered to Gentoo. With Linux until had practically no acquaintance, so, to be played put some ancient RedHat, but especially did not impress and this OS was not suitable for a solution of the current working tasks. Under Gentoo the laptop more or less worked, but some drivers were not in standard delivery of a kernel so it was necessary to collect the kernel from source codes. Here I also caught the first bug, however, not in the kernel, and in the program of forming of a configuration of a kernel. Poryskal on a network — solutions is not present, well and decided to try to correct. It appeared, it was necessary to deal with a set of adjacent tasks (as the kernel what tools are used, etc. gathers) . Made a patch, sent in mailing. To my astonishment, meynteyner of a kernel treated very favourably even such "curve" patch (running forward, I will tell what had to be remade as the patch was disgusting, just did not begin to let "go whistle" at once), but there was no snicker towards the beginner: explained as as, and showed how it is correct to do.
Interested a kernel further — as works what algorithms are used. In this respect "openness" of the project renders invaluable service: it is possible to look as these or those problems are solved (not some theoretical, but real). Quite often there was a question "and why so, but not so", and here it is extremely useful to have back coupling with the author of a code. Open mailing lists not only allow to ask the developers "as as", but what is more important, serve as something like the knowledge base — it is always possible to look in archives of discussion of problems and methods of their solutions.
For the beginning programmer without experience, such environment — just fertile field to try the hand, to understand and whether all this is necessary to me.
Approximately so was also with me: several years governed something in a code, sent patches, was hit on hands for a curve code, well and approvals if the patch was correct and beautiful. Such experience is actually invaluable. Also it is possible to be sure if at you it begins something to turn out then sentences about work will appear. I and was crossed with the Linux developers of a kernel from OpenVZ. And further decided to work together on OpenVZ a kernel and adjacent programs, without forgetting of course and about a vanilla kernel.
Openness of the project — extremely important help when training in practical programming, but it is necessary to understand that the project to the project discord, and openness in itself does not guarantee quality of a code at all (if to download the code on gitkhab, it does not become from it a good code). As well as the return — the closed code is not a priori good or safe.
Alexander Polyakov, developer
I think in my history there is nothing original. As it occurs usually — begin to use some software also suddenly it turns out that it would be desirable that something in it worked not absolutely so or something is missing, or there are opposite jambs.
In case of an opensors there is an opportunity to correct it. So was with the window manager of dwm in whom I was irritated by a configuration through config.h with recompilation: at first I added a config through xrdb, then click to focus, etc. Such changes did not correspond to minimalist guidelines of the project therefore it was necessary to do fork. With DragonFlyBSD approximately the same: enticing texts on the website sounded interestingly, FreeBSD bothered, but suddenly it turned out that there bad support of the languages other than English, and energy managements (ACPI). It was necessary to be engaged in porting of necessary code locations from fresher FreeBSD version. Strongly other developers from the IRC channel helped, explained that they to what helped to deal with problems. There I got some experience of development of a kernel and system libraries. Still it was succeeded to earn on it a little money — there was a person from Moscow who used DragonFlyBSD in the prodakshena, and too something wanted to tighten up in ACPI and the driver of some raid (it seems) there. Found me through git log, communicated by mail.
In OpenBSD I only on a trifle threw some patches — in cwm dopilivat something for convenience (in wm'ax that I was already a specialist), in ksh corrected couple of jambs and improved vi mode. In this project the relation to new kontribyyutor not the best — is supposed that you independently will understand everything, and will write only after that to mailing. The threshold of entry turns out high, only the most resistant survive, but the code turns out good.
Still I in 9front participated: finished the driver for WiFi and, already familiar to me, ACPI. They have probably the smallest working implementation of the AML interpreter. And a kernel quite compact (in comparison with "normal" OS) therefore it is simpler to understand. Bragged of it on interview as far as helped (or on the contrary) — I do not know.
There now and so it is possible to get experience in open projects. The main thing not to be afraid to send a curve code (happens at all), to keep calm (when he is cursed) and to select projects which are really interesting to you. And experience you will derive also pleasure. Still there is a chance that the employer will find you on kommita or a profile in a gitkhaba (Hi, Google!).
This article is a translation of the original post at habrahabr.ru/post/274217/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: firstname.lastname@example.org.
We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.