Introduction to the development of a typical open source solution
On September 11, Java Meetup , dedicated to Apache Ignite , was held in St. Petersburg. Many thanks to the organizers for the invitation and the opportunity to talk about Open Source on behalf of the developer of this very Open Source. Considering the positive reaction of the hall, I decided to share the presentation with those who could not attend the meeting.
A text version of the presentation, full of subjective perception of Open Source, both positive and negative, awaits you under the cut.
So, my name is Anton Vinogradov, and for the last 4 years I have been developing the Open Source project Apache Ignite. By his example, I want to talk about how Open Source is being done, what personal benefits you can get from participating in the community, and ultimately, I want to inspire you to participate.
')
I will talk about Open Source on the example of Apache Ignite - one of the many projects of the Apache Software Foundation. ASF is one of the largest Open Source communities with almost 20 years of history. It owes its success, in the first place, to the processes and principles of motivation laid back in 1999, but still relevant. This “philosophical” side of the community was described in detail in his article by Dmitry Pavlov , we will consider the “applied” side of the development of Open Source using the example of Apache Ignite.
Suppose you decide to contribute to community development. How to do it?
In general, we can not say that Open Source - this is about the code. Many different activities can make a significant contribution, and only some of them are directly related to the code.
The most important contribution to Open Source is to inform the community about the problems of the product, its shortcomings. But here it is important to understand that Open Source is not a custom development and the community is not obliged to you. 90% of success depends on you. If you find a problem, then your contribution to Open Source will be its detailed analysis and search for solutions. It is expected that you will actively participate in the discussion of the problem. If you report it and leave, the problem will not be solved.
Ideal: you came, told about the problem and are ready to drive this thread until the very end, until the problem is solved.
Each problem discussed, but not solved in a user list, falls into the devlist, where it is worked out. Here, developers discuss how to properly implement a feature or close a bug.
Devlist is a kind of “place of power” of the project, where you can chat with cool developers who could potentially make a lot of money at trainings, seminars, consultations, writing articles. But these people are busy with what they write the real code, the very code that now moves everything forward on the cutting edge of progress. It seems to me that you simply have no other way to communicate with these people, except on devistya.
In addition, a devlist is a thoughtful correspondence, where you have the opportunity to think an hour or two and only then reply with a letter, unlike messengers, where it is difficult to read the correspondence and understand everything globally. In my understanding, devlist is such a good profile technical journal that can not only be read, but also be directly involved in its creation.
Work in devlist, like any work in Open Source, is public. If you make a contribution to it, it will be loaded by your current / future employer or colleagues. For me personally, when evaluating a candidate for a job, his participation in devlists is more important than his profile on a githaba. A profile on a githaba characterizes only the ability to write code, and the experience on devliste also characterizes the experience of team development. Moreover, such an experience is where individual responsibility is important, not collective. In my opinion, this skill is most important for a good developer, and he develops best when communicating in devlists in Open Source.
We proceed directly to the development.
After agreeing on the improvements on devliste, and the principal design decisions usually agree, the task is ready for implementation. The task is realized most often by the same people who offered and drove it, but not always. One person in reasonable time some features do not overpower - especially if it is a feature in half Ignite.
If you are a good developer and are ready to cut Open Source - come and choose one of the developed tasks, coordinate it with the author and start cutting.
In Open Source, all communications are public. The discussion goes either on devlist or in issue tracker. It is important to try to avoid doing something without discussion, because there is a high probability of doing something wrong. It is considered good practice to clarify all the fundamental points before starting development, so as not to do extra work.
Now about the important.
Development in Open Source is a good and free school. Cool developers, professionals in their field, decompose tasks, allow you to accomplish them, help with any difficulties - and ultimately there is a commit that characterizes you as an excellent developer. As I said, it can be booted, this is part of your portfolio.
If you do not want to realize something for free, think about the fact that this contribution is, roughly speaking, your credit history. It shows that you are doing everything correctly, you can write code and discuss tasks, and it is easy to work with you.
The dangerous moment in the open source development is that absolutely anyone can come to it. I think in every open source project there is a person who has distracted everyone for years, and then leaves without making any contribution.And it is good if it leaves.
Not being such a person is already an important contribution to the Open Source community!
So, you decided to cut something into Open Source. Chances are that the first time you do everything wrong. Over time, you will gain experience that will help you to do everything right - but not in the first times.
In this case, the review will help you.
In most projects (in Apache Ignite exactly), a review occurs before the commit, which allows you to keep the master or development branches clean. And we have a number of fundamental requirements that must be met before the code is given for the review.
CodeStyle.
There is a lot of code in the project, it is written by different people, with different motivation and at different times. If it were written in different ways, it would have been impossible to read. Therefore, code style for us is fundamental. If you are told in a review that an empty line is needed, this is fundamental.
Each feature must undergo regression.
If the project is large, then you never guess how your little finishing touch will affect all the functionality. At the moment we have about 50 thousand tests, each feature is covered by one or more. According to the fallen tests, the regression will help determine that you broke something. For you, this is a good way not to think too much and quickly understand everything - there are breakdowns or not. If we talk about the cost of testing, we have a cluster of ~ one hundred machines that drive regression one by two in two hours.
Changes in significant areas.
If you change something in the "crust" - you have to go through benchmarking. No matter how cool and decisive all problems are, a feature, if it worsens a couple of throughput / latency, then it cannot be merj. The degradation of speed in our product is unacceptable.
API.
There are two points. The new API should not break the compilation of the one who used the old version of the product. And there should be no methods that will be deprecated in a couple of months. You do API - do it right away.
Contributor Viewer is the most important of the most difficult contributions to open source. A reviewer is a person who is ready to help you, in some cases he does up to 90% of the work. The reviewer pushes, explains, almost writes code for you, if necessary. The problem is that when a feature gets into master, it is listed as a contributor, not a reviewer. Appreciate the free work of the reviewer.
If you work in the Open Source community, try to make the work of the reviewer convenient. The basic rules are to make the fix minimal in terms of volume, but as clear as possible. If you see before the review that you can reduce the amount of fixes and increase its clarity, do it.
The current version of Apache Ignite is 2.6. Releases occur about once every 3 months.
Release version 2.7 has been prepared by Sberteha employee Nikolai Izhikov for almost a year as a committer in the project. This is a significant event for the project, because for the first time in its history, the release is not carried out by an employee of Gridgain, the company that created Apache Ignite and transferred it to ASF. This is very good, because we are moving in the direction of the ideal Open Source, when the product is decoupled from a particular commercial company and exists independently. We hope that the experience will be successful, and the following releases will be carried out by employees of other companies, of which we have committers - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, etc.
The popularization of the solution - as is the case with devlist - is a contribution not only to the project, but also to yourself. Such things google and affect hiring decisions. It is also a way for you to briefly postpone the code and do something interesting, but no less useful.
We turn to the main question: why is it worth participating in open source projects?
I will not stop repeating: participation in Open Source is your rapid growth. According to my observations - about a year in three, if not more compared to applied development. This is your chance at an interview to shock your opponent with the phrase "I sawed this thing, I know exactly how it works, and you're wrong!" - I did it twice, the feeling is unforgettable.
Any good programmer should follow the trends. Open Source is the hottest, most promising trend of modern times in software development. Participation in this trend gives a guarantee of respect from your colleagues (right now) and some stability, financial guarantees (in the future).
In many companies, not so little Open Source, as is commonly thought. Many companies are looking for employees fundamentally with experience in Open Source, or for a specific project on full-time. It is important for companies to have an internal project expertise, to be able to influence its development. For example, a company may ask you to finish security in a product or fix a bug that is only in its production. And do it quickly, and not when the community agrees. If you have experience in Open Source or in a specific project, for you it will be a competitive advantage when hiring or continuing to work in your company.
As a proof, there are extremely interesting vacancies ( MSK and SPB ) and Apache Ignite in our team, which saws Open Source at Sberbank-Technologies, and is not the only product that we are developing.
I hope everyone was interested, and many will think about participating in the Open Source movement, and those who have already thought will move on to concrete actions.
Ps For those who like a warm and tube sound, the audio version of “No Cuts” is available.
A text version of the presentation, full of subjective perception of Open Source, both positive and negative, awaits you under the cut.
So, my name is Anton Vinogradov, and for the last 4 years I have been developing the Open Source project Apache Ignite. By his example, I want to talk about how Open Source is being done, what personal benefits you can get from participating in the community, and ultimately, I want to inspire you to participate.
')
Traditional Disclaimer.
Immediately I warn you that my attitude to Open Source is subjective and should not be perceived as the only correct one.
I will talk about Open Source on the example of Apache Ignite - one of the many projects of the Apache Software Foundation. ASF is one of the largest Open Source communities with almost 20 years of history. It owes its success, in the first place, to the processes and principles of motivation laid back in 1999, but still relevant. This “philosophical” side of the community was described in detail in his article by Dmitry Pavlov , we will consider the “applied” side of the development of Open Source using the example of Apache Ignite.
Suppose you decide to contribute to community development. How to do it?
In general, we can not say that Open Source - this is about the code. Many different activities can make a significant contribution, and only some of them are directly related to the code.
- If you find a problem, state it on the user list, where it will work;
- If you are ready - you can participate in the elaboration of tasks on devil list and in the coordination of actions;
- If you are a cool developer - for you it is an opportunity to write a lot of good code;
- Who can revive a cool reviewer;
- If you are a good manager, you can help with the release of the release;
- If you are a good storyteller or just a fan of a project like me, then you can get involved in popularizing the solution.
The most important contribution to Open Source is to inform the community about the problems of the product, its shortcomings. But here it is important to understand that Open Source is not a custom development and the community is not obliged to you. 90% of success depends on you. If you find a problem, then your contribution to Open Source will be its detailed analysis and search for solutions. It is expected that you will actively participate in the discussion of the problem. If you report it and leave, the problem will not be solved.
Ideal: you came, told about the problem and are ready to drive this thread until the very end, until the problem is solved.
Each problem discussed, but not solved in a user list, falls into the devlist, where it is worked out. Here, developers discuss how to properly implement a feature or close a bug.
Devlist is a kind of “place of power” of the project, where you can chat with cool developers who could potentially make a lot of money at trainings, seminars, consultations, writing articles. But these people are busy with what they write the real code, the very code that now moves everything forward on the cutting edge of progress. It seems to me that you simply have no other way to communicate with these people, except on devistya.
In addition, a devlist is a thoughtful correspondence, where you have the opportunity to think an hour or two and only then reply with a letter, unlike messengers, where it is difficult to read the correspondence and understand everything globally. In my understanding, devlist is such a good profile technical journal that can not only be read, but also be directly involved in its creation.
Work in devlist, like any work in Open Source, is public. If you make a contribution to it, it will be loaded by your current / future employer or colleagues. For me personally, when evaluating a candidate for a job, his participation in devlists is more important than his profile on a githaba. A profile on a githaba characterizes only the ability to write code, and the experience on devliste also characterizes the experience of team development. Moreover, such an experience is where individual responsibility is important, not collective. In my opinion, this skill is most important for a good developer, and he develops best when communicating in devlists in Open Source.
We proceed directly to the development.
After agreeing on the improvements on devliste, and the principal design decisions usually agree, the task is ready for implementation. The task is realized most often by the same people who offered and drove it, but not always. One person in reasonable time some features do not overpower - especially if it is a feature in half Ignite.
If you are a good developer and are ready to cut Open Source - come and choose one of the developed tasks, coordinate it with the author and start cutting.
In Open Source, all communications are public. The discussion goes either on devlist or in issue tracker. It is important to try to avoid doing something without discussion, because there is a high probability of doing something wrong. It is considered good practice to clarify all the fundamental points before starting development, so as not to do extra work.
Now about the important.
Development in Open Source is a good and free school. Cool developers, professionals in their field, decompose tasks, allow you to accomplish them, help with any difficulties - and ultimately there is a commit that characterizes you as an excellent developer. As I said, it can be booted, this is part of your portfolio.
If you do not want to realize something for free, think about the fact that this contribution is, roughly speaking, your credit history. It shows that you are doing everything correctly, you can write code and discuss tasks, and it is easy to work with you.
The dangerous moment in the open source development is that absolutely anyone can come to it. I think in every open source project there is a person who has distracted everyone for years, and then leaves without making any contribution.
Not being such a person is already an important contribution to the Open Source community!
So, you decided to cut something into Open Source. Chances are that the first time you do everything wrong. Over time, you will gain experience that will help you to do everything right - but not in the first times.
In this case, the review will help you.
In most projects (in Apache Ignite exactly), a review occurs before the commit, which allows you to keep the master or development branches clean. And we have a number of fundamental requirements that must be met before the code is given for the review.
CodeStyle.
There is a lot of code in the project, it is written by different people, with different motivation and at different times. If it were written in different ways, it would have been impossible to read. Therefore, code style for us is fundamental. If you are told in a review that an empty line is needed, this is fundamental.
Each feature must undergo regression.
If the project is large, then you never guess how your little finishing touch will affect all the functionality. At the moment we have about 50 thousand tests, each feature is covered by one or more. According to the fallen tests, the regression will help determine that you broke something. For you, this is a good way not to think too much and quickly understand everything - there are breakdowns or not. If we talk about the cost of testing, we have a cluster of ~ one hundred machines that drive regression one by two in two hours.
Changes in significant areas.
If you change something in the "crust" - you have to go through benchmarking. No matter how cool and decisive all problems are, a feature, if it worsens a couple of throughput / latency, then it cannot be merj. The degradation of speed in our product is unacceptable.
API.
There are two points. The new API should not break the compilation of the one who used the old version of the product. And there should be no methods that will be deprecated in a couple of months. You do API - do it right away.
Contributor Viewer is the most important of the most difficult contributions to open source. A reviewer is a person who is ready to help you, in some cases he does up to 90% of the work. The reviewer pushes, explains, almost writes code for you, if necessary. The problem is that when a feature gets into master, it is listed as a contributor, not a reviewer. Appreciate the free work of the reviewer.
If you work in the Open Source community, try to make the work of the reviewer convenient. The basic rules are to make the fix minimal in terms of volume, but as clear as possible. If you see before the review that you can reduce the amount of fixes and increase its clarity, do it.
The current version of Apache Ignite is 2.6. Releases occur about once every 3 months.
Release version 2.7 has been prepared by Sberteha employee Nikolai Izhikov for almost a year as a committer in the project. This is a significant event for the project, because for the first time in its history, the release is not carried out by an employee of Gridgain, the company that created Apache Ignite and transferred it to ASF. This is very good, because we are moving in the direction of the ideal Open Source, when the product is decoupled from a particular commercial company and exists independently. We hope that the experience will be successful, and the following releases will be carried out by employees of other companies, of which we have committers - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, etc.
The popularization of the solution - as is the case with devlist - is a contribution not only to the project, but also to yourself. Such things google and affect hiring decisions. It is also a way for you to briefly postpone the code and do something interesting, but no less useful.
We turn to the main question: why is it worth participating in open source projects?
I will not stop repeating: participation in Open Source is your rapid growth. According to my observations - about a year in three, if not more compared to applied development. This is your chance at an interview to shock your opponent with the phrase "I sawed this thing, I know exactly how it works, and you're wrong!" - I did it twice, the feeling is unforgettable.
Any good programmer should follow the trends. Open Source is the hottest, most promising trend of modern times in software development. Participation in this trend gives a guarantee of respect from your colleagues (right now) and some stability, financial guarantees (in the future).
In many companies, not so little Open Source, as is commonly thought. Many companies are looking for employees fundamentally with experience in Open Source, or for a specific project on full-time. It is important for companies to have an internal project expertise, to be able to influence its development. For example, a company may ask you to finish security in a product or fix a bug that is only in its production. And do it quickly, and not when the community agrees. If you have experience in Open Source or in a specific project, for you it will be a competitive advantage when hiring or continuing to work in your company.
As a proof, there are extremely interesting vacancies ( MSK and SPB ) and Apache Ignite in our team, which saws Open Source at Sberbank-Technologies, and is not the only product that we are developing.
I hope everyone was interested, and many will think about participating in the Open Source movement, and those who have already thought will move on to concrete actions.
Ps For those who like a warm and tube sound, the audio version of “No Cuts” is available.
Source: https://habr.com/ru/post/425043/
All Articles