Slashdot Mirror
How Often are Internal IT Projects Open Sourced?
An anonymous reader asks: "Most open source projects seem to started by individual contributors working in their personal capacity. I am thinking about projects like attendance maintenance systems, and not high-end infrastructure projects like Sun's Solaris. Most internal IT products are probably reimplementations of what exists at other companies, and do not bestow any competitive advantage to the developing company. The cost of developing the software is overhead, and they could potentially save money by open sourcing the projects and utilizing contributors' expertise. So, are there lots of instances of companies' internally developed IT products being open sourced?"
I doubt it. All the software I've worked on in-house would be absolutely useless outside the immediate company, and no-one without expert domain knowledge would be able to add much to it anyway. I'd wager that most inhouse stuff is =not= reimplementations of things other people are doing.
Or do a lot of companies calculate the industry cost of sunday magazine coupon promotions?
Well, I just recently received the blessing to release a bunch of internal PHP tools I made as open source... a test case management system, an inventory library system, and a scheduled task notification system.
It helps a lot when you can easily point out that the tools you want open sourced have nothing to do with the core function of the company, and are really serving a generic purpose and could be used by others. (It also helps to have designed the tools with this in mind from the start.)
My company asked that the company's name be included somewhere in the softwares' materials in the releases I was involved with; I figured this was a small favor to go along with, and it helped them appreciate the idea as having some sort of paid-forward benefit.
Terrorists can attack freedom, but only Congress can destroy it.
For open source software to be useful there's more than just make it available under an open source license: packaking, documentation, perhaps even some sort of rudimentary support. Large parts of the applications developed in-house might be reimplementations - but it's the rest which is the problem.
Most internal applications like the kind you are talking about are poorly engineered monstrosities that few would want to see the light of public exposure. They were thrown together on a far too short schedule just to fill a need, and are therefore exhibit some large subset of the following embarassing characteristics: unscalable, uncommented, unstable, hard-coded/non-modular, inefficient, unadaptable, buggy, etc.
While a switch from a DIY mentality to a shared/open-source model might alleviate these problems, whose going to be the one to put their crap forward as the starting point? Management will never give anyone the time to finish it and clean it up properly for publication, since there's no immediate or guaranteed benefit to the company (though certainly some to the competitors), and few in-house developers will have the balls to put their disfigured lump of an application out their for public review.
I think that you're trying to make a statement advocating open-source software for internal projects, not actually asking a question. Now there's nothing wrong with that, but let's be up-front about it.
I think that most of the in-house software will not be open-sourced. First of all, there's always the chance that the programs would benefit the competition. Remember that since they are the competition, they will generally need the same tools. Secondly, right or wrong, there is in some companies, the stigma of the "viral open-source license". Finally, internal programs often use internal (and sometimes proprietary) tools and are also seen as potential revenue streams. "Why give it away when we spent $XX,XXX developing it"
Note that this post is in no way meant to be a flamebait, just an honest assessment of what I've seen.
"Eve of Destruction", it's not just for old hippies anymore...
On the projects we create internally which are applicable to other businesses, even competitors, we sell the source if there is a market.
Why would we give it away for free?
The strategy I used was to explain to the IT group to which I was contracted that I was leveraging from a lot of existing open source, and that the "tradition" was to return something in kind for using this software. The portions related to the generic application were thus released, while the portion I do to solve the specific problem that drove this framework remain private to the client. This is the best of both worlds.
At all the companies I have worked at that use OSS have all taken something, improved it because they had a specific need for the improvement, then released the improvements. Our company is planning to do some optimizations to several OS statistical packages. However, the only reason we are going to do it, is because we need it to be faster.
As other people have pointed out, the internally developed stuff will most likely stay internal because it is poorly written/documented or would be to valuable to give away for free.
That said, if our company fails completely (ie not sold, just shuts its doors), I will advocate that the products be open sourced, because they very well could be.
While my company is in the research and development end of the spectrum, they are very particular about what makes its way out of the company. Most of our business is contracting work. In order to have work we need to get contracts and to get contracts, we need to beat out our competitors. One of the points of leverage is that we have an internal code library which is proven and tested. Giving the library away does not help us do our work any better nor does it help us win additional contracts, but it will help our competitors.
We do have less specialized code which could be released without any real backlash, but it's too much of a headache to go through the legal process with the company's lawyers to get something out as open source. I have some additions I'd like to make to a couple of open source projects, but I simply don't have the time to sit down with the lawyers and work through red tape nor do I have time to sit down with my upper management (non-programmers) and convince them that giving away some code is 1) a good idea and 2) will not hurt the company.
I always try to release under libre licences and open-source whatever I can, including my university assignments. Recently a professor asked us to program an Eliza-like chatbot, software that lets the user to discuss with a computer. He joked "the perfect language for chatbots is Perl, but you won't learn a new language just to write one program, will you?". I did: I was fascinated with the idea of learning a new language just to finish a university assignment, and I learnt Perl and finished the chatbot (including documentation) in 3 days. Now I published it under a permissive licence (BSD-like) and you can download the complete source code.
Right now I am working on my B.Sc. individual project and dissertation, doing research and evaluation of modern content management systems and wikis, as well as developing my own wiki-CMS, and I intent to release it to the libre software community too.
I encourage all students and employees to publish your work under libre licences, such as GPL, BSD or Creative-Commons, if this is allowed by your university or employer.
I can't imagine that coupon promotion cost analysis is not open to reimplementation.
....
Perhaps the specifics of your project are in-house but I'd have thought that it was readily adaptable for other users. I'm not clear which side of the equation you're on [nor what the equation is] but coupons to promote sunday magazine sales and/or magazines sold on sundays with coupons in are not unique to a single company. If you widen the field to coupons in publications in general you're looking at a vast array of companies/groups.
So the answer to the original post is "our shareholders want oodles more money and so we don't give away our precious software". Nevermind the analysis of that statement
They call it 'reason', where's the logic in that!
My experience is limited, but here in UK [at least until a couple of years ago] Uni's have very strict limits on student IPR (Intellectual Property Rights).
Dissertations, and often any IP produced by students in the course of their study belongs to the Uni (don't know how enforceable it is but I had to sign a waiver of rights as part of my matriculation process).
Do you have the relevant rights to GPL your software???!
Yes, it sucks.
Recently, though, there was some functionality I wanted added to ClamAV, an open-source virus scanner. Basically, I wanted to make sure the milter was running. So, I wrote clmilter_watch, a tool to monitor the functionality of clamav-milter. Of course, I don't trust my own programming skills enough to know if it's stable for production use. So, it gets released to the world. A few downloads later, I get a couple of suggested patches, and the thing is pretty solid. Everyone wins.
On the other hand, if you're the *first* company to develop $INTERNALAPP (or the processes/procedures/workflow $INTERNALAPP embodies) and $INTERNALAPP facilitates significant improvements in productivity, etc, then $INTERNALAPP most certainly *does* give a competitive advantage. This sort of scenario is an *excellent* reason not to open-source an internal piece of software.
I'm a strong proponent of open source both in concept and in considering open source solutions at the Fortune 200 where I work as a technology strategist. However sometimes you really have a hard time selling some of the less enlightened at a big company on the merits of fully opening a project.
In case anyone interested in this subject hasn't checked them out before, you might want to read up a little on Avalanche, a consortium which provides a slightly less open but slightly more palatable (to resistant PHB's) option for corporations looking to experiment with sharing IP.
http://www.avalanchecorporatetechnology.net/
I know the question was about open sourcing a corporate project, but I thought this might be relevant to mention because the idea came up constantly when the subject was broached of opening up a major platform product at our company. Sadly, in the end, neither the shared source or open source model was chosen.
The good news, though, was that the decision was made to continue the life of the project in question and in fact port it to Linux, rather than replacing it with a costly COTS solution - so at least it was a partial victory for the "clueful" involved.
I am currently consulting for a large drug company; I was asked to help evaluate and deploy a small firewall device to protect networked diagnostics equipment at customer sites. The device had to be
-small
-cheap (less than ca.$250)
-robust
and a whole slew of other qualities, including having to work in an environment where ca. 3,000 boxes could be easily managed individually, by non-technical field service staff (as there's no chance of central management access to customer nets.)
We settled on M0n0wall running on a PCEngines WRAP board, after evaluating a pretty extensive number of commercial and a few open source products or packages.
I was really impressed by the openness that this (mainly Microsoft) shop showed towards this sort of thing--I encountered none of the "but if it's proprietary it's more secure" or "if it's proprietary, we have someone to sue" garbage you often get from management. There are good reasons to pick commercial, non-open software products, but these are entirely dependent on the companies that sell them.
In addition, what I really appreciated about this client was their willingness to put the developer on retainer while he finishes his studies, and to kick him some cash for time spent making changes, 3rd level support, etc. The guy who wrote M0n0 is a really superb and bright individual, and it's great to see a large company sponsor such people (plus it's costing them absolute peanuts.)
Cole's Law: Thinly sliced cabbage
Ant Tasks for AlienBrain was something we needed in-house, but realised would be generally useful. After a debate with my boss, we got clearance to release.
OK, it's not the GIMP or anything, but every little helps...
Sean Ellis
Follow OfQuack's antics on Twitter.
My company has a standard clause in our independent contractor agreement that allows us to specify whether ancillary projects will be undertaken by the client, who will then pay for the development and own the rights, or by my company... which then does the development "off the clock" and owns all rights. (The definition of an ancillary project is complex, but it's essentially anything that isn't part of the core functionality and can still work reliably without that core.)
The concept here is that if we come across something that would be better shared than hoarded, we can share it -- either by sticking it in a box and selling it, or by taking it open source. We draw the line based on whether we think people will buy it. (Hey, we're a business. Piss off.)
The upshot, however, is that our ancillary projects tend not to be very useful to anyone. Not only do we not think people will buy most of them, we don't think people will USE most of them. So the vast majority of the time, we look at something like our skinning and template engine, and we say "even if you *did* need this, you could write it yourself in less time than it would take to find the project". (Literally, it's about twenty lines. Not interesting at all.) We may at some point release something along the lines of Bob Stout's SNIPPETS, but that's about all we're likely to do.
In the end, our ability to release open source projects is hampered by the narrow focus of our tools. They have such limited functionality and flexibility, they're just not going to be applicable to most people's needs. Even when we took our web site's back end and branded it "Alatar CMS" for release as an open source project, we had to admit it's just plain not ready for general use. At some point, we're still going to clean it up and release it, but we're just not ready to invest time in that yet.
Microsoft cheerleader, blue flag waving, you got a problem with that?
No, what happens is that B,C,and D are going to spend the exact same amount of money to close the gap. After that, nobody has a competitive advantage, because they all have the same order processing ability now. This is the whole point of Nicholas Carr's book by the way, "IT Doesn't Matter".
So maybe A,B,and C should collaborate on an order processing system, then D's left out of the game. Except then D would sue A,B,and C for anti-trust violations and win the cost of the order processing system plus punitive damages. Bottom line - companies are supposed to compete, not collaborate.
So then maybe A,B,C, and D should all buy the order processing software from the same company, and that company could spread the costs across it's customers. Well, they do, and it's called SAP. But SAP spends $1.2b on R&D a year, so I don't see them giving away their stuff for free.
Tristan Yates
Simple logic :
: :)
1) You have paid internally to develop that tool, so you have spent, let's say 5000$, more than you competitors
2) The ones who may probably take a greater advantage from your sw are your competitors, to whom you are already behind of 5K$
3) Under most common OSS licenses your competitors are not even obligated to release their modified version, since they do not distribute it (for personal use you can keep the source under GPL for example)
4) You risk giving away hints of your secrets : I don't think every firm evaluates coupon promotion costs the same way and you are giving away your formula which may or may not be something powerful in the competitors' hands.
5) The sw should probably be cleaned up before publication and this is a loss of time
6) Even if the released sw gets publicly modified by someone (probably your competitors) you hardly gain something from it, since if you don't have some features probably is because you didn't need them in the first place.
7) You can forget concepts like "many eyes mean less bugs".. sometimes someone still finds and exploits bugs in firefox (used by millions of users).. do you expect so much code inspection from your "3 possible users in the world" software ?
8) In the end, you may or may not lose something but you surely gain nothing at best.
Nitpick
The only one advantage is that you might be able to find a new employer who worked for your competitors and already knows your software! But that employer will easily cost more (knowing your software he will ask for more money!). And for this fact your own developers are discouraged to open source their own software, since by doing this they lose "power"
A example of a small, but useful open source project that started as an internal project:
;)
JavaConfig. It allows easy and type-safe access to configuration properties, for Java based applications.
My previous employer, Chess in Haarlem, the Netherlands, agreed to make it Open Source (under a BSD license) after me and a few other colleagues had been working on it for a while. Proves that it's a cool company