How to create an open source project

Already this week in St. Petersburg will host the TechTrain IT-festival. One of the speakers will be Richard Stallman. Embox also participates in the festival, and of course we could not ignore the topic of open source software. Therefore, one of our reports is called “From student crafts to the opensource project. Embox Experience . ” It will be dedicated to the history of Embox as an open source project. In this article I want to talk about the main ideas that in my opinion affect the development of opensource projects. The article, like the report, is based on personal experience.



Let's start with a simple definition of the term opensource. Obviously, an open source project is a project that has one of the licenses that allows you to access the source code of the project. In addition, an open project implies the possibility of changes by third-party developers. That is, if some company or developer publishes the code of their product, partially or completely, then this does not make this product an open source project. And finally, any project activity should lead to the appearance of some kind of result, and openness of the project implies that not only the developers themselves use this result.



We will not touch the problems of open licenses. This is too big and complicated a topic that requires deep investigation. A lot of good articles and materials have been written on this topic. But since I myself am not a specialist in the field of copyright, I can only say that the license should meet the objectives of the project. For example, for Embox, the choice of a BSD rather than a GPL license was not random.



The fact that an open project should make it possible to make changes and influence the development of an open project implies that the project is distributed. Managing it, maintaining integrity and efficiency is much more difficult compared to a project with centralized management. A reasonable question arises: why do open source projects at all? The answer lies in the field of commercial feasibility; for a certain class of projects, the benefits of this approach outweigh the costs. That is, not for all projects, an open approach is generally acceptable. For example, it is difficult to imagine the development of a power plant or aircraft control system based on an open principle. No, of course, it is worth including modules based on open projects in the composition of such systems, because this will provide a number of advantages. But someone must answer for the final product. Even if the system is completely based on open source code, the developer, packing everything into one system and making specific assemblies and settings, essentially closes it. The code may be publicly available.



For these systems, there are also a bunch of benefits from creating open source projects or participating in them. As I said, the code of the final system may remain in the public domain. Why, because it is obvious that it is unlikely that anyone will have the same plane to test the system. This is true, but there may well be someone who wants to check individual sections of the code, or for example, someone may find that the library used is not quite correctly configured.



An even greater benefit appears if the company allocates some basic part of the system into a separate project. For example, a library to support some kind of data exchange protocol. In this case, even if the protocol is specific to a given subject area, it is possible to share the costs of maintaining this piece of the system with other companies from this area. In addition, specialists who can study this piece of the system in the public domain need much less time to use it effectively. And finally, separating a piece into an independent entity, which is used by third-party developers, allows you to make this part better, because you need to offer effective APIs, make documentation, I’m not even talking about improving test coverage.



A company can obtain commercial benefits without creating open projects, it is enough for its specialists to participate in third-party projects used by the company. After all, all the benefits remain: the employees know the project better, therefore they use it more efficiently, the company can influence the direction of the project development, well, using ready-made debugged code obviously reduces the company's costs.



The benefits of creating opensource projects do not end there. Take such an important component of the business as marketing. For him, this is a very good sandbox, which allows you to effectively assess the requirements of the market.



And of course, you should not forget that the opensource project is an effective way to declare yourself as the carrier of any specialization. In some cases, this is generally the only way to enter the market. For example, Embox began as a project to create an RTOS. Probably no need to explain that there are a bunch of competitors. Without creating a community, we simply would not have enough resources to bring the project to the end user, that is, for third-party developers to use the project.



The community is key in the opensource project. It allows you to significantly reduce project management costs, develops and supports the project. We can say that without a community there is no opensource project at all.



A lot of materials have been written on how to create and manage an open source project community. In order not to retell already known facts, I will try to focus on the experience of Embox. For example, a very interesting issue is the process of creating a community. That is, many tell how to manage the existing community, but the moments of its creation are sometimes overlooked, considering it a given.



