OpManager: A single console to manage your complete IT infrastructure. Click here for a 30-day free trial.
Welcome Guest | Sign In
LinuxInsider.com

Corporate IT Needs to Embrace the Spirit of Open Source

Corporate IT Needs to Embrace the Spirit of Open Source

In an intra-business setting, we all work for the same company, right? Why shouldn't any and all code be freely available? Why should you have to write a new widget because your application doesn't have one yet? And if that widget API does exist from some other team, great. But why not also make its source code available?

By Elbert Hannah
12/03/10 5:00 AM PT

So, does your company do open source? Really? I'm not talking about using open source. I'm asking if your company takes open source philosophy to heart by walking the walk. I doubt there's any decent- sized company that doesn't use open source. But how many do open source in a business setting? Does your company *do* open source, like, within?

Where you work, is there a place you can go -- a repository you can browse where you can look at company code and freely use it for your own (corporate, of course) purposes?

Congratulations and praise to companies where employees can look at any code. But my experience has been that corporate code is locked as tightly as if it were some outside vendor's code. Why?

I once gave a Linux presentation to an auditorium filled with IT staff of the very large company for which I worked at the time. The presentation generated a lot of buzz, and during the Q&A session that followed, we got into an animated discussion about open source's important role and contribution to the success not only of Linux, but all OSS software.

During this discussion, we realized that we as a company did not have anything like an open source philosophy, and we became excited at the idea of taking action to create an open source atmosphere there. A core of IT techies lingered long after, and we sketched what we thought open source might look like in an internal business context. We were enthusiastic and ready for the challenge.

However, I was later approached by management and firmly admonished: What we had discussed was not appropriate. They made it clear that we as a company were not about to share code across teams, departments, etc. The code produced by each team and project was specifically *owned* by those teams. Wow!

Something That Doesn't Work

One approach I remember as an alternative (actually, way before the Internet as we know it) was to create standardized libraries with documented APIs that IT staff could call. I even signed on to one of the teams creating these libraries. Once. Was. Enough. We thought we would save the day. By creating proper and right ways to use libraries, IT staff would save time and energy not rewriting already invented code. Ha!

The libraries languished in dusty repositories. They may have offered "standardized" interfaces, but almost never delivered exactly what a developer needed. The official policy was to use the APIs as presented and tweak the external (calling) code as necessary to make the APIs useful. What? Heck, I didn't even use the libraries.

Additionally, they posited that they would succeed if they only enforced the standards. Right. Turned out to be the best way to reveal bad policy. By enforcing it. The "standards" weren't. And didn't get used.

Consider the Open Source Way

I think by most people's standards, Linux can be considered an astounding success. Anyone working in technology either is steeped in Linux work daily or knows what Linux is and what it contributes.

Underpinning Linux' impressive presence is the open source community. Now that OSS/FS, et al., have shown the way, why can't companies be open source -- at least "intra" open source?

Seems Risk Free

In an intra-business setting, we all work for the same company, right? Why shouldn't any and all code be freely available? Why should you have to write a new widget because your application doesn't have one yet? And if that widget API does exist from some other team, great. But why not also make its source code available?

Sometimes it isn't about calling other code, sometimes it's just about seeing or borrowing just a snippet of functionality for modest requirements. Open source provides this on a worldwide scale. Some of the best snippets and examples of code I've seen are freely available. Why not do the same inside a company for IT staff?

What Are the Risks?

I guess some may claim that the body of work that makes a company is intellectual property and only available to employees on a need-to-know basis, but what is "need to know"? Yes, code internally is corporate property, but for a collective IT staff, isn't code corporate glue that bonds company business?

Some may say that freely available source code exposes a company to theft and abuse. Maybe, but why and how is that different from the day-to-day access any IT staff already has? And, don't nondisclosure and code-of-conduct policies cover abuse? Meanwhile, the potential return seems huge.

Some Do, Some Don't

I know there are some companies that do allow access to most, if not all, source code. I worked for a couple. In my experience, I found it extremely helpful to find examples of code not only to help me understand technology better ("hey, what a cool way to do this!"), but also to learn more and understand better what my company does ("I never realized we used those totals for that product!").

I've also worked places where each team tightly controlled their code and any access granted was black-box. Not only was it opaque to use, it provided no insight technologically nor business-wise.

Kick It Around

Ever considered open source philosophy where you work? Why not kick the idea around?

Talk to your peers. Sound out management. Open source has a track record. Maybe your company will consider something radical.

They're already doing open source, right? Amazing returns from Internet open source -- why not from internal open source?

Anyone have experiences to share?


Elbert Hannah lives in the Chicago area and does production and scheduling support for a large financial firm. He wrote the most recent edition of O'Reilly's Learning the vi and Vim Editors. He has used Linux and worked actively in the open source community for over 10 years. In and around the house, he has more than 10 instances of Linux and as many versions and distros. He doesn't like technical religious wars and prefers things to be sorted out by merit. He loves the Beatles and thinks the greatest album recorded is Abbey Road.


Facebook Twitter LinkedIn Google+ RSS