12 challenges for open source projects | Opensource.com

12 challenges for open source projects

Posted 24 Jun 2014 by 

Rating: 
(7 votes)
Image by : 

opensource.com

submit to reddit

Open source is the combined contributions of millions of independent volunteers. This single concept brings with it a few inherent realities. In this article let's look at a few potentially concerning points about the nature of open source contributions.

One of the major, oft-touted benefits of open source software is the diverse, large, and ever ready army of developers contributing to the project. This can be an incredibly powerful argument when demonstrating the value of open source to a corporation. However, the larger the community and the bigger the pool of contributors the more opportunity there exists for problems or potential security risks.

Let's look at a few potential areas for problems and how good open source communities are protecting themselves from problems.

More contributors means more risk

This is a very real concern. When a community grows there are more developers contributing code to the project. As more developers contribute code and their solutions to problems there is a very real need to establish some guidelines for all contributors to follow.

Establishing a standard for code submissions, requiring acceptance of a common license, and implementing peer review are three ways in which good open source projects help to mitigate the risk of problematic code.

Establishing coding standards

Code standards are a set of guidelines or rules which the open source project expects all code submissions to adhere to. Most open source projects of any size establish these standards, Joomla, OpenStack, Ubuntu are three such examples. Usually code standards are simple procedures to ensure that every code submission looks similar and once merged will make the system feel as a single unified piece of software.

Accepting a common license

Open source projects should always have a software license of some kind. This defines the distribution policies and the methods in which others can use the software. An important step to consider when allowing developers to contribute code is the license which should be applied to the proposed code. It is important because developers must be aware and in agreement with the license type chosen by the project. Some open source projects request a signature to acknowledge the license type of any code submitted.

Implementing peer review

When an open source project becomes large it becomes increasingly difficult for a limited number of core contributors to review each and every code request submitted. Very quickly this becomes a bottleneck for the entire project and slows the progress and growth of the software. Implementing peer review is the most common practice for fixing this bottleneck. This process requires other developers to understand the mission of the project and the quality to be achieved from all submissions.

More contributors means less security

Some argue that when open source projects grow in size they open themselves up for security risks and hazards brought about from a diverse group of contributors and secret agendas which might otherwise be disallowed in closed source software.

While there is a certain reality in a singular controlled environment found in closed source corporations the advantages of open source far outweigh the perceived risks. In addition, these risks can be easily controlled with a thoughtful approach to community organization.

Shared vision

If a community is grown organically and carefully around the shared vision and goals of the organization then the community becomes much stronger than even a closed source corporation. They become more than individuals contributing code to a project.

When volunteers share a common vision they become so much more than a community of individuals.

Individual objectives fade and blend into the whole. Everyone begins to merge into a single focused community.

Personal ethics

When a community is built on common goals and a vision which is shared by the contributors then personal beliefs are enforced and individual personal ethics are held strongly voluntarily. Open source provides a certain freedom. The idea that each volunteer is responsible for their own actions brings with it a sense of personal empowerment but also a sense of self-governing.

Trust is not something to be bought. Trust is something shared. Trust empowers people. Open source communities are built on trust.

More contributors means less progress

Some would attempt to raise the argument that when the number of contributors grows too great then the progress of the project is slowed and ultimately the project suffers. The notion is a common one and relates well to an old phrase, "too many cooks spoil the soup." While there is truth in the saying this is not an absolute truth and taking the proper steps will make this potential negative an incredible positive for open source communities.

Defining tasks

Assigning clear tasks and delegating responsibilities is one way in which good open source projects are able to protect themselves against the potential problems of too many contributors. When a project defines goals and objectives and then breaks them down to assignable tasks they encourage contributors to work together towards accomplishing those goals. Instead of everyone dabbling in everything they clearly assign specific tasks and thus make tremendous progress.

Listen and focus

Similar to what was discussed earlier, the establishing of a single shared vision and focus for the project will help developers and other contributors to keep momentum moving forwards towards accomplishing those goals. This means less time wasted in meetings and endless debates and discussions on the trivial matters and empowers contributors to spend their time focused on accomplishing the vision of the project.

Yes, listening is important and ensuring the shared vision is an appropriate representation of the shared goals of the community requires discussion and debate; but this should be done occasionally rather then consistently. Once it's been determined and agreed, it's time to move on. The result is the larger the community the better for the project because more progress will be made.

Nothing is perfect

There will always be pain points in open source and no community is perfect. However, the argument that open source communities are somehow less ideal than a closed source corporation is simply untrue. The list above is just a small sample of how each potentially perceived risk of open source can be mitigated and resolved.

Open source may not be perfect, but there are millions of volunteers reasons why open source is a better option than the alternative.

Originally posted on David Hurley's blog. Reposted under Creative Commons.

submit to reddit

Comment now

David is an open source evangelist and promotes multiple open source projects. He is currently the Community Manager for Joomla! and a member of the Production Leadership Team. David writes frequently about open source and spends his time helping businesses find success with open source solutions.

Reader favorite