Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Businesses Programming IT Technology

How Often are Internal IT Projects Open Sourced? 55

Posted by Cliff from the enlightened-business-entities dept.
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?"
This discussion has been archived. No new comments can be posted.

How Often are Internal IT Projects Open Sourced? More

How Often are Internal IT Projects Open Sourced?

Comments Filter:

  • Most are reimps? (Score:5, Informative)

    by VultureMN ( 116540 ) on Tuesday April 05, 2005 @06:57PM (#12148898)
    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?
    • 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 compa
      • 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
    • I'll second this. I've worked in several different industries, and I doubt that *most* software is just a reimplementation.

      I wrote a geographical revenue analysis program for a big three long distance carrier that took data from a mainframe and mapped it on a desktop.

      At another place we collected documents on tobacco litigants. We wrote an app that managed the investigation including document sources, cases, and scanned images.

      To say that most internal apps are just reimplementations of what other compa

  • Anecdote (Score:4, Interesting)

    by RomulusNR ( 29439 ) on Tuesday April 05, 2005 @06:57PM (#12148899) Homepage
    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 [sourceforge.net], 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.
    • 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.

      And they will really appreciate that small favor when the support calls start coming in.

    • Re:Anecdote (Score:3, Interesting)

      by drsmithy ( 35869 )
      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.

      I find it amazing you look on something that should have been an assumed inclusion - a basic acknowledgement of who was responsible for having the software developed in the first place - as a "favour".

      • I don't think it's entirely as clean cut as it seems -- I wasn't asked or ordered to develop it (I'm QA, not development); I saw the need for it to do my job, not being able to find a suitable alternative, and went ahead and did it on my own. But I only developed it to the extent that was warranted by my responsibilities and job expectations.

        As for mentioning the company, I quite likely would have done that anyway.
    • 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[...]

      Agreed. My experience is that businesses feel very proprietary about software that relates to what the business does for money, but rarely give a damn about library code or generic tools once you explain the distinction.

      It also helps if your bosses already know that you're using a number of open-source tools or libraries, and if they hear about it when you submit
    • Being a tester I am always interested in new test case management software. When are you going to open the source for yours?

      (no files in sourceforge, apparently)
      • It's all in the CVS at the moment. I'm holding off on progress right now until I can acquire a place with the required MySQL 4.1 for a demo site.

  • Open source software (Score:1, Insightful)

    by Anonymous Coward
    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.
    • There is a "software co-op" called Avalanch [avalanchec...nology.net] that allows companies to share software. For the reasons you describe above, I'm not sure if it has much of a chance of success. It's sort of a open source, but open only to members.

  • In my experience... (Score:5, Insightful)

    by torinth ( 216077 ) on Tuesday April 05, 2005 @07:05PM (#12148956) Homepage
    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.

    • Re:In my experience... (Score:4, Interesting)

      by Artega VH ( 739847 ) on Tuesday April 05, 2005 @07:48PM (#12149273) Journal
      I'm the author of one of those "monstrosities" you're talking about. Initially I was embarrased to hypothetically release it but then I realised that almost all of the projects on SF simply don't work as well as my hack does. If my app was released onto SF I'd consider working on it from home too which is something I will NOT do if its just at work...

      My application is a web based timesheet program. The only part I'm "proud" of is the pdf timesheet generation. Other than that the application runs, with almost zero maintenance (occasionally a strange bug pops up on average once every three months). The part I'm least proud of is the interface which looks worse than slashdot.. and the code that generates it has SQL, PHP, and php generated javascript all in one file (ie a total mess). It is reasonably well commented though since I've had to have other people working on it. Oh the database sucks too since it was converted directly from an excel sheet its pretty much one huge table... whoops..

      My feeling is getting the company to actually release its previous IP freely unto the world would be an uphill battle. Maybe there is a different culture in other companies but mine is heavily protective and risk adverse in that sense.
      • I have a similar timesheet monstrosity. People punch in and out each day by tapping on their photos on a touch screen and entering their code in the keypad that pops up. It tracks locations, vacations, overtime, attendance, and lunch. It keeps dual logs, one permanent, the other editable by a manager. It can store custom forms linked by employee and date, where the manager only needs to write an html version of the form and upload it. It has a message board, with personal message support. Hours are verified
      • You (and the guy who replied to you) should check out Journyx Timesheet [journyx.com].

        It's free (as in beer) for 10 users or less. It's not open-source itself, but it's built on open-source stuff such as Python, Apache, and Postgresql.

        A new version is coming out soon which has a much prettier CSS interface than the current version.

        And yeah, I am biased because I am the senior developer at the company.

    • I wrote several of these "monster" tools that you speak of. I work at a conglomerate with international offices, and it turned out all of these tools ended in the hands of users throughout the world. Since I have no time to support the tool for everyone from India to Europe, the users often tweak the source themselves (it's included in the distribution zip). I would often find my networking libraries embedded in other people's tools afterwards. So...open source, but at a local level may work at some compani

  • Your question seems a bit confused... (Score:3, Interesting)

    by HotNeedleOfInquiry ( 598897 ) on Tuesday April 05, 2005 @07:08PM (#12148984)
    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.
    • 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.

      Yes, but consider it the other way around, because your company had to write it, it costs your company to write and maintain it. So what you are actually saying is that it is better for companies to spend more writing and maintaining multiple toolsets than to get together and write one between them.

      Remember that since they are the competition, they

      • So what you are actually saying is that it is better for companies to spend more writing and maintaining multiple toolsets than to get together and write one between them.

        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

    • When management is aware of how much benefit their projects have received from being able to make use of other people's open source projects, I've found they're receptive to open sourcing internal tools that have been built that are not part of the company's core competency.

      As an example, we've built some C++ classes to abstract shared and exclusive mutexes, including scope objects that acquire a lock in their constructor and release in their destructor to provide better exception safety and simplify code

    • Companies typically use a lot of software that has nothing to do with the business model of the company.

      For example, if I decide that no CMS out there does what I want to do for the best arrangement of the company's Intranet, I might go ahead (if I have the cycles, or I am lucky enough to work for a "20% percent" company, or a "blue time" company, or can otherwise defend the time/effort, etc.) and start putting together a CMS that does what I want. But this is for a company that sells hot dogs, not CMS's.

  • We sell our source. (Score:2, Interesting)

    by Oz0ne ( 13272 )
    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?

    • Re:We sell our source. (Score:3, Insightful)

      by jhoger ( 519683 )
      "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
      • Also, you may get bugfixes, and other contributions from the community of contractors and users.

        Except not even the GPL would require anyone in the community that is using your code inhouse to give you back any code - so you have gained nothing, except maybe giving a competitive edge to your competitors. If your app really is worthless, then sure give it away - but then, why did you waste your time and effort on it.

        • Re:We sell our source. (Score:3, Interesting)

          by jhoger ( 519683 )
          Someone using your code and not giving anything back does not really cause you any kind of loss 0 - 0 = 0. So, No impact.

          But if someone improves your code and releases it (contractors, for example, or anyone who understands and participates in this barter system) you can take advantage of that. That's a net gain. The GPL doesn't require release of source unless you redistribute binaries or source. But the GPL has real teeth, due to the fact that software is quite often distributed. And even when the GPL do

        • Except not even the GPL would require anyone in the community that is using your code inhouse to give you back any code - so you have gained nothing, except maybe giving a competitive edge to your competitors.

          While no law or contract requires it, the social mores of the free software communuty strongly encourage it. Mores can sometimes be stronger than laws. Even profit-monster corporations can be influenced by them, as potential customers and employees will make decisions based on whether a company is

          • Employee will probably prefer to close source their work as much as possible. If a sw is open sourced there could be much more programmers out there knowing how your internal software works and this deevaluates the value of your programmers. For example you can refuse a raise to a programmer, since even if he decides to go away you have plenty of other programmers who already know your sw. So cunny employees will not insist on giving away their changes if possible.

            • For example you can refuse a raise to a programmer, since even if he decides to go away you have plenty of other programmers who already know your sw.

              Security by obsurity doesn't work for job security either.

              Clueful employers value developers whose code is easy to work with. If other programmers can't figure out your software because you're deliberately writing obfuscated code, it's time to fire your ass and have it re-written.

              Smart developers understand that if other people can't take over their co

  • CGI::Prototype (Score:5, Insightful)

    by merlyn ( 9918 ) on Tuesday April 05, 2005 @07:15PM (#12149050) Homepage Journal
    My CGI::Prototype [cpan.org] application framework started as an IT task for a large university I have as a client.

    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 giv

  • Too many problems (Score:3, Insightful)

    by StarWynd ( 751816 ) on Tuesday April 05, 2005 @07:48PM (#12149272)

    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.

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

      That depends a lot on the code you release. There are companies that I've done business with solely because they released some open-source code that got me interested in what else they could do.

      Aside from the advertising benefit, I generally find it nicer to deal with companies who get the whole open source thing. They often have a positive-sum view of the world t

  • I open-source my university assignments (Score:4, Informative)

    by wikinerd ( 809585 ) on Tuesday April 05, 2005 @08:46PM (#12149676) Journal

    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 [wikinerds.org].

    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.

    • 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.
      • That's true, though there are two easy ways to get your code GPLed:

        1. Extend an existing GPL project. Since it remains under the GPL the university will have no real reason not to just release it back onto the Internet.

        2. Ask. After completing my university project I asked if it could be released LGPL to the world. A forms and a signature later, it was. Universities claim IPR on projects as a precaution but for most projects they won't stand a chance of making any money, at which point they'd genera

      • In the US, undergrads have complete rights to whatever they create(provided they actually created it) because they paid the tuition to go to the school. However, most grad students who are given a tuition waiver and a stipend have to sign an agreement that basically states whatever IP they create during their time at the univerisity belongs to the university, sucky tradeoff, but when has grad life ever been glorious?
    • finally! someone who understands the essence of libre!

      I've been releasing my shit under the GPL license for years. Sure, some close minded, closed source assholes complain that I don't flush the toilet. Or that it isn't sanitary to take a dump in the sink. Well fuck them! Open Source forever!

  • My own experience (Score:5, Interesting)

    by menscher ( 597856 ) <menscher+slashdotNO@SPAMuiuc.edu> on Wednesday April 06, 2005 @01:05AM (#12151270) Homepage Journal
    I don't consider myself to be a programmer, just a sysadmin. We use lots of open-source software on our machines, but don't really have funding to contribute to the projects. So, I give back in the form of answering questions on mailing lists, submitting patches, etc.

    Recently, though, there was some functionality I wanted added to ClamAV, an open-source virus scanner [clamav.net]. Basically, I wanted to make sure the milter was running. So, I wrote clmilter_watch, a tool to monitor the functionality of clamav-milter [uiuc.edu]. 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.

  • Er (Score:2)

    by drsmithy ( 35869 )
    Most internal IT products are probably reimplementations of what exists at other companies, and do not bestow any competitive advantage to the developing company.

    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

  • 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

  • Here's a Nice Example (Score:3, Interesting)

    by fuzzybunny ( 112938 ) on Wednesday April 06, 2005 @05:01AM (#12152062) Homepage Journal
    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 [m0n0.ch] running on a PCEngines [pcengines.ch] 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.)

  • Well, at least once... (Score:3, Interesting)

    by seanellis ( 302682 ) on Wednesday April 06, 2005 @06:49AM (#12152383) Homepage Journal

    Ant Tasks for AlienBrain [sourceforge.net] 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...

  • 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 co
  • Your question shows that you don't understand competitive advantage. If company A writes some software to improve order processing in their company, and nobody else has it, now they have a competitive advantage in the industry because they can process orders better than anyone else. Do you think they're going to just give that away to company B,C,and D within their industry? Yeah, right.

    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, n

  • A example of a small, but useful open source project that started as an internal project:

    JavaConfig [sf.net]. 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 ;)

Slashdot Top Deals

"May your future be limited only by your dreams." -- Christa McAuliffe

Close