Time was when most enterprise software came in the front door as part of a formal, signed-off-at-the-highest levels procurement process. Or it got written in-house as part of an equally formal, multi-year development plan. Or some combination of the two. You didn't expect that expensive packaged software you bought to just work out of the box did you?
Lots of software still gets purchased and developed that way of course. However, the truly striking story of the past decade is how so many of the tools and other software that we take for granted today are essentially bottoms-up phenomena. They largely came in the back door and made their way into what's often called the "Shadow IT" of organizations. Official IT didn't make this software ubiquitous and mainstream. For the most part, it was already ubiquitous and mainstream by the time IT departments got around to blessing it.
Linux (and, more broadly, open source in general) is perhaps the canonical example of this trend. In some respects, Linux adoption just mimicked past adoption patterns for distributed computing in general--from Windows NT servers to PCs and even Unix in the early days. However, open source licenses make backdoor sourcing one big quantum step easier. Indeed, the basic idea that open source licensing helps to build a developer and user base that can then be monetized when the software goes into production underpins a lot of the thinking around business models associated with open source.
However, the trend goes well beyond open source. Consider the following two examples.
Especially as workforces get more distributed, tools such as Novell Teaming + Conferencing and Lotus Domino have moved beyond e-mail and calendaring to encompass a much broader set of formal and informal interactions within a company. Cisco CEO John Chambers has said that "collaboration" is the one word that describes where his company and the entire technology industry is headed.
However, beyond e-mail and calendaring, it's been instant messaging that's probably been the tool with the biggest impact, rather than something bigger and more architected. And IM came in from the consumer space, often informally. Indeed, many organizations still just use freebie IM from AOL or Yahoo or Google rather than some enterprise version.
Even the red-hot virtualization trend is an example of bottoms-up. One of the reasons that virtualization was able to really break out was that it lent itself to small, local IT optimizations with immediate payback. You could install VMware on just one or two servers and see an immediate benefit. You didn't need to rototill your data center management and change any number of business processes.
Today, the next phase of virtualization--which goes by terms like Dynamic IT--is indeed a broader concept requiring a more deliberate and phased approach. But it got its start at the small scale (which distinguishes it from many of the virtualization management solutions being touted today that are only truly useful at data center scale).
The downside of all this ad hoc-ism is that it can lead to tools that can't really grow or that don't have other characteristics--such as reliability--that become more important as usage transitions from casual to business-critical. (See twitter.) But that genuine caveat aside, the IT industry is in a qualitatively different place than it once was. The enterprise architects still have a job to do. But no small part of that job is now integrating with tools that users and departments have brought in on their own.
One of the interesting threads within this year's O'Reilly Open Source Conference (OSCON) was a variety of collaboration tools and platforms aimed at what might be called "mid-weight" collaboration. Which is to say, collaboration that is something more than mailing lists or user forums but something less than the code repositories that primarily target a core group of developers.
Here's the basic issue. Some popular projects, such as the Linux kernel, have a pretty broad range of contributors. However, many other projects--even successful ones--are the product of a much more constrained group of people. With open-source software specifically, a big part of the problem is that it usually takes considerable effort even for experienced developers to understand a code base well enough to make useful contributions, And, of course, not many people are experienced developers.
Even beyond software development, as shown in the Gartner Group graphic in this post, only a small minority of any community is highly active. To use Gartner's terminology, "Contributors" and "Opportunists" significantly outnumber "Creators." (Unsurprisingly, the largest group are "Lurkers," which is to say basically users.)
Thus, the challenge is to harness the diffuse energy of a community in addition to the energy concentrated in a relatively small number of core individuals--the "Long Tail" of content creation if you would.
Here are a few examples of the work in progress.
JasperForge is perhaps the project that's most explicitly about harnessing the contributions of nondevelopers. The community here are those associated with Jaspersoft (Open Source business intelligence) and related projects. (There are currently 227 public projects and 70 private projects.) Individual projects setup a portal that includes only the components they need. For example, a documentation project could have a wiki and shared files but not a code repository.
Launchpad is the creation of Canonical, the commercial entity behind Ubuntu. It recently got a major redesign for its 2.0 release. For our purposes here, one novel feature is a Web-based translation and review component that allows contributors to provide translations of strings in the program into any of up to 265 languages. It also includes a community support component that lets users create FAQs and build a searchable knowledge base of previous answers.
Finally, Sun's Zembly--currently in private beta--is a collaborative tool for building applications for social media, such as Facebook. A lot of these applications are pretty small and simple and they often lend themselves to reusing code from other similar applications. For example, if you have a widget that displays a group of photos from Flickr, another widget that displays a different set of photos, but in a similar way, can pretty much just cut and paste a lot of the first widget's code. In short, it's oriented for the lightweight code sharing and reuse that characterizes many of this type of application.
The need for sophisticated version control and code repository systems isn't going away. However, we're starting to see those systems complemented by new techniques that either layer tools for more casual contributors on top or that explicitly target lighter-weight collaboration from the get go.
- prev
- 1
- next
