Avoid these bad practices in your open source projects

On the web you can find a lot of information on how to develop an open source project, but nobody comments on what you should avoid. That is why we want to tell you about some negative behaviors or bad practices, which must be avoided for the project to be successful.

• Believing that your contributors are a nuisance

When someone external makes an observation, the developers think that they have given them more work and it really is, but ignoring these props is a mistake for an open source project. Rather, they must welcome and thank that they are working with you, so that they continue to do so. Later these people could become your co-workers.

You need people to make a contribution, then make a second and a third. So it is possible that your project will have its new maintenance representatives.

• Letting people just do the dirty work

Each person who wants to contribute to an open source project has different reasons for doing so: some are users and others want to experience helping in this type of work. In the second case, it serves as an exercise or learning to give something to the computing ecosystem they use.

Many take advantage of this goodwill and give the dirty work to those who wish to collaborate: tasks without interest, with little value and without direct impact on the project. Take care what tasks you assign to your contributors because some might be offended, and remember to give their credit to whoever deserves it. It's the only way to keep them close and keep helping.

• Setting very high expectations for new employees

In principle you must take care of what task you will assign to the new contributors. Some can be very complicated and cannot be done, so they will end up scared or disappear because they do not feel able to help.

Talk to them beforehand about their skills and you can make an overview of their ability and guide them to shine in the project. Along the way some will stay and others will leave, but it is part of the process.

If you can, become their mentor because that makes your collaborators feel welcome. This advice applies to other areas as well.

• Asking these people to make some sacrifice in their lives

These collaborators contribute voluntarily and in their free time, so they should not be asked to make great sacrifices. It is frowned upon (for this type of work) that contributors have to travel a long distance, neglect their family for a few days, spend a night in a hotel or away from home to be part of or fit into a project. Remember that not everyone who helps has the same time zone. It is preferable to assign them certain tasks, indicate a delivery time and let them execute at their own pace and in their available time.

However, it is recommended to do some social activities to share and get to know them. You can also make video conferences using free software.

• Thinking that foreigners are strange

It is well known that most open source projects use English as a common communication language since it is the universal language and it has worked well so far. But many people were not born speaking English and some are not fluent, so some people get frustrated at the slowness of the conversation.

It is in bad taste when a speaker who is fluent in English ignores people because they speak slowly. But the drawback is that by not being able to communicate in the same language, people are not on the same level of oral conversation. Much patience and they will understand each other perfectly.

• Without vision there is no way to delegate

It is a common mistake in open source projects to see how the leader struggles with the growth of his project, even when he has people trying to help.

When collaborators begin to arrive, they begin to add new characteristics, they want to evaluate and be oriented; and the project leaders become paralyzed and do not know how to respond, so the contributors get frustrated and sooner or later disappear.

It is extremely important to have a vision for the project and communicate it. Make it clear to your collaborators what you want and what not to avoid friction between the participants, so they will know whether to join your work or not. This way you can be a good captain.

Once they join your project, you should trust them as soon as possible and delegate some responsibilities to them. Give them a whole part so they feel as responsible as you. If, on the contrary, you maintain too much control, you will be left working alone and you will stop its growth.

• Forget to be grateful

The experiences and feelings of your collaborators will always be different, but all these serve as learning. Thank it.

If you have something to add to this list of bad practices, we invite you to include it.