Open source projects are amazing in that practically anyone can come in and make a difference. But it can also be a burden for the exact same reason. Just ask project developers and maintainers.
If you have been or currently are a project developer or maintainer, this scenario may be familiar to you: you’re juggling a million things with your project and out of nowhere an external contribution comes in. You’re grateful of course, but you’re also sighing inside and thinking, great. More work for you. And you wouldn’t be wrong.
New contributions can come with a lot of work: reviewing patches and reworking code among others. But thinking of them in this negative way can lead to some bad decisions– decisions that can make open source projects a little less open and a lot more unwelcoming, sometimes even hostile. This is the one big mistake you do not want to be making.
New contributions help keep open source projects going. Developers should really avoid thinking negatively of them as this can lead to actions that keep new contributors away.
Purposefully Discouraging New Contributions
Unfortunately for some, this negativity and the bad practices that result from it can come instinctively or unknowingly simply to avoid “added” work. They’ll say they don’t want contributions; make it difficult for newcomers to make contributions; or purposefully make new contributors feel unwelcome.
The first thing that developers have to realize here is that doing these discouraging things will only hurt instead of help their project. They’re missing out on additional support that can only be beneficial to their project. They could be preventing the entry of a future maintainer. The second thing they need to realize is that these contributions are not really “added” work but work that is essentially part of every open source project. It may not always be the most important part, but it is still part of the project and of the open source process in general, so it should not be discouraged.
Blind to Bad Habits
Even if you don’t do things to purposefully discourage new contributors, there may be other things you’ve gotten used to doing that you didn’t know or notice are actually discouraging. For example: handing new contributors grunt work. It’s often instinctual for maintainers to hand these jobs off to newbies, and in many cases, it’s fine. However, this is not true for all. Some contributors have different motivations and expectations; others are more skilled than they let on. By simply handing them grunt work without consulting them, slowly but surely they will be discouraged to continue with the project.
Conversely, some maintainers expect newcomers to already know the ins and outs of the project, and ask too much of them too soon. This results in the newcomer feeling incompetent.
In these cases, it’s important for project developers and maintainers to properly assess the ability and expectations of newcomers and assign tasks appropriately. You can start by asking them to send in some patches, and review these patches. Simply communicating with them could even be enough to gauge where a new contributor would prove to be most useful within a project. By doing these things, newcomers will feel more fulfilled and be more likely to stick around and help, and the project will be able to benefit from maximizing the newcomer’s skills.
Hi,
I have a question for the article author.
Since the market is abuzz with innumerable productivity tools (for instance knowledge management software) to help businesses, I want to know which is a better option – an open source knowledge base or a cloud-based knowledge base?
As my technical understanding is limited, I want to understand in-depth what are the disadvantages of using an open-source knowledge base for a business and can it impact productivity as well?