Daniil Dubrovkin: “Because they don’t write open source, they didn’t become bad engineers”
Introducing the sixth issue of a podcast about technology, processes, infrastructure, and people in IT companies. Today, CTOcast is visiting - Daniel Doubrovkine, Technical Director of Artsy and an open source enthusiast.
Listen to the podcast
1st part of the text version of the podcast
')
Pavel Pavlov: What is the secret of success in creating an open source project? What should be done? What could be the problem?
Daniil Dubrovkin: The indispensable things for creating an open source project are good documentation and systems that help new developers work in a project. For example, when we write a library, we need tests in it. And then a person who adds something to this library can make sure that he did not break anything. The library needs a good changelog so that everyone knows about the changes in the latest version, and that users see that there is a group of people who are following these changes.
Work on any open project is the management of a large group of people who are independent of each other, and they all need to be helped by the infrastructure.
Difficulties arise when you find abandoned projects, or projects that you use are abandoned. For example, I worked on one good project, and the engineer who wrote it and with whom we never met in life, suddenly disappeared. Time passed, and no one knew what happened to him. A few years later I accidentally found it and it turned out that he completely abandoned programming and began planting grapes in the north of Italy. He decided that he would never be connected to a computer again, and the project was going pretty fast: there were a lot of people writing code and thousands of users. The company I worked for at the time also used it, so someone had to start doing organizational work, which was what the missing engineer had done before.
I have to talk a lot about how to continue other people's projects, so I can say for sure that it is very important when organizing a project to organize the process so that the work does not stop if someone else is missing.
Pavel Pavlov: If not a secret, what was this project?
Daniil Dubrovkin: Of course, the project dotNetInstaller — bootstrapper for Windows installation. It is so old that it still works on Windows 95. The project has many users and it is alive. I do not write anything in it, but there are people who continue to deal with it.
Pavel Pavlov: The situation is actually quite typical. People’s priorities change, different life situations and career paths. When you start a project, there is a high probability that in two or three years a lot will change and you will not be able to support it. Is it always worth building a project thinking that after a certain time you will transfer it? Or is it worth trying to motivate yourself and support the project, no matter what?
Daniil Dubrovkin: Morally, I have to keep up with what I have begun, and I cannot leave the project until someone else takes it. I can not criticize people who think the opposite: they put the code on the Internet and no longer want to deal with them. The main thing is for people to express this directly. For example, I see a lot of projects, when someone says: “You know, I don’t think that this is a very good project, but I still throw it on the Internet. Do what you want with him. ” Not perfect, but it suits me. I can not criticize people who have their own priorities change and who, perhaps, want to grow grapes.
Pavel Pavlov: Are companies that post open source projects bear moral responsibility? Business may close, but the project will remain.
Daniil Dubrovkin: Yes, most likely the business will close, but the project will remain. Most companies do not work, especially startups that disappear faster than we think. It seems to me that companies here have no moral obligations. If a company lays out projects on its own behalf, then it must pay its own engineers to continue working with these projects.
Today in my company (Ed. — Artsy) we rarely want engineers to lay out projects on behalf of Artsy. Our engineers mostly work on open source projects from themselves. Nobody forces them to have the projects necessarily from Artsy. On the contrary, I want the engineers themselves to develop open source projects, without a company that tells them what to do and how. At the same time, we spend a lot of money so that they work on their open source projects, trust them over time and with what they do. We believe that all their work will in some way benefit the company. And here it turns out a lot of interesting things.
For example, our engineer, head of a mobile company and known on the Internet as Orta, is one of the main developers of CocoaPods, which is used by almost all developers writing programs on iOS. And he spends a lot of time on CocoaPods, but if I look at every line of his code and say, “These are CocoaPods, this is not for Artsy,” then I’ll probably be wrong. Due to his activity, I have no problems with hiring engineers who write our iOS programs.
Alexander Astapenko: It turns out that engineers do the work of HR.
Daniil Dubrovkin: Yes, and much better than HR. I am always interested in the overall result of our group. When one person works on open projects, other developers see and learn this, which is very good for the whole team. In addition, as already mentioned, it becomes easy to find new engineers.
Alexander Astapenko: If representatives of the company who decided to give their product to open source came to you for advice, how would you recommend them to build this process? Not just throw on github?
Daniil Dubrovkin: This is a cultural issue for the company. Why do they need it? If they think that this is better and there are advantages, for example, it is easier to hire people, then they are in the right stream. I would start very simply with the translation of the development in an open format: open the repository and start working for everyone to see. It's the most important. Then you need to work a little on organizing this project for others. Not only for engineers who can turn the chair and ask a question, but for those who are at the other end of the earth and want to do something about it. Recently, our mobile team opened the Artsy iOS app, in 2013, Apple made a feature for it. A beautiful and cool written program that is now fully open source on GitHub. And for the first three days we had 10−15 requests for documentation only: how to do it, how to do it. This is how cooperation with people who do not work for you begins.
Alexander Astapenko: It may sound strange by the standards of the modern world, but still I will ask. Imagine that there is an experienced developer who has never worked on open source projects. How would you convince him to connect to this area? What benefits does a person, not a company, get to participate in open source projects?
Daniil Dubrovkin: I do not agree that there are no strong developers who would not write to open source. I see them every day. There are so many good developers who have never done this. Because they do not write open source, they did not become bad engineers.
I think that for an individual person there are several advantages. First, you learn to work in a completely different way, and this is interesting. Maybe you are a strong engineer, but how do you interact with people, especially whom you do not know? If you now work in a small company, then this may be the next step in the development of an engineer who can do something more than just write code.
Second, the engineer most likely will not work until the end of his life in one company. This is reality and this is normal. Laying out his projects in open source, the developer makes a name for himself and the next time he goes to an interview, employers will already look at his code, and not listen to how he was a good engineer in a company that they have never heard of . A proper name is something that every person wants to at least think about. And due to the fact that everyone begins to think about themselves, the company only gets better. This is a more modern form of development today.
My friend Alice Marwick (Alice E. Marwick) wrote the book Status Update, and she says that strong engineers are the highest level in technology companies. True, if no one knows about this, then the engineers will not be better off. We often forget that indoors, no matter how good an engineer you are, you cannot prove it without the programs themselves, without the code. I think that open source is better for a person, for a company, and for the code itself. We need to write good code, because we all show it, we need more tests, we need to make it look cleaner and more beautiful. And the company itself receives advanced software, which is written by its engineers. Products are becoming easier.
Pavel Pavlov: So far we get that open source is a rainbow story. Unfortunately, this is not always the case. Here, for example, is the Linux community, where there are many conflicts between people who support the project, with key figures and leaders. In the case of Red Hat and MongoDB, everything is different: they have their own goals and they need to be achieved, there is money for the project. Imagine that there is an enthusiast and he wants to fix a bug, and the people who support the project do not want to accept it, they are not satisfied with the quality of the code. The man had good intentions, and he wanted to improve the project, but he was immediately repelled. How to avoid such situations? How to allow new people to enter the project and help increase the community?
Daniil Dubrovkin: I agree 100 percent. This happens very often: people try to help, and they are cut off rather dryly. And they no longer want to do this, they are hard and unpleasant. In such situations, blame the people who support the projects. They believe that they rule the state and do what they want. This is not just an open source issue. In closed companies, this is also very common. There are engineers who work on the principle of "this is mine and do not even come close."
We all have to learn from Matz, who wrote Ruby: "Matz is nice." We need to take people and help them. Not to think that they did something bad, and not to blame, but to comment only on the code itself or on what they did wrong.
On the other hand, a newbie in open source needs to understand that if people who support the project consider the code bad, then these are not personal attacks. They do not say that you are a bad person, but simply comment on incorrectly written or not working.
This is work for both parties: for those who are trying to make their contribution, and for those who accept this contribution.
Alexander Astapenko: How do you see the future of open source?
Daniil Dubrovkin: I believe that all the code that we will write in 10 years will be open source. There is no reason for the software to be closed. Recently, I support the movement of Open Source by Default: we are creating a company and from the very beginning we say that our software will be open. And if we have something proprietary, some kind of special algorithm, then we can hold it for a while so that competitors don’t find out. But in the end, when everything starts to work in public, when everything is completed, you can open it.
Alexander Astapenko: Do I understand correctly that under your leadership in Artsy there is not a single proprietary product left?
Daniil Dubrovkin: Wrong. We have a lot of proprietary products.
Alexander Astapenko: Why?
Daniil Dubrovkin: I do not dictate to my team what to do or how to work them. We began to open our code gradually, after we started writing it. Initially, I did not make the decision that everything should be open. I think that next time, if I start a new company, this decision will work from day one.
Artsy has very little code that needs to be closed. People often ask me: “What about your super-algorithms that make one art look like another?” And I’m happy to explain to everyone how it works, because the data that our historians make are very important, and the algorithms themselves are pretty . And if you saw all the code, you would not find anything stunning there. So now we are working more and more openly. Our iOS application is now open source and this is quite a big deal. There is already one program written in the open from scratch — bidding kiosk for Artsy auctions, done in Swift. I would say that 99 percent of our new open source projects from the very beginning, but until the old hands just have not reached.
Alexander Astapenko: You work in a company and support open source projects. How does this fit in time? And what happens when one of your projects becomes very popular. For example, Grape.
Daniil Dubrovkin: Grape, who, by the way, did not start me, benefits the company directly. We have all API written with Grape.
I have several well-known projects, for example, Waffle (authentication in Windows). Now another person supports him, but sometimes I put my hands in there and do something. I try to limit my time on projects that companies do not directly bring any benefits, and usually take half a day a week to get involved in open source projects, answer letters, attract new people. My advice is to share your time. Work on open source projects that do not interest me now should also be limited.
Alexander Astapenko: What are you doing at Artsy and what are your main responsibilities there?
Daniil Dubrovkin: Artsy — a phenomenal company where I have been working for four years, almost since its foundation. This is a very interesting project, the purpose of which is to make art as popular as music, to transfer it to the Internet. Artsy is based on the Art Genome research project, for which a large group of our historians classify art, especially contemporary art.
What am I doing now? There are almost 90 people in Artsy, an engineering team — about 20. I still continue to write code, but lately I have been working more as a “historian”: looking at very old things and trying to tell engineers about them, about how we will these things get rid of. I spend a lot of time hiring new developers, find contacts, try to help engineers connect with the right people. For example, we worked on the Ezel project — such isomorphic JavaScript on the server and on the client, and our engineers contacted Airbnb developers who had gone a long way in this business. We worked together to finish everything, and I had to simplify their contacts. I mainly work with people, and in the remaining free time I write a lot of open source code. I am trying to understand where our technology is going, and how we can use it to help clients and partners.
Alexander Astapenko: Is there anything else that you would like to say at the end of the podcast?
Daniel Dubrovkin: I would like to appeal to those who listen to this podcast. There are a lot of talented and good engineers in Russia, but only a few of them are involved in open source. If I can help someone to be part of an open world without borders, then I will do it with pleasure.
Listen to the podcast
1st part of the text version of the podcast
')
Text version of the podcast (2nd part)
Ethics of open source and the secrets of successful projects
Pavel Pavlov: What is the secret of success in creating an open source project? What should be done? What could be the problem?
Daniil Dubrovkin: The indispensable things for creating an open source project are good documentation and systems that help new developers work in a project. For example, when we write a library, we need tests in it. And then a person who adds something to this library can make sure that he did not break anything. The library needs a good changelog so that everyone knows about the changes in the latest version, and that users see that there is a group of people who are following these changes.
Work on any open project is the management of a large group of people who are independent of each other, and they all need to be helped by the infrastructure.
Difficulties arise when you find abandoned projects, or projects that you use are abandoned. For example, I worked on one good project, and the engineer who wrote it and with whom we never met in life, suddenly disappeared. Time passed, and no one knew what happened to him. A few years later I accidentally found it and it turned out that he completely abandoned programming and began planting grapes in the north of Italy. He decided that he would never be connected to a computer again, and the project was going pretty fast: there were a lot of people writing code and thousands of users. The company I worked for at the time also used it, so someone had to start doing organizational work, which was what the missing engineer had done before.
I have to talk a lot about how to continue other people's projects, so I can say for sure that it is very important when organizing a project to organize the process so that the work does not stop if someone else is missing.
Pavel Pavlov: If not a secret, what was this project?
Daniil Dubrovkin: Of course, the project dotNetInstaller — bootstrapper for Windows installation. It is so old that it still works on Windows 95. The project has many users and it is alive. I do not write anything in it, but there are people who continue to deal with it.
Pavel Pavlov: The situation is actually quite typical. People’s priorities change, different life situations and career paths. When you start a project, there is a high probability that in two or three years a lot will change and you will not be able to support it. Is it always worth building a project thinking that after a certain time you will transfer it? Or is it worth trying to motivate yourself and support the project, no matter what?
Daniil Dubrovkin: Morally, I have to keep up with what I have begun, and I cannot leave the project until someone else takes it. I can not criticize people who think the opposite: they put the code on the Internet and no longer want to deal with them. The main thing is for people to express this directly. For example, I see a lot of projects, when someone says: “You know, I don’t think that this is a very good project, but I still throw it on the Internet. Do what you want with him. ” Not perfect, but it suits me. I can not criticize people who have their own priorities change and who, perhaps, want to grow grapes.
Pavel Pavlov: Are companies that post open source projects bear moral responsibility? Business may close, but the project will remain.
Daniil Dubrovkin: Yes, most likely the business will close, but the project will remain. Most companies do not work, especially startups that disappear faster than we think. It seems to me that companies here have no moral obligations. If a company lays out projects on its own behalf, then it must pay its own engineers to continue working with these projects.
Today in my company (Ed. — Artsy) we rarely want engineers to lay out projects on behalf of Artsy. Our engineers mostly work on open source projects from themselves. Nobody forces them to have the projects necessarily from Artsy. On the contrary, I want the engineers themselves to develop open source projects, without a company that tells them what to do and how. At the same time, we spend a lot of money so that they work on their open source projects, trust them over time and with what they do. We believe that all their work will in some way benefit the company. And here it turns out a lot of interesting things.
For example, our engineer, head of a mobile company and known on the Internet as Orta, is one of the main developers of CocoaPods, which is used by almost all developers writing programs on iOS. And he spends a lot of time on CocoaPods, but if I look at every line of his code and say, “These are CocoaPods, this is not for Artsy,” then I’ll probably be wrong. Due to his activity, I have no problems with hiring engineers who write our iOS programs.
Alexander Astapenko: It turns out that engineers do the work of HR.
Daniil Dubrovkin: Yes, and much better than HR. I am always interested in the overall result of our group. When one person works on open projects, other developers see and learn this, which is very good for the whole team. In addition, as already mentioned, it becomes easy to find new engineers.
Alexander Astapenko: If representatives of the company who decided to give their product to open source came to you for advice, how would you recommend them to build this process? Not just throw on github?
Daniil Dubrovkin: This is a cultural issue for the company. Why do they need it? If they think that this is better and there are advantages, for example, it is easier to hire people, then they are in the right stream. I would start very simply with the translation of the development in an open format: open the repository and start working for everyone to see. It's the most important. Then you need to work a little on organizing this project for others. Not only for engineers who can turn the chair and ask a question, but for those who are at the other end of the earth and want to do something about it. Recently, our mobile team opened the Artsy iOS app, in 2013, Apple made a feature for it. A beautiful and cool written program that is now fully open source on GitHub. And for the first three days we had 10−15 requests for documentation only: how to do it, how to do it. This is how cooperation with people who do not work for you begins.
On the benefits, conflicts and future open source
Alexander Astapenko: It may sound strange by the standards of the modern world, but still I will ask. Imagine that there is an experienced developer who has never worked on open source projects. How would you convince him to connect to this area? What benefits does a person, not a company, get to participate in open source projects?
Daniil Dubrovkin: I do not agree that there are no strong developers who would not write to open source. I see them every day. There are so many good developers who have never done this. Because they do not write open source, they did not become bad engineers.
I think that for an individual person there are several advantages. First, you learn to work in a completely different way, and this is interesting. Maybe you are a strong engineer, but how do you interact with people, especially whom you do not know? If you now work in a small company, then this may be the next step in the development of an engineer who can do something more than just write code.
Second, the engineer most likely will not work until the end of his life in one company. This is reality and this is normal. Laying out his projects in open source, the developer makes a name for himself and the next time he goes to an interview, employers will already look at his code, and not listen to how he was a good engineer in a company that they have never heard of . A proper name is something that every person wants to at least think about. And due to the fact that everyone begins to think about themselves, the company only gets better. This is a more modern form of development today.
My friend Alice Marwick (Alice E. Marwick) wrote the book Status Update, and she says that strong engineers are the highest level in technology companies. True, if no one knows about this, then the engineers will not be better off. We often forget that indoors, no matter how good an engineer you are, you cannot prove it without the programs themselves, without the code. I think that open source is better for a person, for a company, and for the code itself. We need to write good code, because we all show it, we need more tests, we need to make it look cleaner and more beautiful. And the company itself receives advanced software, which is written by its engineers. Products are becoming easier.
Pavel Pavlov: So far we get that open source is a rainbow story. Unfortunately, this is not always the case. Here, for example, is the Linux community, where there are many conflicts between people who support the project, with key figures and leaders. In the case of Red Hat and MongoDB, everything is different: they have their own goals and they need to be achieved, there is money for the project. Imagine that there is an enthusiast and he wants to fix a bug, and the people who support the project do not want to accept it, they are not satisfied with the quality of the code. The man had good intentions, and he wanted to improve the project, but he was immediately repelled. How to avoid such situations? How to allow new people to enter the project and help increase the community?
Daniil Dubrovkin: I agree 100 percent. This happens very often: people try to help, and they are cut off rather dryly. And they no longer want to do this, they are hard and unpleasant. In such situations, blame the people who support the projects. They believe that they rule the state and do what they want. This is not just an open source issue. In closed companies, this is also very common. There are engineers who work on the principle of "this is mine and do not even come close."
We all have to learn from Matz, who wrote Ruby: "Matz is nice." We need to take people and help them. Not to think that they did something bad, and not to blame, but to comment only on the code itself or on what they did wrong.
On the other hand, a newbie in open source needs to understand that if people who support the project consider the code bad, then these are not personal attacks. They do not say that you are a bad person, but simply comment on incorrectly written or not working.
This is work for both parties: for those who are trying to make their contribution, and for those who accept this contribution.
Alexander Astapenko: How do you see the future of open source?
Daniil Dubrovkin: I believe that all the code that we will write in 10 years will be open source. There is no reason for the software to be closed. Recently, I support the movement of Open Source by Default: we are creating a company and from the very beginning we say that our software will be open. And if we have something proprietary, some kind of special algorithm, then we can hold it for a while so that competitors don’t find out. But in the end, when everything starts to work in public, when everything is completed, you can open it.
Alexander Astapenko: Do I understand correctly that under your leadership in Artsy there is not a single proprietary product left?
Daniil Dubrovkin: Wrong. We have a lot of proprietary products.
Alexander Astapenko: Why?
Daniil Dubrovkin: I do not dictate to my team what to do or how to work them. We began to open our code gradually, after we started writing it. Initially, I did not make the decision that everything should be open. I think that next time, if I start a new company, this decision will work from day one.
Artsy has very little code that needs to be closed. People often ask me: “What about your super-algorithms that make one art look like another?” And I’m happy to explain to everyone how it works, because the data that our historians make are very important, and the algorithms themselves are pretty . And if you saw all the code, you would not find anything stunning there. So now we are working more and more openly. Our iOS application is now open source and this is quite a big deal. There is already one program written in the open from scratch — bidding kiosk for Artsy auctions, done in Swift. I would say that 99 percent of our new open source projects from the very beginning, but until the old hands just have not reached.
Alexander Astapenko: You work in a company and support open source projects. How does this fit in time? And what happens when one of your projects becomes very popular. For example, Grape.
Daniil Dubrovkin: Grape, who, by the way, did not start me, benefits the company directly. We have all API written with Grape.
I have several well-known projects, for example, Waffle (authentication in Windows). Now another person supports him, but sometimes I put my hands in there and do something. I try to limit my time on projects that companies do not directly bring any benefits, and usually take half a day a week to get involved in open source projects, answer letters, attract new people. My advice is to share your time. Work on open source projects that do not interest me now should also be limited.
About the Artsy project
Alexander Astapenko: What are you doing at Artsy and what are your main responsibilities there?
Daniil Dubrovkin: Artsy — a phenomenal company where I have been working for four years, almost since its foundation. This is a very interesting project, the purpose of which is to make art as popular as music, to transfer it to the Internet. Artsy is based on the Art Genome research project, for which a large group of our historians classify art, especially contemporary art.
What am I doing now? There are almost 90 people in Artsy, an engineering team — about 20. I still continue to write code, but lately I have been working more as a “historian”: looking at very old things and trying to tell engineers about them, about how we will these things get rid of. I spend a lot of time hiring new developers, find contacts, try to help engineers connect with the right people. For example, we worked on the Ezel project — such isomorphic JavaScript on the server and on the client, and our engineers contacted Airbnb developers who had gone a long way in this business. We worked together to finish everything, and I had to simplify their contacts. I mainly work with people, and in the remaining free time I write a lot of open source code. I am trying to understand where our technology is going, and how we can use it to help clients and partners.
Alexander Astapenko: Is there anything else that you would like to say at the end of the podcast?
Daniel Dubrovkin: I would like to appeal to those who listen to this podcast. There are a lot of talented and good engineers in Russia, but only a few of them are involved in open source. If I can help someone to be part of an open world without borders, then I will do it with pleasure.
Source: https://habr.com/ru/post/255585/
All Articles