Experience in managing the development of a non-profit project or how to kill the nervous system
Many in the early days of acquaintance with programming choose “I will write my own,” instead of participating in someone else’s project. In principle, this choice is very clear, because no criticism, framework and codreview from the old, IMHO . Over time, of course, the choice changes, but there are exceptions. One of them will be discussed.
2016 – Hellow, World!
Recycling the old game engine was my idea, which I decided to do. However, my fork was not the only one, so it was necessary to somehow interest the community. About half a year of implementing minor, unnecessary edits to anyone, until an interesting idea came up. X64 support. And here come the first problems: we need a man who understands at least something in this. From that moment, problems began with the team.
More experienced member
It is always nice to have a person to whom you can turn for help with a particular problem, these developers can be divided into two groups: he is interested in and interest in him . If in the first case everything is quite simple, then in the second the situation is much worse. If you have such a member in the team, then you need to somehow maintain an interest in further work in it. Most often it works on the principle of concessions. (yes, you can support it financially, but we don’t have commerce) The more concessions, the less you manage this project.
First successes – first participants
Success is next to interest, so for some time there will be a stream of people who want to participate in the development. My first mistake was choosing the priority of the quantity, not the quality of such assistance. Which led to a large number of bugs that were fixed and are being fixed from 2017 to this day. Over time, the people will drop out on their own, in a good case – there will remain a couple of people who will still have at least some interest in this. Second mistakeI was trying to keep the remaining people, and not to develop the project in the chosen direction, which turned it into a sandbox. Different code style, constant disputes in the team, lack of a single idea and at least some kind of leadership. Each participant dragged the blanket in his direction. We managed to get out of the situation, removing everyone who tried too hard to insist on their own. Thus, calmer participants became more malleable, which allowed more or less to stabilize the situation. But, not everything is so good … The consequences of what happened killed almost all the community’s interest in the project, which brings us back to the first paragraph of our article. You need to do something worthwhile.
Forks, forks, and again forks
The next problem is neighboring forks. The project was OpenSource, so everything interesting flowed from it to neighboring projects, which led to the problem of uniqueness. The solution was to rework the base API to make the transfer of edits more difficult. Of course, anyone who is more or less versed in the language and API of the engine could transfer the necessary code, spending an nth amount of time, to study the changes. But still, some of the forks did not suffer from this.
Left in english
One of the strangest situations is when a person at some point drops everything and just leaves, breaking off all contacts. You have to either refuse a partially finished feature or modify it yourself / look for someone to finalize. In the second option, most often the development will begin anew, because “The taste and color markers are different . ” Often do not insist on the contrary, because there is a high probability of crutches and moral exhaustion both in you and in him.
A little higher, I have partially touched on the topic of review of developments, but still it is worth writing in more detail. If you introduce a review policy from the very beginning, it will help to avoid a series of problems in the future, namely:
- Lack of a single style
- Errors, bugs, exceptions
- Lack of content control
Moreover, it is desirable that the review was conducted by several people, I think it’s clear why …
So, I will briefly repeat all of the above: choose the quality of features, not their quantity. Watch what gets into master. Do not try to keep on the team those who create more problems than content.