An IT festival will take place in Saint Petersburg this week . One of the speakers will be Richard Stallman. is also participating in the festival, and of course we couldn't overlook the topic of open-source software. Therefore, one of our presentations is titled . It will focus on the history of the development of Embox as an open-source project. In this article, I want to share the main ideas that, in my opinion, influence the development of open-source projects. The article, like the presentation, is based on personal experience.
Let's start with the basics: the definition of the term open source. It is clear that an open-source project is one that is licensed in such a way that it allows access to the project's source code. Moreover, an open project implies the ability for third-party developers to make changes. This means that if a company or a developer publishes their product's code, either partially or fully, it does not automatically make that product an open-source project. Finally, any project activity should lead to some kind of result, and the openness of the project implies that this result is utilized not only by the developers themselves.
We will not touch on the issues of open licenses. It is a large and complex topic that requires deep investigation. Quite a lot of good articles and materials have been written on this subject. However, since I am not an expert in copyright law, I will only state that the license should align with the objectives of the project. For instance, the choice of the BSD license over the GPL for Embox was not accidental.
The fact that an open project must allow for modifications and influence the development of the open project implies that the project is distributed. Managing it, maintaining its integrity and functionality is much more challenging compared to a project with centralized management. This raises a reasonable question: why even create open projects? The answer lies in commercial viability; for a certain class of projects, the benefits of such an approach outweigh the costs. This means that the open approach is not suitable for all projects and is not generally permissible. For example, it is hard to imagine developing a power plant management system or an aircraft based on open principles. Of course, such systems should include modules based on open projects, as this will provide several advantages. However, someone must take responsibility for the final product. Even if the system is entirely based on the code of open projects, the developer, by packaging everything into a single system and creating specific builds and configurations, essentially makes it closed. The code can still be publicly accessible.
There are also many advantages to creating open projects or participating in them for these systems. As I mentioned earlier, the code of the final system can remain publicly accessible. Why? Because it is evident that it is unlikely anyone will have the same aircraft to test the system. This is true, but there may well be someone willing to check individual segments of the code, or for instance, someone might discover that the library being used is not configured quite correctly.
Even greater benefits arise when a company allocates a fundamental part of its system to a separate project. For example, a library for supporting a specific data exchange protocol. In this case, even if the protocol is specific to a given domain, the costs of maintaining that portion of the system can be shared with other companies within that field. Moreover, specialists who can study this part of the system in an open environment require much less time to utilize it effectively. Finally, creating a standalone entity that third-party developers can use enables that part to be of higher quality, as it necessitates offering efficient APIs, creating documentation, and, of course, improving test coverage.
A company can also gain commercial benefits without creating open projects; it is sufficient for its specialists to participate in external projects utilized within the company. After all, all the advantages remain: employees gain a better understanding of the project, thus using it more efficiently, the company can influence the project's development direction, and leveraging stable, pre-tested code obviously reduces the company's costs.
The advantages of creating open-source projects don't stop there. Let's take a crucial aspect of business such as marketing. For this purpose, it serves as a very effective sandbox that allows for an accurate assessment of market demands.
And of course, we must not forget that an open-source project is an effective way to establish oneself as an expert in a particular specialization. In some cases, it is the only path to market entry. For instance, Embox started as a project focused on OS development. It’s probably unnecessary to explain that there are countless competitors. Without building a community, we simply wouldn't have had the resources to bring the project to the end user, meaning that it could be adopted by third-party developers.
The community is key in an open-source project. It significantly reduces management costs, develops, and supports the project. One could say that without a community, there is no open-source project.
There are numerous materials on how to create and manage an open source project community. To avoid recounting well-known facts, I will focus on the experience of Embox. For example, an interesting question is the process of community creation. Many discuss how to manage an existing community, but the moments of its creation are often overlooked, as if they are a given.
The main rule in creating an open source project community is that there are no rules. I mean, there are no universal rules, just as there is no silver bullet, primarily because projects can vary greatly. It is unlikely that the same rules can be applied when creating a community for a logging library in JavaScript versus a highly specialized driver. Moreover, the rules change at different stages of the project's development (and thus the community's).
Embox began as a student project, as we had access to students from the Department of System Programming. Essentially, we entered another community. We could engage the members of this community, the students, by offering them valuable industrial practice related to their field, scientific work in system programming, as well as coursework and theses. In other words, we adhered to one of the fundamental rules of community organization: participants in the community should gain something, and this value must correspond to the participant's contribution.
The next stage for Embox was seeking external users. It is crucial to understand that users are full-fledged participants in an open source community. There are usually more users than developers. To want to become a contributor to the project, users typically start using it in some form or another.
The first users of Embox were the Department of Theoretical Cybernetics. They suggested creating an alternative firmware for Lego Mindstorm. Although these were still local users (we could meet them in person and discuss what they wanted), it was a very good experience. For instance, we developed demos that could be shown to others, as robots are fun and attract attention. As a result, we genuinely had outside users asking what Embox is and how to use it.
At this stage, we had to think about documentation and communication tools with users. Of course, we considered these important aspects earlier, but it was premature and did not yield positive effects. The outcome was rather negative. Let me give a couple of examples. We used googlecode, whose wiki supported multilingualism. We created pages in several languages, not just English and Russian, which we could somewhat communicate in, but also German and Spanish. Consequently, it looked very absurd when questions arose in these languages, and we simply couldn't respond. We also introduced rules for writing documentation and commenting, but since the API changed quite often and significantly, our documentation became outdated and misled more than it helped.
In the end, all our efforts, even if not perfectly executed, led to the emergence of external users. Even a commercial client appeared, who wanted us to develop a custom OSRV for them. And we developed it since we had the experience and some groundwork. Here, it is necessary to discuss both the positive and negative aspects. I will start with the negatives. As many developers were drawn to this project on a commercial basis, the community, already quite unstable, became divided, which inevitably affected the project's development. An additional factor was that the project's direction was set by one commercial client, whose goal was not to further develop the project. At least, that goal was not the primary one.
On the other hand, there were several positive aspects. We truly gained external users. It wasn't just the client, but also those for whom this system was intended. The motivation to participate in the project increased. After all, it's always nice to earn while working on something interesting. Most importantly, we heard one request from the clients that at that time seemed absurd to us, but has now become the core idea of Embox: to use already developed code in the system. Currently, the main idea of Embox is to use Linux software without Linux. Thus, the main positive aspect contributing to the further development of the project was the realization that external users were using the project, and it needed to solve some of their problems.
At that time, Embox had already gone beyond being a student project. The main limiting factor in developing the project under the student model is the motivation of the participants. Students participate while they are studying, and once they graduate, a different motivation should arise. If that motivation doesn't appear, the student simply stops participating in the project. Given that students need to be trained first, they only become skilled specialists by the time they graduate, but their contribution to the project, due to inexperience, is not very significant.
In general, we smoothly transition to the main point that allows us to speak about creating an open-source project — developing a product that solves the problems of its users. As I explained above, the main feature of an open-source project is its community. And the participants of the community are primarily users. But where do they come from if there's nothing for them to use? It turns out that, just like with a non-open-source project, we need to focus on creating an MVP (Minimum Viable Product), and if it interests users, a community will form around the project. If the focus is only on creating a community through PR, writing wikis in all languages of the world, or maintaining a proper git workflow on GitHub, 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 bring up , in my opinion, reflects user expectations from an open-source project:
I'm seriously considering switching to this OS (at least to try it. It's being actively developed and exciting things are being created).
P. S. At we will have three talks. One about open source and two about embedded systems (one will be a practical session). At our booth, we will conduct a master class on programming microcontrollers using . Traditionally, we will bring hardware and let attendees program them. There will also be a quest and other activities. Come to the festival and visit our booth; it's going to be fun.
Source: habr.com
