Why make BILLIONS when you can make...millions!?!? Bwa-ha-ha-ha-ha!

Don't they know men give up the first amendment right to free speech the second they get married, if not months or years ahead of time. Particularly when the mother-in-law is in town.

What....too soon?

The prerequisites to making the switch is first and most importantly having an appropriate business case for OLAP. The second prerequisite is that you've tried doing analytics in a traditional RDMS, perhaps jumped on to the NoSQL bandwagon, and you've failed at it (i.e. success for a little while but then your data eventually brings your queries down to its knees). Don't worry, failure isn't necessarily wrong, it's just you and your team needed the experience before you could make the next leap.

The risks are a knowledge jump in to an OLAP mindset from a traditional SQL mindset. Invest in you and your fellow developer's knowledge. Push back on management and sales when they want more immediate results and let them know that it will take 3-5 months to replace your current system. Do your proper technology evaluations. Learn FoodMart and Adventureworks and let them guide you down the path of good fact and dimension design. Don't snub your nose at Microsoft as they absorbed the company in the 80's that basically pioneered this stuff and made billions, but also don't take their stuff too literally as there are several products out there and some that do things better.

Read The Data Warehouse Toolkit thoroughly and practice using Mondrian which is an open source Java OLAP engine that can sit on top of PostgreSQL, MySQL, and others. Find a good ETL tool rather than trying to write your own at first and don't be afraid to force your internal users to use this tool to create their facts. Don't worry if you don't get it the first time, but keep trying and keep discussing with your fellow developers as it takes a team to work out all the kinks. Later on you'll probably end up seeing how you did things wrong, but hopefully you can get most things right in the beginning.

It is not very often that a company gets software designed for exactly what their needs are. Put together a decent package, i.e. licensing terms, costs (licensing and buyout), feature list, benefit comparison, maintenance fees. Spend the time and put together an LLC (sole proprietorship would likely be a little too risky in this instance). Don't be lazy and put it in to a nice professional looking folder. You'd be surprised how differently people respond when they receive something that shows some effort and professionalism compared to some guy saying "hey I've got this thing, you want it then give me money". The best part is they already know you and know the quality of your work rather than the line of some sleazy sales guy.

Lastly, don't expect them to buy. Just because you see the need and it may be the perfect product for the company you work for doesn't mean they will want to buy it. At least you will provide a view of a compelling product and you're giving them the opportunity to consider things in a format that they are accustomed to and gives your supervisor something more tangible to give to his/her higher-ups. Don't nag and be sure to do some follow up in 2-3 weeks if you haven't heard anything from them. If they indicate they're not interested, don't bother pursuing, but if they say maybe or better just hold the line and keep following up every 2-3 weeks. Sometimes other cogs in the organization have to spin before a decision can be made and that can take time.

Also don't be unwilling to negotiate. Perhaps you can show them the maintenance fees and say that you'd be willing to waive them with a minor change in job description that fits the necessary duties and a modest raise to make up for the difference in cost (perhaps that raise matches the amortized maintenance cost over a 12-month period...) which would also allow for performing maintenance and minor feature improvement during normal working hours.

Although I wholeheartedly agree with all the people who are going to recommend Unity (which is also the platform I prefer), you might be better served with UDK when demonstrating to students. I'd say that Unity is a 3d game engine/platform made for programmers whereas UDK is a 3d game engine/platform made for level designers with support for programmers. You can get a lot of mileage from both platforms without much programming, but UDK is specifically designed so you can create an entire game without one stitch of programming (i.e. Jazz the Jackrabbit).

Also, I highly recommend the free training videos from 3dbuzz, here are the ones for UDK and here are the ones for Unity.

I guess you've never heard of Gentoo...

Somebody reverse Carmack's Reverse and put it on a tshirt!

Since you're such a low UID I'll bother answering your question.

I had already thrown out OCFS2 and GFS2 as possible candidates, but that was irrelevant to my reply. Also currently I am unaware of any non-proprietary hardware or software RAID (mdadm in particular) that supports active/active or active/passive on a shared backplane at any RAID level other than 1 or 0 (i.e. DRBD) and rather expensive and not yet released Areca external RAID controllers. Also I'm looking for whitebox OSS solutions.