IT festival will be held in St. Petersburg this week . One of the speakers will be Richard Stallman. also participates in the festival, and of course we could not ignore the topic of free software. Therefore, one of our reports is called . It will focus on the history of Embox as an open source project. In this article, I want to talk about the main ideas that, in my opinion, influence the development of open source projects. The article, like the report, is based on personal experience.
Let's start simple, with the definition of the term opensource. Obviously, an open source project is a project that has one of the licenses that allows access to the source code of the project. In addition, an open project implies the possibility of making changes by third-party developers. That is, if some company or developer publishes the code of its product, partially or completely, then this does not yet make this product an open source project. And finally, any project activity should lead to some kind of result, and the openness of the project implies that this result is used not only by the developers themselves.
We will not touch the problems of open licenses. This is too large and complex a topic that requires deep investigation. Quite a lot of good articles and materials have been written on this topic. But since I myself am not an expert in the field of copyright, I will only say that the license must meet the goals of the project. For example, for Embox, the choice of a BSD license over a GPL license was not accidental.
The fact that an open project should allow changes and influence the development of an open project implies that the project is distributed. It is much more difficult to manage it, maintain integrity and performance compared to a project that has centralized management. There is a reasonable question what for in general to do open projects. The answer lies in the field of commercial feasibility, for a certain class of projects, the benefits of such an approach outweigh the costs. That is, it is not suitable for all projects and generally an open approach is acceptable. For example, it is difficult to imagine the development of a control system for a power plant or an aircraft based on an open principle. No, of course, such systems should include modules based on open projects, because this will give a number of advantages. But someone has to be responsible for the final product. Even if the system is completely based on the code of open projects, the developer, having packed everything into one system and made specific assemblies and settings, in fact closes it. The code may be in the public domain.
There are also many benefits to these systems from creating or participating in open source projects. As I said, the end system code may remain in the public domain. Why, because it is obvious that hardly anyone will find the same aircraft to test the system. This is true, but there may well be someone who wants to check certain sections of the code, or, for example, someone may find that the library being used is not quite correctly configured.
An even greater benefit arises if a company separates some basic part of the system into a separate project. For example, a library to support some 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 get commercial benefit without creating open projects, it is enough for its specialists to participate in third-party projects used in the company. After all, all the benefits remain: employees know the project better, therefore they use it more efficiently, the company can influence the direction of the project development, and the use of ready-made debugged code obviously reduces the company's costs.
The benefits of creating open source projects don't end there. Let's take such an important component of business as marketing. For him, this is a very good sandbox, which allows him to effectively assess the requirements of the market.
And of course, we should not forget that an open source project is an effective way to declare yourself as a carrier of any specialization. In some cases, this is generally the only way to enter the market. For example, Embox started out as an RTOS project. Probably no need to explain that there are a lot of competitors. Without the creation of a community, we simply would not have had the resources to bring the project to the end user, that is, for third-party developers to start using the project.
The community is key in an open source project. It allows you to significantly reduce the cost of project management, develops and supports the project. We can say that without a community there is no open source project at all.
A lot of material has been written about 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 people tell how to manage an existing community, but the moments of its creation are sometimes overlooked, considering it a given.
The main rule when creating an open source project community is that 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 logging library on js and some highly specialized driver. Moreover, at different stages of the development of the project (and hence the community), the rules change.
Embox started out as a student project, as there was access to students in the systems programming department. In fact, we entered some other community. Members of this community, students, we could be interested in good industrial practice in their specialty, scientific papers in the field of system programming, term papers and diplomas. That is, we followed one of the basic rules for organizing the community, community members must receive something, and this price must 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 were the Department of Theoretical Cybernetics. They offered to create an alternative firmware for Lego Mindstorm. And although these were still local users (we could meet with them 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 is 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. I'll give you a couple of examples. We used googlecode, whose wiki supported multilingualism. We made pages in several languages, not only English and Russian, in which we could barely communicate, but also German and Spanish. As a result, it looked very ridiculous when asked in these languages, but we cannot 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 more misleading than helpful.
As a result, all our efforts, even the wrong ones, led to the appearance of external users. And even a commercial customer appeared who wanted to develop his own RTOS for him. And we developed it because we have experience and some developments. Here you need to talk about the good moments 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 was already rather unstable, divided, 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 his goal was not to further develop the project. At least this goal was not the main one.
On the other hand, there were a number of positive moments. 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 earn money on an interesting business, it is always nice. And most importantly, we heard one desire of customers, which at that time seemed crazy to us, but which is now the main idea of Embox, namely, to use already developed code in the system. Now the main idea of Embox is to use Linux software without Linux. That is, the main positive moment contributing to the further development of the project was the realization that the project is used by third-party users, and it should solve some of their problems.
At that time, Embox had already gone beyond the student project. The main limiting factor in the development of the project according to the student model is the motivation of the participants. Students participate while they are studying, and when they graduate, there should be another motivation. If motivation does not appear, the student simply ceases to participate in the project. If we take into account that students first need to be trained, then it turns out that they become good specialists by the time they graduate, but the contribution to the project, due to inexperience, is not very large.
In general, we are smoothly moving on to the main point that allows us to talk about creating an open source project - creating a product that would solve the problems of its users. As I explained above, the main property of an open source project is its community. Moreover, community members are primarily users. But where do they come from until there is nothing 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 building a community through community PR, writing a wiki in all languages of the world, or proper git workflow on github, then it 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 would like to , which in my opinion reflects the user's expectations from the open source project:
I'm seriously thinking about switching to this OS (at least try it. They are very actively sawing it and doing cool things).
PS On we will have three reports. One about open source and two about embedded (and one is practical). At the booth we will hold a master class on programming microcontrollers using . Traditionally, we will bring the pieces of iron and let them be programmed. There will be a quest and other activities. Come to the festival and our booth, it will be fun.
Source: habr.com