Yale Switching To Gmail, Not Without Opposition
PwnSnake writes "While it makes sense for small (and large) corporations to move to Gmail, something seems amiss when a top private university decides to hand everything over to Google. Although most in that community seem to welcome the change, several organizations on campus have joined forces to call for a transparent process and get students and faculty thinking about the downsides of the switch. The problem is choice (users can already forward mail to Gmail; it doesn't make sense to force that option and not have a backup or opt-out mail server)."
God, I wish my university would do this. We have 40MB account limits and professors routinely send out 10MB worth of attachments. Sure, you can forward it all to gmail (and who doesn't), but don't forget to delete your mail off the university's shitty server once a week or you'll get everything bounced!
This game will waste your life. Don't clicky!
Whatever they decide to do, some people are going to complain. The gmail-based service lets people use POP and IMAP so they can use a different UI if they want. So you've got real flexibility, and a default UI that (in most people's opinions) doesn't suck. So... what was the problem again?
You're just making up what Google does with that data.
http://www.google.com/support/a/bin/answer.py?hl=en&answer=60762
I work for a higher-ed institution that's in the Big Ten. We recently provided GMail on campus, to all faculty, students, and staff. It was a remarkably easy transition for us to make. Here's how we did it:
Opt-in.
Really, that was it. We said, "Here's the GMail system that we arranged through Google and the University. If you want to move to GMail, please do - here's a link to make that happen. If you prefer to remain on the existing University email system, that's fine, we aren't taking that away and we're still committed in supporting the University system."
It's worked out well. As of last week, our overall adoption rate is 26% across faculty and staff (I don't have the student numbers) with several colleges and departments already at 100%. Overall, students opted in very quickly. Our outliers have been staff and faculty - this is likely because moving to GMail is a change, and change can be scary. (Note you can use the web interface, or access GMail using POP/IMAP.)
It's not entirely opt-in, though. Incoming students are not given an option - they'll be issued a University GMail account by default. The goal is that over the next 4 years, we'll gradually have all student accounts move to GMail automatically. (But as I said, students tended to opt-in very quickly.)
Maybe someone better informed than I could say whether or not if using Gmail corporate services would also expose you to randomly-applied 'great ideas' such as the screwup that is Buzz?
In a word, No.
When my university moved to GMail, the central IT folks get to administer the university GMail system. [Disclaimer: I work in our central IT, but am not part of the GMail team, although I am in the same overall unit.] That means the university central IT gets to choose what new add-ons our users get access to. So, central IT gets to be the gatekeeper for new stuff that appears in Labs, or new bolt-ons like Buzz. In our university, I believe we use a pretty vanilla GMail. This is (mainly) to help with support issues, but privacy concerns like Buzz probably play into this too.
Incidentally, it's the same with corporations that use GMail, IIRC. Except in that case, the corporation is paying $$$ to Google to be hosted on GMail. But the corporate IT staff still manage the featureset for things like Labs and Buzz.
Gmail does not implement IMAP standard correctly. I am aware of two currently existing problems (and there were more iirc): ENVELOPE response is occasionally misformed for more complex messages. Gmail sends EXPUNGE unsolicited responses when it is forbidden by the standard. Gmail sends the responses to some queries out of order - this behaviour is formally correct but is not what some IMAP clients expect. Still, many IMAP clients which use IMAP in a POP fashion and never - or rarely - encounter these problems. Try using a more sophisticated IMAP client which makes an effort to optimize the amount of transferred data and keeps long-lived network connections the way IMAP was designed for - and you will understand what the grandparent had in mind.