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?"
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.
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.
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.
"Why would we give it away for free?"
Perhaps because you're not a software company?
OSS is a barter system. Many give things away not because they are Jesus, but because they want something in return.
For example, if the software is some fantastic cost accounting system, for example, and you release it, other contractors could "squat" on the code, and make their own competitive businesses supporting it. Then you would have some choices about outside contractors to go to when you need extensions.
Also, you may get bugfixes, and other contributions from the community of contractors and users.
-- John.
No, what he's actually saying is that at most companies somebody will say "could this possibly benefit our competition?" and at that point, the idea will die.
Whether or not there is an opposing viewpoint, and whether or not it is correct, is immaterial. In most companies, if the people in decision making capacities think that there is any chance that open sourcing something they've written could help their competition (yes, even if it increases their own benefit as well), they just flat won't do it.
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