The main rule when creating the community opensource project - there are no rules. I mean, there are no universal rules, just like a silver bullet, if only because the projects are very different. It is hardly possible to use the same rules when creating a community for a js logging library and some highly specialized driver. Moreover, at different stages of the development of the project (and therefore the community), the rules change.



Embox began as a student project, as there was access to students in the Department of System Programming. In fact, we went into some other community. Participants of this community, students, we could be interested in good industrial practice in their specialty, scientific works in the field of system programming, term papers and diplomas. That is, we complied with one of the basic rules of community organization, community members must get something, and this price should correspond to the contribution of the participant.



The next stage for Embox was the search for third-party users. It is very important to understand that users are full members of the opensource community. There are usually more users than developers. And in order to want to become a contributor to the project, they first start using it one way or another.



The first users for Embox was the Department of Theoretical Cybernetics. They suggested creating an alternative firmware for Lego Mindstorm. And although it was still local users (we could meet in person and discuss what they want). But still it was a very good experience. For example, we developed demos that could be shown to others, because robots are fun and attract attention. As a result, we had truly third-party users who began to ask what Embox was and how to use it.



At this stage, we had to think about documentation, about means of communication with users. No, of course, we thought about these important things before, but it was premature and did not give a positive effect. The effect was rather negative. Let me give you a couple of examples. We used googlecode, the wiki of which supported multilingualism. We made pages in several languages, not only English and Russian, which poorly could poorly communicate, but also German and Spanish. As a result, it looked very ridiculous when asked in these languages, but we can’t answer at all. Or they introduced rules about writing documentation and commenting, but since the API changed quite often and significantly, it turned out that our documentation was outdated and misleading more than it helped.



As a result, all our efforts, even not correct ones, led to the emergence of external users. And even a commercial customer appeared who wanted him to develop his own RTOS. And we developed it because we have experience and some developments. Here you need to talk about the good points and the bad ones. I'll start with the bad ones. Since many developers were involved in this project on a commercial basis, the community, and so rather unstable, split up, which of course could not but affect the development of the project. An additional factor was that the direction of the project was set by one commercial customer, and its purpose was not the further development of the project. At least this goal was not the main one.



On the other hand, there were a number of positive points. We got really third-party users. It was not only the customer, but also those for whom this system was intended. Motivation to participate in the project has grown. After all, if you can also make money on an interesting matter, it is always a pleasure. And most importantly, we heard one desire of customers, which at that moment seemed crazy to us, but which is now the main idea of ​​Embox, namely, to use the code already developed in the system. Embox's main idea now is to use Linux software without Linux. That is, the main positive factor contributing to the further development of the project was the realization that the project was used by third-party users, and it should solve some of their problems.



At that time, Embox was already beyond the scope of the student project. The main deterrent to the development of the project on a student model is the motivation of the participants. Students participate while they study, and when they graduate, a different motivation should appear. If motivation does not appear, the student simply ceases to participate in the project. If we take into account that students must first be trained, it turns out that they become good specialists by the time of graduation, but the contribution to the project, due to inexperience, is not very large.



In general, we are moving smoothly to the main point that allows us to talk about creating an opensource project - creating a product that would solve the problems of its users. As I explained above, the main property of the opensource project is its community. Moreover, community members are primarily users. But where do they come from until what to use? So it turns out that just like with a non-opensource project, you need to focus on creating an MVP (minimum viable product), and if it interests users, then a community will appear around the project. If you are only involved in creating a community through community PR, writing a wiki in all languages ​​of the world, or proper git workflow on github, then this is unlikely to matter in the early stages of the project. Of course, at the appropriate stages, these are not only important, but also necessary things.



In conclusion, I want to give a comment , in my opinion, reflecting the user's expectations from the opensource project:

I’m seriously thinking about switching to this OS (at least try it. They’re very active in sawing it and doing cool things).

PS At TechTrain we will have as many as three reports. One about open source and two about embedded (and one practical). At the stand, we will conduct a master class on programming microcontrollers using Embox . Traditionally we will bring pieces of iron and let them program. There will also be a quest and other activities. Come to the festival and our booth, it will be fun.