I deployed an open source solution in a large corporation in what was considered a fairly non-critical situation first. Big corporations usually want to do business with other big corps.
Our problem was that we had a few laptop users coming into the building every once in a while from someplace else in the company and they were tired of all the changes they would have to make to their systems to work on our network (we were static IP). So, we pulled an old 486 from a storage room just before it was donated to a school and installed Linux and set it up as a DHCP server. We didn't want it on our production systems because they were old and we didn't want to put on the extra overhead. After the solution had proven itself for a few months, everyone moved to DHCP and we upgraded the hardware to a P120 and everyone was happy. No new hardware to support the new OS purchase. No need to go and do maintenance on the server since it would stay up. The only costs were my salary while I built the system (3-6 hours since I was still learning my way around) and the electricity to run the box (no monitor because everything was done via telnet).
Another group in the company was using a RedHat system as the corporate bulk mailer. I didn't like the idea our company was into that kind of thing, but it made sense to use Linux for it.
The point is that corps. will always want someone major to back their critical systems. They are also more conservative that individuals or small companies. They don't like risk and don't want to be the first to put their business into the hands of something they don't know about. Concentrate your paper on how non-critical systems/products can be shifted over to OSS at a lower price. The fact that major corps are embracing OSS is something you might want to mention, but until more depend upon it, most corps won't go that direction.
Actually, I would suggest no tuning done for the non-expert class testing. Just straight out of the box with all defaults. Install any patches the distro and Windows may have and leave it at that. That is probably a more accurate test on the non-expert.
If you start to include the learning curve of the individuals, you add too many variables to the testing and muddy the results.
Also, you might want to limit the tuning time for the experts. A single 8 hour period from start of install to completion of task. You can spend all the prep time you want planning how to tune it. Just limit the amount of time on the box. Most places I've been at say they want the server running within a certain period of time. I don't have as long as I would like to tune the box once the hardware has arrived.
Slashdot Mirror
Our problem was that we had a few laptop users coming into the building every once in a while from someplace else in the company and they were tired of all the changes they would have to make to their systems to work on our network (we were static IP). So, we pulled an old 486 from a storage room just before it was donated to a school and installed Linux and set it up as a DHCP server. We didn't want it on our production systems because they were old and we didn't want to put on the extra overhead. After the solution had proven itself for a few months, everyone moved to DHCP and we upgraded the hardware to a P120 and everyone was happy. No new hardware to support the new OS purchase. No need to go and do maintenance on the server since it would stay up. The only costs were my salary while I built the system (3-6 hours since I was still learning my way around) and the electricity to run the box (no monitor because everything was done via telnet).
Another group in the company was using a RedHat system as the corporate bulk mailer. I didn't like the idea our company was into that kind of thing, but it made sense to use Linux for it.
The point is that corps. will always want someone major to back their critical systems. They are also more conservative that individuals or small companies. They don't like risk and don't want to be the first to put their business into the hands of something they don't know about. Concentrate your paper on how non-critical systems/products can be shifted over to OSS at a lower price. The fact that major corps are embracing OSS is something you might want to mention, but until more depend upon it, most corps won't go that direction.
If you start to include the learning curve of the individuals, you add too many variables to the testing and muddy the results.
Also, you might want to limit the tuning time for the experts. A single 8 hour period from start of install to completion of task. You can spend all the prep time you want planning how to tune it. Just limit the amount of time on the box. Most places I've been at say they want the server running within a certain period of time. I don't have as long as I would like to tune the box once the hardware has arrived.