Contributing
Increasingly I stumble upon articles that are pushing businesses to increase their investment in open source. I recently fought this battle myself, working against the legacy thought process that all source code of a business should be proprietary as key contributor of unique selling points. I want to ellaborate on my experiences for those of you also working towards such a goal, and provide some advice on how you can go about implementing the process itself.
Benefits
The benefits of open sourcing the code you write for your company may be obvious to you, but it is the crucial point you need to convey to stakeholders. You need to be fore-armed in these discussions, able to alleviate concerns and provide confident redoubt in your proposal.
Let’s go over some of the key benefits, from the business’ point of view, which will assist you in this battle.
Quality
There are two sides to this coin. The first is that by open-sourcing your code, you are openly inviting experts from across the entire globe to contribute and improve your product (at no cost to the company!). Certainly, many of the major OSS projects you rely upon yourself may have started the same way.
Although this sounds like a very attractive prospect, in reality your project needs to gain major traction before it will generate much attention from contributors. So, although this exists as a sellable pipe dream, don’t rely upon it.
There is a very observable upside to quality though. Most developers hold pride in their work, or at least fear the wrath of shame. If you tell a developer that the entire world is going to be able to see their commit history, the reviews on pull requests, the issues raised against the project, progress made and the code itself, they’ll start thinking about quality.
Teams will think about whether they are using the correct patterns, whether they are following best practices or utilising the most effective technologies. They will consider the development process end to end, and take it upon themselves to educate and collaborate with one another.
If your team is not already doing this, open sourcing your code is certainly one way to encourage it.
Motivation
Whilst I can’t deny that there are many developers who simply work 9-5 to pay the bills and could care less for self-development and the overall health of our industry, there are an ever increasing number of developers that do. Most employment contracts I’ve come across contain what has grown to be typical restrictions towards intellectual property that can give a developer doubt as to whether investing their own time creating software is worthwhile.
Developers work hard, within numerous constraints, often writing software that may not be of interest to them. If you offer them some freedom from these shackles and allow the developers not only to feel effort in their own time is of value to themselves, but do so in such a way that the company can benefit and still maintain control, everyone profits.
I’ve spoken before about how I believe that all developers should make time at home to refine their skills, constantly furthering their understanding of fundamentals and keeping an eye on latest technologies. I would be hesistant to hire anyone that didn’t do so, but at the same time we need to empower our developers to do so.
Although I admit the others listed in that tweet probably did a great deal more than I, I’m proud to be acknowledged for my efforts. All too often in business the feedback from our customers are that of bugs, issues, and negativity, or simply non-existent. It’s nice to get a pat on the back for doing something we love!
Publicity
We’re not talking about world-wide marketing here. Although I’m sure there are a fair few cases whereby the popularity of open-source contributions of a company have generated the interest of higher calibre talent, for the majority, the scope of this type of branding is much more localised.
However, it is most definitely present. Not so long ago I decided to move on from a company called 4Com. Their teams and development process were some of the best I’ve come across, and their developers some of the most talented I’ve met. They encouraged not only open sourcing, but for developers to get their names out there. Whilst working at 4Com, I can’t say I noticed any particular difference from contributing to open source, blogging, and so forth, other than myself and many of the other developers relishing within such an environment.
When it came time to move on to greener pastures, I found myself for a brief period back on the recruitment market. This is when it became evident just how substantial of an impact our efforts had made. In almost every interview I attended, people had heard of the talent at my former company; it was a sought after, leaving me spoilt for choice.
Although it hadn’t been so evident from the perspective of my prior employment, we were most definitely making ripples. Wouldn’t you want your competitors to envy your workforce? Wouldn’t you want the best developers to seek you out instead of fumbling through for the proverbial needle in a haystack?
Trust
So, you’ve sold the benefits of open sourcing to your company and you’re just waiting to hear back? Still waiting? Sat in limbo?
There are numerous legalities, and ultimately a concern of trust that your company and higher management may be struggling to overcome. In fact, the may well be struggling to even discuss it with you. It’s not pleasant telling someone “I don’t trust you” but at the end of the day, the company cannot leave itself feeling exposed. After all, if the company trusted you completely, there would have been no need to discuss the benefits of open source; they would have trusted that you were making the right decision for the business.
My best advice is that you bring this issue out into the open. I will not discuss here concerns of copyright, licensing, and so forth because I firmly believe that is something you should research for yourself - not take the word of some blogger.
Trust must be earned, so providing the company with ample control over open source privileges can be a way to get your foot in the door and allow that trust to be built upon.
Process
The actual implementation of open sourcing for your company will likely vary by the level of control your company requires. The least level of control is simply to let the developers get on with it. I advise caution to the developers of such a regime because it only takes one person to ruin it for everyone.
Remember that your company has entrusted you. Abusing their generosity might see open sourcing removed as an option far quicker than it took to put in place.
For those that want to build confidence and trial the process of open sourcing, the following links can provide some guidance. Although both of these articles are exclusive to GitHub processes I’ve used in the past, I’m sure the concepts could be carried over to other sites and repositories.