This week I’ve been testing out OpenGoo, an open source online office project that’s meant to provide a more open alternative to Google Apps.

Specifically, the code that comprises OpenGoo is freely accessible, and, as a plain old LAMP application, OpenGoo gets to leave the confines of its makers’ firewall and live in your data center, or desktop, or hosting service of choice.

As I’ve written in the past, I’m a big fan of Google’s Apps. However, I’m also a fan of reserving the right to fire any of your suppliers, and to do so, ideally, without disturbing adjacent layers of your stack: Swap Intel for AMD, IBM for HP, Xen for VMware, Red Hat for SUSE, Domino for Zimbra, and so on.

With something like Google Apps, every layer of the stack, all the way up to your data, is under Google’s control. Of course, that’s the point of SaaS–someone else manages and serves up the application, and you get to focus on taking care of business.

As I see it, the perfect application would be available in SaaS form, from multiple hosting providers, as well as in commercially-supported on-premises, and self-supported open source incarnations.

Perfection is a pretty tall order, but we’re starting to see open source Web applications that offer the sort of deployment flexibility that I’m looking for, even if they don’t nail all the features as well as do better-established online incumbents do.

OpenGoo is certainly not perfect, but the project is progressing at a promising clip. I’ll be keeping tabs on OpenGoo as it continues to develop. For now, check out my review and slide gallery of OpenGoo, and go demo the suite for yourself. I’d love to hear what you think of it — drop me a line in the comments below, ping me on Twitter or Identi.ca.

Next up on my review docket is another SaaS/on-premise/open source challenger in the enterprise application space: SugarCRM.

Brian Prince is reporting today that Google is considering enforcing SSL encryption by default for its Google Apps users. It’s a good idea–as eWEEK Labs’ own Andrew Garcia discussed recently, your on-the-go applications can have an awful lot to say about you.

In fact, enforcing HTTPS encryption for Google Apps by default is such a good idea that you shouldn’t wait for Google to implement it. Whether you administer a Google Apps domain or are an individual user of the service, you should enable the mandatory SSL (Secure Sockets Layer) encryption yourself, right now.

Here’s how you do it:

• Step One: Visit https://www.google.com/a/cpanel/YOURDOMAINHERE and log in.
• Step Two: Click “Domain settings” in the menu bar across the top of the screen.
• Step Three: Check the box marked “Enable SSL.”

• Step Four: Click the “Save changes” button.
• Step Five: Take a look at the General Settings page within one of your managed Gmail accounts, and confirm that your users have no choice but to connect via SSL.

If you’re a regular Gmail user, or if you have a Google Apps account without an established SSL connection policy, you can use this same settings page radio button to upgrade Gmail security on your own.

The best and the worst attributes of Linux as a desktop operating system involve acquiring and maintaining software applications. For me, the positives outweigh the negatives, making Linux the best desktop operating system option I’ve encountered, and the one I choose at work and at home.

If Linux is to pile up more desktop adherents, the vendors and communities that back the open-source platform need to work together to accentuate those positives and shrink down the negative aspects of getting and managing software on Linux.

The GOOD: Software packages are your friends

All the bits that make up a typical Linux distribution, from the kernel to the little applets on the task bar, are divvied up into software packages, each of which contains metadata about what its bits are supposed to do, where they came from and what other packages they require to operate.

As a result, Linux is modular enough to squeeze into all sorts of vessels, and to integrate code contributions from many different sources without becoming unmanageable. In fact, as long as you stick to software that’s been packaged up for your Linux distribution of choice, there’s no better platform for staying in control of what runs on your system.

In order to keep my Linux desktop up-to-date, I don’t have to spend my time clicking on a succession of different vendors’ system tray-embedded update applets, reiterating to Adobe, Apple, et al, that I still don’t want to install that Yahoo tool bar or take them up on that Quicktime up-sell opportunity.

The BAD: Linux and proprietary software don’t mix well (usually)

The desktop market share of Linux is pretty small compared to that of Macintosh or Windows, which tends to make the platform an unattractive development target for software vendors. Making things worse, Linux’s slender share is divided up between many different Linux distributions, many of which require different packages.

