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.
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.
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.
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.