What is open source software
By definition, source code for “open” source software is available for public at large to use, modify and contribute to. Using the software, or the source code as programmers do, makes sense; given the level of stability, functionality and maturity some of the open source software have achieved over the years. What motivates the developers to spend their time and energy to contribute into these projects? This question had intrigued me for a while and I only found the answer after contributing to one such open source software myself.
Some of the notable, widely adapted and acclaimed open source projects are:
New open source softwares are being developed everyday while some older ones are being abandoned for good at a similar rate, more or less.
Who funds open source projects
Every open source software, if it ever gathers pace, has a well defined and clear utility for a number of users and, by extension, to a handful of organizations. These organizations consume or depend on these open source software for their commercial products and it is in their interest to support the open source community for regular maintenance and advancement of the open source software in question.
It is worth noting, however, most of the successful open source software serve as a framework for development of applications relying on them. This motivates the application developer organizations with substantial stakes in the software to ensure that the framework progresses. These organizations, then, have the capability to steer the direction of a open source software, with maintainers in confidence. GCC, for example, is a widely used open source compiler. The developers of new processor architectures extend GCC to ensure it is capable of compiling binaries which are executable on their processors.
What’s in it for the developers
The developers can have a number of reasons for contributing:
- Passion – this is the primary motivation for all contributers. The developers believe in what the software stands for and what it is used for. They take pride in leaving a mark on its technical evolution.
- Visibility – what better way to prove your technical prowess than to contribute to a professional grade software, while overcoming the challenges that come with participating in an open source community.
- Organizational Efforts – employees of organizations depending on an open source project are occasionally assigned tasks to contribute to it, especially in the area of the organization’s interest.
- Income – although open source software does not pay directly, any organization in search of experts on an open source software is bound to get in touch with one of the contributors who know their way around the source code.
I believe I will come across or experience more motivating factors as I delve deeper in the community.
Challenges and their solutions
Developers working on any open source project come with a range of programming experience, variety of backgrounds, different native languages and even alternating timezones. This poses a number of challenges which have been effectively overcome by the open source community over the years.
Communication
Development in open source is distributed by nature. The first challenge is quick, effective, publicly visible communication with the possibility archiving important conversations. Most developers have not, and will never, meet each other in person.
Mailing lists serve as the primary mode of communication and, to some extent, as a loose technical documentation of implemented features. Emails exchanged between developers are CC to mailing lists which are publicly accessible as sorted archived threads. See https://lists.gnu.org/archive/html/qemu-devel/ for an example. With little to no effort, pertinent communication is accessible to all. The defacto language for communication on virtually all open source projects is English.
IRC is used for quicker, less formal, conversations. Open source community sets up IRC channels and all the relevant people can be contacted here. This is where the newbies, attempting to climb the learning curve, can discuss with the available experienced community members.
Authority
Who is the decision maker in case of a conflict? After all, there is no boss… actually there is: a ‘technical leader’ is how I would put it. ‘Maintainers’ as they are called are pioneers or veterans for a given open source project. They have spent years working on the software and know its organization and inner workings by heart. Bigger projects may have multiple maintainers, each expert in their own area of the software. They all collectively ensure that the software is following a general trend towards a shared vision. See the vision outlined for GDB by Pedro – maintainer of GDB.
Review System
A number of people contribute to the same source code tree simultaneously, resulting in the requirement to adapt a version control system. The most widely adopted examples are Apache Subversion (SVN) and Git. Within these version control systems, changes in source code are transferred and discussed in the form of patches. See a sample patch below which replaces a single line of code:
target-ppc/fpu_helper.c
@@ -1442,7 +1442,7 @@ static inline uint32_t efststeq(CPUPPCState *env, uint32_t op1, uint32_t op2)
#define HELPER_SINGLE_SPE_CMP(name) \
uint32_t helper_e##name(CPUPPCState *env, uint32_t op1, uint32_t op2) \
{ \
- return e##name(env, op1, op2) << 2; \
+ return e##name(env, op1, op2); \
}
/* efststlt */
HELPER_SINGLE_SPE_CMP(fststlt);
Community members discuss and review the patches on basis of its validity, approach, maintainability, long term impact and source code formatting – all hallmarks of good software engineering. Eventually, the maintainers give their stamp of approval. Finally, the patch is applied to the source code and becomes a part of the open source software.
Quality Control
Most of the quality checks are performed in the patch review stage. However, perfectly identifying the effects of a patch on every possible use case is virtually impossible and prone to human error. This is where automated test suites comes in. Running hundreds of thousands of automated test cases are on the software helps to identify and quantify bugs and hence ensure quality.
Conclusion
Open source software paradigm has seen continued success over the years. This model also satisfies the interests of big corporations indicating that it is here to stay at least for the next few years to come.
2 comments