Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
GNU is Not Unix

Is There a Need for a GNU Lobby? 11

Anonymous Coward writes "Data Warehousing is a field in which you dump data from a lot of different databases, transforming it in some way and load it in a new, business-oriented database. Somewhere along the way, you need to transform a HUGE load of data, and there are VERY expensive copyrighted tools that 'help' you do so. While working on a job for a client, we developed all of the transformation process using GNU tools (SunOS 5.6 and a nice E10K machine, if you want to know!) and found out that it was MUCH faster and even cleaner than with the particular transformation tool that we were 'supposed' to use. Our client (a big bank...) went berserk and started talking about 'lack of support', especially since the management had already bought the other tool and paid $200K for it, so they didn't want to look stupid. What they did was pay for the redevelopment using their transformation tool, only to find out in the the end that the process was taking 20 hours longer (approx 5x increase!) Now that we are going back to the original solution, I am thinking about what arguments I could have used 6 months ago(!) to prevent this? Maybe there is a market out there for consulting companies that offer GNU/Linux support and can reassure the management about these solutions?"
This discussion has been archived. No new comments can be posted.

Is There a Need for a GNU Lobby?

Comments Filter:
  • Ah, you've never worked for bank executives, I can tell from your invalid assumption that because they are executives, they must be adults.
  • by PD ( 9577 ) <slashdotlinux@pdrap.org> on Tuesday June 05, 2001 @03:53PM (#173607) Homepage Journal
    You want a gnu in the lobby? What's wrong with the parking lot?
  • Try documenting how actual support incidents worked. Have they had occasion to use the support on the other package? Did it work? What about with your open package?
  • What was the difference in development time like? and how experience was your team at using the packaged ETL tool?

    If things work the way they're supposed to, development with the packaged tool should have been significantly shorter. Reducing development and maintenance time is really the only reason to buy a packaged app over developing your own. Of course you can build a better solution on your own because it will be taylored specifically for your situation.

    Packaged applications have to be generalized enough so that people in dozens of different industries, using dozens of different data sources and target systems can build a solution quickly. The result of these compromises is a slower, but more generally marketable system.

    I'm with you on using GNU tools to develop solutions internally, but if the company has already made an investment in a packaged solution, it's just all that much more difficult to convence them to throw that money away and spend a longer period of time just to build a solution that performs faster. If 20 hours were fast enough, why spend all the extra time building a solution that so significantly exceeds the requirements. Remember that you shouldn't necessarily do something just because you can.

    The business world and it's rules suck... but they also are the one's who pay the electricity to keep that computer on.
  • by bellings ( 137948 ) on Tuesday June 05, 2001 @04:17PM (#173610)
    Ok... I don't understand this at all. One of your clients only wants to use supported tools and is willing to pay tens or even hundres of thousands of dollars for support. At the same time, you have a fast, flexible solution that works, you have all the source code for that solution, you have every legal right to use and modify the source code for that solution, and you have the knowledge and ability to maintain that solution.

    So why are you asking us what to do? The answer is simple -- sell your clients a support contract, and support the tools yourself. You have the source code -- what the hell do you think it's for?
  • I suspect that the reason is because since the tool was developed in house, there is no guarantee that anyone on the outside will be able to pick up where you left off if the client decides to dump you.

    Not an issue if the OP releases his tools as Open Source.

  • Maybe there is a market out there for consulting companies that offer GNU/Linux support and can reassure the management about these solutions?

    Just point them to slashdot. Just make sure they're browsing up around 3 or so. ;-P

  • One thing that tends to increase even PHB acceptance of software is support, which in turn tends to come with more widespread use, which tends to result from positive publicity. So how about a little publicity: which GNU tools did you use, and how? "GNU tools (SunOS 5.6 and a nice E10K machine if you want to know!)" dubiously implies that SunOS, a proprietary OS, was your GNU tool.
  • Big companies are not likely to get support contracts from little startups.

    Support is kinda like insurance. Most people wouldn't get insurance from companies that are just starting out and don't quite look ready yet.

    Let's face it - Redhat is a pretty big company, but you don't see a mass stampede to Linux in the business world. (Although some business have seen the light - that's nice.)

    No one wants to make a mistake. It's their jobs on the line, after all.

  • by Pogue Mahone ( 265053 ) on Wednesday June 06, 2001 @02:08AM (#173615) Homepage
    Our client (a big bank...) went berserk and started talking about 'lack of support', especially since the management had already bought the other tool and paid $200K for it, so they didn't want to look stupid.

    Here's the answer, you provided it yourself. They spent a lot of money on the tool and didn't want it to look like a complete waste of money to their PHBs - so they insisted that you used the expensive tools.

    However, after discovering that the expensive tools really were a crock'o'shit, they decided to cut their losses and save on the (no doubt equally expensive) upgrade/maintenance treadmill.

    Unfortunately, it actually takes a complete disaster before people with this kind of mindset will come to their senses - and sometimes even a disaster doesn't work. How many people do you know that expect the next version of [insert pet hate here] will somehow fix all their problems with the current version, despite the fact that all the previous versions haven't shown any likelihood of doing so? This is just the same optimism, but on a corporate scale.


  • by ryants ( 310088 ) on Tuesday June 05, 2001 @03:48PM (#173616)
    I'm interested in knowing, How did the suits find out?

    Anyway, more to the point, support for GNU stuff already exists to a limited extent. You can buy support from Cygnus for gcc/gdb. You can buy support from RedHat for their distros and most of the stuff included therein. Cyclic supports CVS.

    And I'm sure there are numerous little startups out there that I don't know about that are getting into this... or maybe they don't exist, and there's a business opportunity for ya.

    Ryan T. Sammartino

"I have not the slightest confidence in 'spiritual manifestations.'" -- Robert G. Ingersoll