Build an open source and Web 2.0 sandbox

Open source and Web 2.0 technologies are often appearing in enterprise environments as “skunk-works,” unauthorized projects that rapidly gain popularity.

Tools such as wikis, blogs, content-management systems and discussion forums can be found in many enterprises, despite the lack of official support or sanction. Just like e-mail in the last decade and IM more recently, these technologies are discovered by users outside the enterprise and brought into the enterprise incrementally and without planning.

Some companies are inclined to prohibit or even block these technologies, often with little success. As with e-mail, wireless and IM in the past, most companies eventually realize that the attempts to block technologies that users want to use only lead to uncontrolled deployments, which increase the risks and decrease the benefits.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Open source and Web 2.0 technologies are often appearing in enterprise environments as “skunk-works,” unauthorized projects that rapidly gain popularity.

Tools such as wikis, blogs, content-management systems and discussion forums can be found in many enterprises, despite the lack of official support or sanction. Just like e-mail in the last decade and IM more recently, these technologies are discovered by users outside the enterprise and brought into the enterprise incrementally and without planning.

Some companies are inclined to prohibit or even block these technologies, often with little success. As with e-mail, wireless and IM in the past, most companies eventually realize that the attempts to block technologies that users want to use only lead to uncontrolled deployments, which increase the risks and decrease the benefits.

How can a company experiment with these technologies without spending too many IT resources? Many excellent tools and platforms (both Web 2.0-ish and more “traditional” apps) are available under open-source licenses and built by developer communities (some examples include TWiki, drupal, Zimbra, Alfresco, phBB, SugarCRM, etc.). But building a test bed for these tools can take a lot of time and effort. Corporate IT engineers may have to move beyond their comfort zones and expose themselves to unfamiliar application stacks, operating systems and programming or scripting languages. Is it worth the effort just to try these tools out?

One possible approach is to create a flexible “sandbox” where corporate IT can build small pilot deployments of different applications for testing and evaluation. Let’s say for example that the PR department is willing to try out blogs or wikis for a new campaign. The IT department can deploy some software in the sandbox to allow for some experimentation on a smaller scale.

Building such a sandbox can be easier if companies use open-source tools and virtualization software combined together. Many software vendors and developer communities are now releasing their “wares” as virtual appliances either for VMware or for Xen. Bypassing the cumbersome OS build, customization and fine-tuning, IT engineers can just drop a virtual appliance on a SAN or NAS, boot up a blade server and have a test application up in minutes. By connecting to corporate LDAP or AD directories, IT can quickly enable access controls, user accounts and groups and have the test project ready for experimentation in a matter of days if not hours.

Here are some considerations for your sandbox:

* Make sure the sandbox is a secure environment. Prototypes and skunk-works projects may lack the security controls you would employ in a full production environment. Make sure there is adequate authentication and access control, if necessary by deploying proxies or firewalls around the sandbox.

* Set clear policies and expectations. Users may dive in and start using your sandbox for serious work. Make sure that you communicate the expectations of acceptable use and service-level guarantees (or lack thereof). At the same time be careful not to choke off new paradigms by making the policies too strict - for example, putting edit controls on a wiki defeats the whole wiki paradigm.