tecosystems

Open Source Offices: Cost Center or Fundamental Requirement?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

A couple of weeks back, Sun made the intelligent (IMO) decision to create an over-arching open source office along with a C-level spot at its head, to be staffed by Simon Phipps. I say it’s intelligent because I believe that it’s important for larger organizations not solely for single point of contact logistical reasons, but also because open source is a complex subject and requires both specialized expertise as well as an external viewpoint. MySQL’s Zack Urlocker seemed to be similarly inclined here. Danese Cooper, formerly of Sun and now Chief Open Source Evangelist with Intel, agreed in the above story, saying:

“Every big company ought to have one of these,” Cooper said. “You have to figure out what your [open-source] policies are and how you’re going to implement them. Every big company needs someone to know enough about [open-source] to help make decisions. … [Phipps] has done a lot of work in the years since he’s decided that open-source is something he’s interested in. I’m really pleased for him.”

Exactly right. Whether or not enterprises, ISVs and governments actively mandate open source and to what degree is to some extent academic; open source’s role is growing, and as such deserves the attention of dedicated resources. Even Microsoft, often decried for “not getting” open source, has made such a resource allocation in Jason Matusow, who heads their “Shared Source” office.

But when discussing these types of roles with some folks previously, a couple of people have paraphrased the Bob’s from Office Space, asking what such people actually do? Implicit in such a question is the idea that because such representatives frequently have no direct responsbilities for shipping products or the like, they’re nothing more than a cost center and drain on the business. While I’m sure there are lazy, unproductive Chief Open Source Officers somewhere, I personally have yet to meet one. And just as Jason’s diligent efforts have an impact that is felt far and wide within the halls of Redmond – much in the way that Scoble’s are, incidentally – Simon’s wasting no time rolling up the sleeves and getting to work.

Witness this bit of news that he forwarded over to me this morning: the deprecation of the SISSL license. While I’m far less concerned about license proliferation than some others in the open source community – Simon included – I’m certainly a believer that less licenses is a good thing. My lack of alarm at the proliferation issue is mainly due to the fact that the so-called vanity license problem to me is overblown, given that the vast majority of projects – and virtually all of the really important ones – are licensed under a handful of OSI approved options. But does it make sense to remove as an option a license whose time has come and gone? Without question. In the absence of an open source officer, would anyone care to give odds on this kind of thing happening? If not a COSO, then who? Legal? Ha. As an aside, I find Simon’s decision to make this announcement on his blog, without bugging everyone with yet another press release, very refreshing.

If the SISSL retirement doesn’t convince you, consider Simon’s earlier creation of an open source ombudsman role. I’ve always been a believer that in business at least, things that aren’t people’s jobs have a tendency to not get done. Not out of any instrinsic laziness, but simply that businesses and the people that run them tend a.) to have too little time, and b.) to devote that little time towards the things they get measured on, as opposed to the things that they don’t. Hence the unfortunate propensity of things to fall through the cracks, as in his FreeBSD example. Making open source someone’s job and sole responsibility, therefore, seems to me to be not merely logical, but necessary.

Sun’s not the only example I can point to here, of course. I’ve already cited Microsoft’s Matusow, but the need for resources with dedicated interests in and responsibilities for understanding how their business interacts with open source is no less pressing in smaller firms. Optaros’ Stephe Walli is a good example here, and one of his projects has been the Optaros Free and Open Source Software Policy. That he perceived not only the need for such a document but took it upon himself to produce it speaks well of him, obviously, but also to the organization that fosters such responsbilities. I think it’s an excellent document overall, with which I have only one quibble. I’m not particularly concerned about the line it treads from open source / commercial, because having been an SI myself I fully appreciate the reluctance of some clients to share their work externally, no matter how clear you make the benefits. The clause that concerns me is #8, which requires external work to be cleared with the higher up’s; I can see that rankling some of the developers that I know. But the important thing here is not that specific clause, it’s the idea that Optaros saw a need to explicitly define how and when they’ll work with open source – that’s a goal worth pursuing.

We could probably spend the rest of the day calling out similar examples detailing the intricasies of businesses working with open source and vice versa, but I think the salient point in every example would be the same: open source is a cross-cutting business concern. Given its horizontal nature and its relative importance within most of the organizations working with it, I’m convinced that resources with a relevant skillset and relationships need to be allocated to the problem, tasked with pursuing it, and perhaps most importantly – empowered to do so.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *