Your Company is Screwing Itself by Not Supporting Open Source Software

An artist’s representation of what is happening to your company

“How long will that take to make?”

Ah, the old dreaded words. Let’s all run to Twitter now and whine about how “this has never been created before” and “they don’t understand software” — and anyway, we all know you should never rush an artist.

This will be a short piece, so I’m not going to go down that rabbit hole right now, but tell me one thing: When a construction company is handed a one-of-a-kind blueprint of a new house, do they respond, “Well, golly gee! This has never been built before — I have no idea how long it would take”?

(We’ll ignore stuff like Union Hours & the Mafia for now. I know it never ends up being what they said. That doesn’t mean they don’t usually know.)

They know because they know how long it takes to lay a concrete basement floor, and how long it takes to build a stud wall, and how long it takes to wire a room. They don’t look at the whole house as a unit — they look at all the parts and add them up (and then do whatever their padding formula is, I’m sure. )

If you are good at creating software estimates, you probably already know the Joel Spolsky guide to making (somewhat) accurate ones. Break it down into small bits that you can understand. When I ask you “How long would it take to create a migration file for a new database table and add a framework model and endpoint that lets me look up a single record by id”…you could probably get pretty close on that one, no?

Now…here’s where we start honing in on my point. I may have lied to you a little bit above — that construction team may not know how long it takes to build a stud wall with wiring. Why not? Because they use bloody pre-fab for everything these days! They know how long it takes to stick a fully wired pre-fabricated wall into place and attach it.

And they can probably tell you that number with even greater accuracy.

They use composer packages. They use node modules. They use Ruby gems. Stuff that other people make, that lets them have efficient processes & fantastically accurate estimates.

You don’t think that’s important? You don’t know shit about business.

That manager may be a royal pain in the ass, but he really does need to know how long this project is going to take. Your whole “I’m an artist” schtick isn’t going to go over with them (and will inevitably lead to their wanting to “get more involved”, which is never a good thing.)

So…what is the natural conclusion of all of this?

1. Companies make more money when they can accurately estimate time and effort
2. When code is modularized into well-written, well-tested, well-documented packages, it is much easier to estimate build times on projects they are central to.
3. The point of Open Source Software is to build well-written, well-tested, well-documented packages.
4. The quality of #3 is directly related to how much time and effort the authors can afford to give those packages.

Now it feels like what I’ve said up until now is old hat and completely obvious, but I don’t think that’s true. I think most companies, from tiny start-ups all the way on up — are only looking at OSS as, “How many dollars am I saving by not having to pay for writing this code?”

What they are missing is, How much are they making by being able to accurately forecast when they can bring a new feature to market? How much are they making when they know how quickly they can start on a new client’s work? How much are they saving when they don’t accidentally hire too many developers, or try to line them up for a project and lose them because it doesn’t start on time? That’s where the real money is in this equation.

But here’s the catch — how often do we think, “I’ll use File Upload Library Kazaam and knock this out in 3 hours”, only to find that there are a couple little problems in implementing it that you had no real way of anticipating but now 3 hours is 3 days?

Modularized and tested code will not give you the big savings — accurate estimates — without excellent documentation and support. And because no one wants to pay for those things, they tend to be hard to find in most projects.

And so companies are shooting themselves in the foot by not making relatively tiny financial support to the libraries that they build their business on.

I realize I’m preaching to the choir.

Even without my steeltrap arguments you probably would have been in agreement that OSS should receive donations. Let me ask you, though — what have you personally done to facilitate that?

Here’s a few simple things you can start with:

1. If you work on hourly contracts, see if donations to package authors is an expense you are allowed. If not — charge an extra hour each month and pass it on.
2. Don’t always rush to grab the free version of something. Look at paid versions, see the difference and if the price is justified, and use it. It is probably better code and easier to use, and you’ll be happy you did anyway.
3. If you are in a more corporate setting, your IT department probably has a monthly slush fund that it can spend without getting any special approval. Your boss is probably a techie like you. Make a quiet policy to donate a bit each month out of that.
4. If you are an agency, you are probably the group benefiting the most from OSS. Pick a couple of packages you really depend on and approach the author about becoming a sponsor in exchange for being able to ping them with issues that come up. It will more than pay for itself, believe me.

Possibly most import — spread the word you are doing this! Let it become the new “normal”; let other companies start to scratch their chins and wonder if they shouldn’t be doing this too.

Not every package needs or even expects this kind of treatment, but there are far too many incredibly important ones out there that hardly raise a dime from their beneficiaries.

It’s time to change that.