Rebuilding the Enterprise - Software, Hardware and Peopleware Migrations for the Systems Architect

8/10/2015

Valuing Developers Over Intellectual Property

As is not uncommon, I went on a pretty hard Twitter rant the other night. Aimed at the industry in general, I hit squarely on a few of the trappings of current software/technology business practices. The problem was that my approach was overwhelmingly negative, and while negativity serves to provoke and stir up controversy, it more often exacerbates the problems at hand as the targets of criticism simply entrench themselves deeper. Additionally, I was missing heaps of context that, in hindsight, makes my point complete. So, the series of blog posts that follow are simply a flushing out of my prior rant. For the sake of accountability I will start each post with my original thought, tear it down and then reshape it into the proper thesis it should have been.

***

Tweet #1

Controversial Statement:
"You value your company's intellectual property over the company's employees."

What it should have said:
"Understand that your employees generate the intellectual property that in turn makes your business valuable."

Let's start with a hypothetical question.  Does your company make money from a product or service that was built once and has never needed additional maintenance? If you answered 'YES', then please tell me how I can invest; otherwise we need to talk about a few things...

If we know that we need to value our employees, how do we go about showing it?  There are the typical forms of compensation that come to mind - paychecks, stock, time off, sick leave, just to name a few.  But let's challenge ourselves.  How about food and coffee, or child care services, perhaps onsite dry cleaning, or transportation to and from your Mayan temple themed campus.  All these, be it compensation, or benefit/perk are provisional and are a raw expense to your business that buys you a commitment from an employee, but little else.

What if, however, there was a place you could spend your money that could benefit both you and your employee?  Slow down and don't be too proud of yourself; naturally concluding that I am referring to training, because while brown bag lunches, seminars, and conferences do indeed make your employees more valuable to your organization, so does forcing them to actually take their vacation time.

I am referring to ...

Open Source Software

"Sure, we use that stuff" - you say. Yes, but to what extent? As I see it, there are three tiers of commitment that govern the return on investment/options that participating in the open source community affords.

At the base level of commitment are the users of OSS, and most everyone these days uses some open source software in their day to day work.  Your usage helps the industry set standards by proxy, meaning that the more installations of a piece of OSS, the more weight that project has in the community.

The next tier is for those contributing to OSS.  These are typically independent developers or organizations that use the OSS and help to maintain or grow the software through bug fixes and feature adds.

The final tier - the highest level of commitment, represents the producers of OSS.  These are developers and organizations that either build new tooling out in the open or decide, for any handful of reasons, to take what was previously a closed source piece of software and open it up to the world.

The theory here is that as you increase your organization's commitment to open source software, the benefits and options that your commitment affords will also increase.  Let's look at a few of the benefits:

Training

Perhaps the most rudimentary of benefits is simply the exposure of your teams to different code bases.  Having the opportunity to simply read someone else's code will add design tricks and best practices to your tool box that even two day conference sessions can't teach.  Additionally, the structure of most projects forces the inclusion of unit and integration tests, automated builds, as well as code reviews, which, if your organization does not use these techniques, are invaluable to successful maturation of software products.

Decreased Risk

This has been a sensitive topic since the first volley of security concerns were lobbed back and forth between open and closed source advocates.  I would like to partially side step the security concerns and focus instead on adoption risk.  By committing to using a project, or even better contributing to a project, you are casting a vote into the OSS community with your time, energy, effort and talent.  This commitment can show other organizations and developers not only that you care about their work, but also that their energy and efforts are useful to the broader community.  This show of support can elongate the life of a project and even entrench its usage in a community further, thereby decreasing your risk of adoption.  (As an aside I would like to note that you can often contribute to a project monetarily by directly supporting a project's committers, reimbursing them for their time.  This is often a solution to needed bug fixes when/if you do not have the bandwidth for such efforts.)

Increased Exposure for Your Business & Increased Exposure for Your Developers

While this topic is somewhat controversial and not everyone agrees on the approach, I am a huge proponent of using OSS as a growth tool.  An organization's commitment to OSS can be a bit of a double edged sword.  On one side, you are increasing your developer's exposure to the broader community, a bonus for them; and on the other hand you are increasing your developer's exposure to the broader community, potentially a loss for you.

The way I see it is that having your employees poached or hired out from under you is a reality regardless, so allowing them to contribute to OSS, expanding their portfolio, is just another form of compensation.  If they stay, then you are getting a more well rounded employee.  If they leave, then at least your firm has shown to the community that you are invested in OSS and you are therefore more attractive to an even broader spectrum of the developer community.  Either way its a bit of a win-win.

Better Quality Software for Cheaper

The final level of commitment to OSS was producing/open sourcing works that your company has created.  This is a wonderful opportunity to get the community as a whole involved to help lower your development costs for projects.  Look no further than some of the great tooling coming from the likes of Facebook, Netflix, Etsy, etc. to see how opening your code to the larger world can decrease your costs and actually increase your quality!

Closing

In closing, cementing an organizational commitment to OSS can be a huge gain for your teams as individuals as well as the organization as a whole.  Be sure to define policies regarding committing to open source to not only make your CFO/Lawyers happy, but also give your developers room to experiment and grow.

0 comments:

Post a Comment