Daniil Dubrovkin: “Because they do not write open source, they did not become bad engineers”

    Introducing the sixth edition of the podcast on technology, processes, infrastructure, and people in IT companies. Today, visiting CTOcast is Daniel Doubrovkine, CTO of Artsy and an open source enthusiast.

    Listen to the podcast

    1st part of the text version of the podcast


    Text version of the podcast (Part 2)


    Open source ethics and the secrets of successful projects



    Pavel Pavlov: What is the secret to success when creating an open source project? What should be done? What could be the problem?

    Daniil Dubrovkin: Indispensable things for creating an open source project — good documentation and systems that help new developers to work in the project. For example, when we write a library, we need to have tests in it. And then the person who adds something to this library can make sure that he did not break anything. A good changelog is needed in the library so that everyone knows about the changes in the latest version, and so 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 help with infrastructure.

    Difficulties arise when you find abandoned projects, or projects that you use are abandoned. For example, I was working on one good project, and the engineer who wrote it and whom we never met in my 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 quit programming and began to plant grapes in northern Italy. He decided that he would never be connected to a computer again, and the project went quite quickly: there were many people writing code, and thousands of users. The company in which I worked then also used it, so someone had to start organizing, as 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 creating 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 kind of project was this?

    Daniil Dubrovkin: Of course, the dotNetInstaller — bootstrapper project for Windows installation. It is so old that it still runs on Windows 95. The project has many users and is alive. I don’t write anything in it, but there are people who continue to do it.

    Pavel Pavlov:The situation is actually quite typical. People’s priorities are changing, different life situations and career paths. When you start a project, there is a high probability that a lot will change in two or three years, and you will not be able to support it. Is it always worth building a project thinking that after a certain time you will pass it on? Or is it worth trying to motivate yourself and support the project, no matter what?

    Daniil Dubrovkin:Morally, I have to support what I always started, and I can’t leave the project until someone else takes it. I can’t criticize people who think the opposite: they have posted the code on the Internet and no longer want to do it. The main thing is that people speak directly about this. 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 throw it on the Internet anyway. Do whatever you want with him. ” Not perfect, but it suits me. I can’t criticize people whose own priorities are changing and who, perhaps, want to grow grapes.

    Pavel Pavlov: Do companies that post open source projects bear moral responsibility? The 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 here companies have no moral obligations. If a company uploads projects on its own behalf, then it must pay its own engineers to continue working with these projects.

    Today at my company (approx. Ed. — Artsy), we rarely want engineers to upload projects on behalf of Artsy. Basically, our engineers work on open source projects on their own. Nobody forces them to have projects necessarily from Artsy. On the contrary, I want the engineers to develop open source projects themselves, without a company that tells them what to do and how. At the same time, we spend a lot of money for them to work on their open source projects, trust them over time and with what they do. We believe that all their work will to some extent bring benefits to the company. And here it turns out a lot of interesting things.

    For example, our engineer, the 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 each of his lines of code and say, “This is CocoaPods, this is not for Artsy,” I’ll probably be wrong. Thanks to his activity, I have no problem hiring engineers who write our iOS programs.

    Alexander Astapenko: It turns out that the 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 source 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 a company that 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 believe 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 — by translating the development into an open format: open the repository and start working so that everyone can see. It's the most important. Then we need to work a little on the organization of this project for others. Not only for engineers who can turn a chair and ask a question, but for those who are on the other side of the earth and want to do something about it. Recently, our mobile team opened the Artsy iOS application, in 2013 Apple did 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 only for documentation: how to do this, how to do that.

    About the benefits, conflicts and future of open source



    Alexander Astapenko: It may sound strange by the standards of the modern world, but still I’ll ask. Imagine that there is an experienced developer who has never worked on open source projects. How would you convince him to join this sphere? What benefits does a person, not a company, have 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. Firstly, you learn to work in a completely different way, and this is interesting. You may be a strong engineer, but how do you interact with people, especially whom you don’t 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 more than just write code.

    The second, the engineer, most likely, will not work until the end of his life in one company. This is reality and it is normal. By laying out his projects in open source, the developer makes a name for himself and the next time he goes for an interview, employers will already look at his code, and not listen about how good he was as an 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 is only getting better. This is a more modern form of development today.

    My friend Alice E. Marwick wrote the Status Update book, 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 get better. We often forget that indoors, no matter how good a engineer you are, you will not be able to prove it without the programs themselves, without the code. I think that open source is better for the person, and for the company, and for the code itself. We need to write good code, because we show it to everyone, we need more tests, it needs to be cleaner and more beautiful. And the company itself receives advanced software that its engineers write. Products are getting easier.

    Pavel Pavlov:So far, it turns out 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 behind the project. Imagine that there is an enthusiast and he wants to fix the bug, and the people who support the project do not want to accept it, they are not happy 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 let new people enter the project and help grow the community?

    Daniil Dubrovkin:100 percent agree. This happens very often: people try to help, and they are cut off rather dryly. And they no longer want to do this, it’s hard and unpleasant. In such situations, people who support projects are to blame. They believe that they rule the state and do what they want. This is not only an open source problem. In closed companies, this is also very common. There are engineers who work on the principle "this is mine and don’t even come close."

    We all need to learn from Matz, who wrote Ruby: "Matz is nice and so we are nice." Need to accept people and help them. Not to think that they did something badly, and not to blame, but to comment only on the code itself or what they did wrong.

    On the other hand, a newcomer to open source needs to understand that if people who support the project consider the code to be bad, then these are not personal attacks. They do not say that you are a bad person, but simply comment on incorrectly written or inactive.

    This is a job for both parties: for those who are trying to make a 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 become open source. There is no reason for the software to be shut down. Recently, I support the Open Source by Default movement: 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 do not recognize it. But, in the end, when everything starts to work publicly, when everything is completed, then you can open it.

    Alexander Astapenko: Do I understand correctly that under your leadership in Artsy not a single proprietary product remains?

    Daniil Dubrovkin: Wrong. We have many proprietary products.

    Alexander Astapenko: Why?

    Daniil Dubrovkin: I do not dictate to my team what to do and how to work with them. We began to open our code gradually, after we began to write it. Initially, I did not decide that everything should be open. I think that next time, if I start a new company, this solution will work from the first day.

    Artsy has very little code to keep private. People often ask me: “What about your super-algorithms that make one fine art look like another?” And I am happy to explain to everyone how it works, because the most important thing is the data that our historians make, and the algorithms themselves are quite simple . And if you saw the whole code, then you would not find anything stunning there. Therefore, now we are working more and more openly. Our iOS application is now open source and this is a pretty big deal. Already there is one program written openly from scratch — bidding kiosk for Artsy auctions, made on Swift. I would say that 99 percent of our new open source projects are from the very beginning, but the old ones simply haven’t reached our hands.

    Alexander Astapenko:You work in a company and support open source projects. How does it fit in time? And what happens when one of your projects becomes very popular. For example, Grape.

    Daniil Dubrovkin: Grape, which, incidentally, was not started by me, directly benefits the company. We have all the APIs written with Grape.

    I have several well-known projects, for example, Waffle (authentication in Windows). Now he is supported by another person, 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 do open source projects, reply to letters, attract new people. My advice is to share your time. Work on open source projects that do not interest me right now should also be limited.

    About Artsy



    Alexander Astapenko: What do you do at Artsy and what are your main responsibilities there?

    Daniil Dubrovkin: Artsy is a phenomenal company, where I have been working for four years, almost from its very foundation. This is a very interesting project, the purpose of which is to make fine 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 fine art, especially contemporary.

    What am I doing now? There are almost 90 people at Artsy, the engineering team is about 20. I still continue to write code, but lately I work more as a “historian”: I look at very old things and try to tell engineers about them, about how we will get rid of these things. I spend a lot of time hiring new developers, find contacts, try to help engineers get in touch 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 went a long way in this business. We worked together to finish everything to the end, and I had to simplify their contacts. I mainly deal with people, and in the remaining free time I write a lot of open source code. I’m trying to understand where our technology is going, and how we can use it,

    Alexander Astapenko: Is there anything else you would like to say about completing the podcast?

    Daniil 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 engaged in open source. If I can help someone to be part of an open world without borders, then I will do it with pleasure.

    Also popular now: