Introduction to Open Source

There are many technical explanations of Open Source licensing but this introduction looks to provide an insight into how Open Source works and how to be a positive influence on the community.

by  John Buswell     

Open Source is a community driven approach to building software where the consumer has access to the source code. The source code is the recipe for building the software. Open Source Software begins with a problem that NEEDS a solution. The need can be anything, from a problem the author is trying to resolve for themselves, a customer or just trying a different approach to traditional solutions. The author will come up with an idea to solve the problem, and then implement that idea as software. The author may realize that friends and colleagues could benefit from the solution, or that the solution needs expertise that they do not have. At this point, the author decides to release their solution as an Open Source Project. This three step process from Need to Idea to Project, is how Open Source Projects are created.

To release their solution as Open Source, the author will select an appropriate Open Source License. Announce the project and initial software release on a variety of Open Source web sites and continue to work on improving the solution. Other people from around the world who read the announcement or hear about the project may have the same NEED that the project solves. These people will download the project and evaluate it. Evaluation will result in one of three results, it will meet their needs, almost meet their needs or won't meet their needs at all. If it meets their needs, that person will become a user, and upon further evaluation implement the solution to solve their needs. For the case where it almost meets their needs, that person may choose to implement what it is missing, request the author to help implement what is missing or hire someone to implement what is missing. What is missing may be something the author actually needs but hadn't thought of yet, and maybe glad to implement it, or better yet, very glad to receive a patch with the work already completed. Here Open Source is working well, two people who wouldn't normally collaborate together have now worked together to achieve a common goal.

Everyone has different talents, which is what makes an Open Source Community work. If everyone was a developer, we wouldn't have documentation, and without users we wouldn't have different deployment solutions for a particular project. Community members contribute in different ways, just because someone may not contribute code, does not mean they are not contributing to open source. The level of contribution often evolves over time.

Initially, a user who finds the project meets their needs may contribute by simply telling other people about the project. These often unrecognized contributors are actually marketing the project for the community, whether thats telling a friend, using it at their place of employment or blogging about their great find, they are still marketing the project. That has value, as it helps to grow the community. While this user may not have the skills to help contribute to the code, they may tell one or more people indirectly about the project that do have those skills.

As the user gets further along with their deployment, they will find problems, figure out solutions and potentially find software defects. Most projects have some kind of system for collaboration whether thats a mailing list, a blog, forum or some other platform. Users will find problems, post their questions, and over time, they will gain confidence with the project to post solutions and answer questions from other users. This could be a problem they ran into in the past and solved themselves. They provide value as they are helping to build up a knowledge base for the project. When they find software defects, they submit reports and if possible patches. It maybe something as simple as just reading the code, and telling the developers where the problem might be located. Again, this brings value whether or not they provide a patch.

Over time the user may gain enough familiarity with the code to contribute patches, a patch is a source code change that fixes a problem or provides an enhancement. It could be that the user has deployed the project at work and a customer needed a particular feature that wasn't available in the project. The user develops the feature, and then contributes it back to the community.

Open Source Project Lifecycle

Open Source is a powerful way to develop software solutions. One of the key advantages is that it integrates the consumer / customer into the development process, and allows that consumer to be self-sufficient. Opponents to Open Source often do not understand how it works or they have business / financial reasons to play down the advantages of open source. Successful software companies have figured out how to be good corporate citizens within the Open Source community, often by integrating a hybrid strategy of open and closed source to provide a valuable solution to their customers. Less successful software companies attempt to poke holes in Open Source, questioning its quality, however by doing so, they are questioning the intelligence and skill set of their most valuable assets -- their customers.

The Open Source Life-cycle begins with Distribution, up until this point the development life-cycle is likely to be the same as most other software projects (Code, Build, Test). The quality of the initial distribution varies from project to project. After Distribution, comes the Use phase. Here any number of third parties will evaluate the project, and provide feedback. The quality of the feedback will vary, from forum postings to software patches. The goal of the feedback is to provide information to help fix and improve the project. Those changes are then discussed, changed if necessary and then submitted to the code base, ready for the next release cycle, where the process starts all over again.

This release cycle is no different from the Release, Support, Fix / Review and QA process that is widely used by commercial vendors. The only difference is that the feedback, fix and review process are done in a public forum rather than internally within a company. The other difference is that often the patching is done by the consumer, the customer, who has tested the fix against the exact problem they were seeing, and not a reproduction. While the fix may not be optimal, the submission process will have the projects development team review and correct the fix as necessary. Open Source gives the customer more visibility and control in the product life-cycle.

But Closed Source Has Support..

Commercial support varies from vendor to vendor, with varying levels of cost and response times. The basis for most commercial support is that the customer reports a problem to customer support, who in turn act as a front-line to determine if its a product defect or configuration problem. If its a product defect, the problem is assigned a priority and fixed in some future release. The length of time that passes from the time the customer reported the problem to receiving a fix, varies from a few days to a few months.