As a result, even those software vendors that do support Linux often end up producing script-based installers that work on multiple Linux distributions, but that leave these systems in a less manageable state by working outside of Linux’s various software packaging frameworks.

When you’re dealing with open-source software, the companies and communities that build Linux distributions are able to grab the source and package it up for easy consumption, thereby tackling the packaging and distribution work on behalf of the upstream developers. This doesn’t work so well with proprietary software, in part because the code is closed, and in part because volunteer packagers prefer to donate their time to free software projects.

There are exceptions, however. When I fire up a fresh Ubuntu install and cruise to YouTube.com, the system offers to download Adobe’s Flash Player, and when the inevitable security issues emerge, my proprietary Flash Player updates occur alongside all my free software updates, and there’s not an unwanted tool bar offer to be seen.

The UGLY: Open-source software gone wild

When the source code is freely licensed and available, it’s much easier for someone to package. However, someone still has to take the time to do the packaging–just because a given Linux distribution could offer packages for an open-source application doesn’t mean that the distribution will offer them.

Significantly complicating matters is the fact that it’s much easier to configure, compile and install an open-source application than it is to package that application. Sure, you have to install some development tools and root out various needed libraries, but it usually isn’t too tough to go from a source code tarball to a running application.

The ugliness accrues as you move forward, and parts of your system are updated without any regard for the dependencies of the roll-your-own open source apps living on your machine. When security updates for your self-compiled apps come down, they won’t get applied unless you keep an eye out for them, fetch the code anew, and repeat the configure, compile, install procedure. Forget about managing this process on multiple machines.

This is what gives me pause about Novell’s SLED series of Linux desktops, and their constrained selection of software packages. Why should we mess with unpackaged apps, or spend time packaging them yourself, when other options are available with much more expansive package catalogs?

THE WAY FORWARD:

1. Everybody Hug

Ubuntu is (and has been for a couple years now) my desktop Linux distribution of choice because Ubuntu offers a very large catalog of packaged and ready to install applications. Ubuntu owes its large application catalog, in large part, to the Debian project, which has been cranking out software packages on a volunteer basis for years now.

I’d love to see Novell and Red Hat figure out a way to work with the Debian project to reuse the packaging work that its members are doing to broaden the range of software packages available for easy installation. It would take some work to translate the Debian packaging efforts to work with Novell and Red Hat’s RPM-based distributions, but Novell already has a project underway capable of building packages for SUSE, Red Hat, and Ubuntu-based distributions.

2. Proprietary Apps are People, Too

No less important than maximizing the work that’s already being done around packaging open-source applications, it’s important that major Linux distributors make it easier for proprietary software vendors to package their wares for Linux.

I know that many in the open-source community have an allergic reaction to proprietary software, but if open platforms such as Linux are to realize their potential, they must host proprietary applications just as well as, and better, than proprietary platforms do.

Again, Novell’s OpenSUSE Build Service seems to offer a decent foundation for moving forward. While the OpenSUSE-hosted version of the service is limited to open-source software, Novell makes the service available for download and self-hosting, so proprietary software vendors could use this code to produce packages for multiple distributions, particularly if Canonical, Red Hat and other Linux vendors began pitching in to help streamline the process.

3. Write Once, Run Anywhere, for Real

Considering the chicken-and-egg issues that desktop Linux faces regarding the relatively small market opportunity it offers to ISVs, I find it surprising that distributors haven’t put more effort into advancing the state of Web application delivery and management on Linux.

I’m a heavy user of Google’s hosted mail service, which I run within a site-specific browser, Mozilla Prism, in order to protect myself from evil-doing scripts that might take advantage of the sorry state of inter-tab isolation in most of today’s Web browsers, and to isolate my mail session from things such as runaway Flash ads adjacent browser tabs.

As far as I’m aware, however, Ubuntu is the only Linux distribution with a ready-to-install package for Prism. What could be more enterprise-appropriate (I’m looking at you, SLED) than providing for isolation between running Web applications? And more than simply packaging Prism, or something like it, why don’t any Linux distributions employ one of their built-in privilege management frameworks, such as SELinux or AppArmor, to offer enhanced Web browser isolation right out of the box?