What Is Your Open Source Policy?
A lot of large companies have a policy of not allowing any Open Source software. Years ago one of my clients was a big corporation and the policy was pretty reasonable. We could use Open Source software but we had to have the source code and compile it ourselves so that if we needed to fix anything later we could. The image above is a comment on a blog post from a concerned employee who works for a client which has a strict no Open Source policy, even if it is from Microsoft. That is a bit extreme.
This policy is probably not uncommon with many companies and these policies are likely very old and surely out of date given all of the changes in the last 10 years. Not using any Open Source software is incomprehensible to me. The company is likely making a few false assumptions about Open Source projects.
Mostly False Assumptions
1. The quality of the code is not that good if they are just giving it away.
2. The Open Source license will get the company involved in a lawsuit for not open sourcing their own proprietary software.
3. There is no support available for Open Source software like is common with proprietary software which is sold with a support contract.
Quality of the software which is Open Source can be judged by the number of users and how long the software has been actively developed. Over many years software matures and deficiencies are found and fixed, just like proprietary software. The projects which do not fix problems and serve the community well do not stay around for long. The jQuery library is a core engine which enables a large collection of plugins that are listed in a directory which shows the version number and release history. You can see a plugin which has many releases over the past year with lots of watchers and forks on GitHub is likely better than one which was recently released and has no watchers on GitHub. More activity over a longer period of time is a good sign that a project has matured and is staying current.
Be Aware of GPL v3
If a company is worried about a lawsuit they should be aware of the GPL license. It is known as a viral license because it requires any software created with it to also be licensed under a compatible license. It is not business-friendly if the business makes money selling proprietary software. If your company does not intend to make your work Open Source you should avoid GPL licensed software and instead look for MIT, Apache and BSD licensed software. By sticking to business-friendly licenses you will eliminate the threat of being sued. You may still be required to acknowledge the Open Source projects you use to build your applications. This is very common. If you look at the About screen for Google Chrome there is a link to credits which list all of the Open Source projects used to create the web browser.
Examples of GNU licensed software are the GNU Compiler Collection, Wordpress and the Linux kernel. Of these 3 projects only GCC is GPL v3 licensed while Wordpress and the Linux kernel prefer GPL v2. Alternatively Ghost and libxml are MIT licensed.
Update Your Policy
Avoiding Open Source entirely is nearly impossible now. Companies like Microsoft, Google, Apple, Adobe and IBM have all become Open Source companies. Sure there is still plenty of code which is proprietary but the parts which do not really offer a distinct advantage are best as Open Source.
One example is WebKit which was published by Apple after forking the KHTML project. WebKit renders HTML and CSS in the Safari and Chrome browsers. It is also used for Adobe AIR and many other applications. By using it Apple, Google and Adobe can save a great deal of time and resources while ensuring they are as compatible as possible to the standards and each other’s products. Each of these companies contributes improvements to WebKit and ongoing development continues to add more support for emerging web standards. And while Google and Apple both use WebKit the Safari and Chrome browsers still offer unique features to distinguish themselves and integrate with the rest of the software and services they provide. WebKit is the ideal example of Open Source being used properly.
In order to revise your Open Source policy you could simply require the following.
1. No viral licenses. The Open Source license must not be a viral license like GPL v3. Acceptable licenses include MIT, Apache, BSD or other compatible licenses.
2. Download and build the source code. Source code for each project must be saved with the rest of the in house code base to ensure it can always be compiled to the binary form which is used in proprietary software. It should be possible to make fixes to this source code and rebuild it if a critical bug is found and the Open Source project has not fixed the issue. (Always file a bug report with the project.)
3. Require unit tests. Acceptable Open Source projects must come with a suite of unit tests to confirm proper functionality so that these tests can be run with each release to ensure there are no breaking changes. These unit tests will also assist with any bug fixes which have to be made in house. Projects which do not have unit tests need some time to mature and are best to avoid.
With these guidelines in place you should be able to take advantage of a massive amount of great software which is out there. GitHub has become a great collection of Open Source repositories with features that make using Open Source very easy.
Keep in mind that you can also use Open Source software just for reference as well. I often read through code which does what I am trying to do to learn from it. I may be using a system framework for the first time and just need a sample project to show me a good way to use it. Once I learn from the reference project I just write the minimal amount of code to do what I need to do. The Three20 project is a good example of a reference project. It is a ton of code with serious backward compatibility. It generates a ton of compiler warnings due to calls to deprecated APIs which I always want to eliminate. The Three20 project does a lot with many great features but I often just need to mimic one little detail. I learn what I can and form my own solution from it with much less code. And then in my new code I can leave a comment with a link back to the GitHub project that was helpful.
Quick Tip: One trick I use on my Mac is to clone useful GitHub repositories to a Reference Code folder. I can use Spotlight to search for the name of a framework or a class name to find working code that I can use to learn about that framework or class. I can select that folder in the Finder and search just the subfolders to focus my search.
Meet The Developers
It is also a good idea to get to know the developers who support the software that you are using. If the source code is in a GitHub repository you can star and watch the repository so that you can track the updates to the project. To get familiar with the software you could even jump in and see if you can resolve any issues listed in their issue tracker. If you fix a few issues it will make the other project supporters much more willing to help you if you do come across an issue you have difficulty resolving.
What If I Find A Bug?
If you do come across a critical bug you have a few options.
1. Check for a new release. The version you have may be an older release. Check which release you are using and see if there is a newer one available. If there is read through the change logs to see if the issue you found was discovered and fixed. Even if you do not see a specific fix you can try a newer release to see if it resolves your issue.
2. Report the bug. If you do not see that it is already fixed you will want to make sure that developers supporting that software are aware of it and perhaps someone will start working to fix it. Be sure to write a helpful bug report so they know how to reproduce the issue and can confirm the issue has been resolved. A really helpful bug report would include a unit test which fails to show the bug. When the bug is fixed that unit test would be successful.
3. Fix the bug yourself. With an Open Source project you may get a fix quickly but more likely you will have to wait or fix it yourself. First log the bug and if you need it fixed right away ask for suggestions on how to go about fixing the issue. Others may not have time to dig in and fix it for you but they could have time to advise you through it. Act like the others supporting the Open Source project are your co-workers and work through the problem like you would in house. If you are working on a forked GitHub repository once you resolve the problem you can submit a Pull Request so that your changes make it back to the main repository and helps others.
Unexpected Benefits Of Open Source
What you will find from using these guidelines for Open Source and resolving bugs is that you will get to know the developers who also use and work on these projects. You can learn a lot from them so keep that in mind. You can even jump on IRC to chat with these developers to discuss what you are doing and what they are doing. Over time you will learn a lot and not just about the Open Source software you are using. You will learn about other projects and get to know the top developers out there and will be able to reach out to them. When most of us work on small teams with very specific focuses it can be a huge advantage to have a large virtual team of developers who have a wealth of knowledge that you can reach anytime. A short discussion on IRC could save you days or weeks of frustration.
Finally, if your company is unwilling to update their Open Source policy it is seriously time to leave as Brad Wilson suggests. Go where the company’s management understands the benefits of Open Source or at least allows you to use it. You will be much happier. Good luck!