The problem for customers with this model is that sometimes it does not make business sense for a commercial software company to incur the cost of fixing a particular problem. The problem maybe unique to the customer's deployment, a corner case, and too complex to reproduce. The necessary changes may impact a more important feature, and a product manager may ultimately have the decision on whether or not the customer reported issue is fixed or not. The feature maybe phased out for a new implementation in an upcoming release, requiring the customer to purchase an upgrade. So even though the customer purchased the software in good faith, and the software is defective, they are now stuck. The problem impacts their deployment but they cannot get a fix, often this news is given to them months after they reported the problem, anticipating a fix.

The customer maybe in a position to use future sales and the size of their deployment as a means to force the commercial software company into fixing the problem. However, even in that situation, the quality of the fix is somewhat questionable, as it was ultimately something the engineering resources did not want to fix, but are being forced to do so for business reasons.

The customer has very few options in this situation, they cannot force the vendor to supply a fix, they cannot hire a third party to fix the problem and they don't have access to the source code to fix the problem themselves. They could attempt to force the vendor through litigation, but most vendors protect themselves against that scenario with End-User License Agreements. The only option is to switch out the solution, which is costly.

The same situation could arise from using Open Source Software. The consumer may report a problem, the community decide it doesn't impact enough users to fix or it doesn't fit with the roadmap agreed by the community for the project. These are essentially the same business reasons that the commercial vendors had. A lack of time and a lack of wide-spread need for the changes. With Open Source though, the No Fix response is not fatal, the consumer has options. They have access to the source code, so the first option would be to fix it themselves. If they do not have the capability, the next option is to hire a third party consultant to implement the changes for them. Another option might be to find a commercial support company that provides support for that project, purchase a support contract and have them implement the changes for you. This is where Open Source makes more sense for the customer, they have options and they have control. They are not at the mercy of the developers.

Open Source Means Common Sense and Fair Play..

When participating in any Open Source Community, it is important to act with Common Sense and Respect towards everyone. Not everyone in the Community has the same backgrounds, ethnic origin or skill sets, so it is important to act with a sense of "Fair Play" within the community. This is even more important when you factor in that members of the community may also be employees of competing businesses. As such, Open Source is very similar to football (soccer / futball) in that you have lots of games going on, players have different roles, different levels of skill, different backgrounds (professional or just for fun) and everyone has the desire to play. Just as its important to engage in Fair-Play for football to avoid injury and to make sure everyone enjoys the game, its equally as important for members of the community to engage in Fair-Play when dealing with Open Source. This includes using common sense, treating the community with respect, even if they are competitors, and abiding by the project licensing.

The Linux Kernel is a good example of this ecosystem. The kernel is used by many different projects and products, from Embedded Systems, to Community Distributions like Fedora, Commercial Distributions such as Red Hat Enterprise, Individuals and Educators. There are also competing Open Source solutions to the kernel, such as FreeBSD and OpenSolaris. When one competitor contributes something to the kernel, their competitors also benefit, but it works both ways. A competitor who isn't contributing, might be considered less innovative than another, and the contributors can be leveraged as thought leadership when pitching their products.

It makes business sense to contribute back to the community. In our example above we have an open source project which is a core component in two commercial solutions. Both competitors are working to attract a finite customer base, those customers can go with either solution, or they can utilize the open source project to create their own. Each competitor though provides their own added value to the solution, which for the customers may offer a faster deployment time, 24x7 customer support, perhaps an easy to use management interface or integration with some proprietary system they are using.

Whenever these competitors contribute code to the shared open source project, there is an argument that they are essentially helping their competition. While this is essentially true, the idea behind Open Source is that both competitors would contribute to the project, therefore the shared core component is a common goal and their value add is what they are really selling to the customers. In the event that the contributions are unbalanced, one competitor is providing the majority of the innovations, then they can use the contributions to demonstrate that they are the leaders in the field. Whenever code is contributed to the project, they promote those contributions through press releases and other public communications. Now, the leading competitor can make the argument that they are the innovative company that the customer should rely on, and their competitor is simply an imitator. The market will force the other competitor to provide more value add and contribute more to the project, ultimately balancing the contributions out.

The Open Source Ecosystem is essentially a free-market, but where time, experience and skills are exchanged instead of money. Projects are successful when they meet the needs of the community and where the community contributes back to the project. Some projects grow so large that they need separate entities to protect them and the interests of the community. Open Source projects, whether directly or indirectly often provide rewards to those individuals who put in the hard work. Whether this is to give them a platform to launch a successful business, have their skills recognized and obtain better employment, or simply knowing that they've helped many people with a specific need. Its all about choice, if you like the benefits and flexibility of Open Source, then choose it!

The wide variety of cool Tux The Penguin Graphics were provided courtesy of The Tux Factory, please refer to their site for appropriate licensing.