I'm off to a pre-Christmas vacation for a few days. Kim and I will be up in Ann Arbor for the graduation of my good friend and long-time podcasting buddy, Charles "cowboyd" Lowell (pictured above). I should get to catch up with The Frontside crew too.

I'll be back Wednesday to Friday next week (Dec. 20th to 22nd) and then on the RedMonk Christmas break until around the new year.

As Anne and I were discussing yesterday, though I'll be on vacation, it'll be natural for me to have my laptop and 'net access. I gotta get my podcasts! As such, if you see me around, feel free to ping me, but I might not answer ;>

Tags: travel, vacation, annarbor, thefrontside, cowboyd

You download the software (there's a form to fill out, but that's it), put it on your server, and let it go. There's not much more than that.

It's not "enterprise search" in the sense that there's no role-driven security or integrate with business applications. It "just" does search . But, that's a whole lot to do for free. It's behind-the-firewall search.

Most search behind the firewall sucks. Having acquired, set up, and administered a Google mini at one of my past jobs, I have first hand experience with how wonderful it can be to get real, public web grade search setup behind the firewall.

Freely Disruptive

As Dan pointed out in the comments the other day, the largest barrier to entry may be people's perception that free things are not worthy of business use. What's good about a free thing like this is that nutty employees with a spare server can just go download it, set it up, and start using it without having to go through the normal, lengthy process.

In that sense, this is a great move for IBM and Yahoo! to be highly disruptive in the behind-the-firewall search market. Given that the technology works as promised, this could be a good enough solution for many, many companies. Revenue wise, I'm actually in rare agreement with IBM's on-ramp thinking for this. I can see that several people will want more enterprisey features once they realize the power and value of real search behind-the-firewall.

The Long View

Indeed, if IBM Yahoo! OmniFind Edition finds wide adoption, this could be a tipping point for enterprise search. The demo's and pitches so far have just been the usual "hey! it mashes up with maps! and knows your role so it limits access to data!" stories. My sense is that until people actually get plain old search behind the firewall, decision makers at those companies won't choose to spend cash and time on search.

For example, let's take figuring out what your companies official vacation days for America are. How long does it take you to track that down? If your intranet is like most intranets I've had to work with, the answer ranges from 5-10 minutes to "I have to send an email to The Guy Who knows." But, if you have real behind-the-firewall search, you just type in "us vacation" and you find it in seconds.

Having that kinds of experience for all sorts of "corporate data" is what will ultimately convince gold holders to spend money on enterprise search, snazzy maps mashups or no. Of course, few people are going to want to spend money for something as seemingly simple as being able to look up vacation days. "We already have intranet search, right?" they'll say...that sucks.

So, offering search for free is the best way to get the ball rolling for more sales down the line. And, it seriously screws with Google, FAST, and others as well.

Yahoo!

The above advantages are largely for IBM. For Yahoo!, the payoff is getting a foot in the enterprise market. Yahoo! should have some interesting experience with the grass roots adoption of IM in the enterprise, but partnering with IBM should give a whole 'nuther layer of experience to draw from.

That is, if they take advantage of it, this should be a good way for Yahoo! to learn the enterprise software ecosystem culture that IBM has perfected. Of course, technologically it goes both ways. As I always says, the enterprise world can learn a lot from the current consumer tech world. This whole deal is a case in point ;>

Good Enough and Security

Sure, the search is not "secure" in the sense that any given user will have their results filtered by what they have access to. Instead, any user can see any URL that's "public" on the intranet. In other consumer tech behind the firewall announcements I've been in recently, this has been an oddly difficult point for enterprise-centric people to get. Of course, it's a natural, almost sub-concious concept for the URL-culture.

Thus, the question of security and behind-the-firewall search is a cultural concern rather than a tick-list item. Search like IBM OmniFind Yahoo! Edition will find everything in the clear so you can't rely on security by obscurity...but you're not doing that with that payroll spreadsheet in SharePoint anyways, right?

To be clear my point is: if you're worried that search is finding things it shouldn't be finding, and that you should, thus, turn off search, you're applying the wrong solution to the problem. Instead, take that spreadsheet off SharePoint or stop allowing anyone on your network to access it. Indeed, finding such security violations is a nice feature of search behind-the-wall. Better a good-willed employee finds it and emails you than a malicious intranet surfer who tells no one.

Now, if you'd like to truly use search as the enterprise command line -- including pulling in content based on the roles of the user -- investing in something else might be worth it. But, if you're like many orginizations and just have no or crappy search for your intranet, IBM OmniFind Yahoo! Edition looks like a big contender for being free.

As far as it working as promised, at least one person I talked with today said they'd played around with it and it delivers on the promises. I'm curious to hear other people's experiences with it.

For the Developers

There are a couple interesting technical aspects:

• There's a straight forward, REST based API.
• From looking through the example output, it looks like it supports Open Search.

Both of these are interesting in that this free stack of software could be used as a search back end for developers who wanted to spend the time to layer other things on-top of it.

An entry on the search blog provides a nice jumping off into the topic.

Questions

During the call, someone from 451 asked why they didn't open source this, which was a good question on my mind as well. The answer was (a.) hey, we've got Lucene in it!, and, (b.) there are some third party entanglements. It's like the Java answer ;)

Another question from a Butler Group dude was right on as well: what's the pricing plan for customers who want to search 500,001 documents but don't want to upgrade to all the fanciness of IBM's non-free OmniFind search? Indeed, as a general rule of thumb I like to advice companies to figure out how to let customers pay them for what they want. If I just want to index 1,000,000 documents, there needs to be pricing around that instead of having to switch over to another product.

Why Not Go All In?

I'm not sure if there's much commercial advantage to limiting how many documents can be searched for free. That is, eventually, IBM and Yahoo! might do well to completely commodities the "basic search" market by giving away unlimited search for free. The Lucene crowd is already doing this in large part, but the brand and packaging of IBM and Yahoo! could accelerate that.

There's still plenty of revenue to be had from making search into a command line for the enterprise. The server sales alone to support 500,000+ URLs in "real time" should be nice. Crawling that many documents at a reasonable frequency takes more horse power than you might think.

Forcing a tipping point as outlined above for that might be the ultimate long term best bet.

For those who like them, here are my raw notes, including supported formats and pricing for "support":

(Thanks to ScottD! for IM'ing me and reminding me to write this up.)

Disclaimer: IBM is a client.

Tags: search, behindthefirewall, ibm, yahoo!, lucene, omnifind

Change by Committee

In my own experience and talking with others, even though introducing "Web 2.0" technologies was always tedious they eventually took hold or, at least, managed to hold on as they were slowly adopted. These technologies were always free -- often open source -- and rarely decided on officially by the company.

In contrast, the stories I've heard about companies officially going through the motions of choosing a collaborative technology have been costly and long to deliver.

Low Risk Change

Now, these "technologies" are simple, user-centric applications like blogs, wikis, and search rather than Morlock stacks like ESBs, SOA stacks, and other nut-n-bolts complexities. A little before-hand architecture is called for when selecting what nuts-n-bolts you're going to use. Or, at least, it's good to try out several and then evaluate the bake-off winner.

The key is that most collaborative and social software is low risk as far as wasting employee effort, cost, and damage to the business. Any application introduction will cause distraction, making command-and-control Scrooges think employees are stealing time; those folks probably need to shut off the 'net.

Free Change

Back to the point though. This all begs the (rhetorical?) question: is free the easiest way to change corporate culture? If you have to pay for change, then you start thinking and evaluating change which has the potential to slow down that change.

For vendors, this means using free offerings for long term corporate change. As I've bemoaned in the past, vendor's outbound product management often like to say they do only what the customer wants. That's half of what product management should do when coming up with features and requirements: the rest of the time they should be coming up with new things customers will want once they see it.

Invention is the child and parent of desire.

And, as it goes, free is a great price for trying out change.

Tags: change, search, wikis, blogs, pricing, free, lowbarriers

Network Management

I often refer to the whole slew of applications that help you monitor and take care of your IT's health as "systems management," but it's worth calling out the category of network management.

It's easy to figure out what it means: monitoring your routers, network performance, and any device related to sending or receiving data over the wire. This is different than application management (monitoring the performance and health of "applications" like databases, ERP, or custom built systems) and desktop management (now-a-days, mostly keeping Windows desktops up to date to defend against viruses and necromancers).

Netreo, OmniCenter

Netreo is solidly in the network management camp: there's no Oracle or Java monitoring, just pure network concerns. This is just dandy if that's what you're looking for or need to compliment another systems management stack.

What's excited to me about Netreo's announcement is that they're now providing their software as a service for folks who don't want to run their own OmniCenter instance. As you know, dear readers, I am all about the hosted systems management idea. I was, by chance, lucky enough to be involved in an early go at the idea when I worked on GuardianAngel and PATROLExpress at BMC.

Netreo doesn't have the AJAX'ed up UI that I've been seeing from other management vendors. That said, they do have a nicely parred down UI based on a collection of different views over your network rather than the more traditional and bulky tree based navigation.

Working with Others: Making a Platform for SaaS Systems Management

Though I didn't think of it during the call, as more and more management vendors create a hosted offering, I'd like to see more cooperations and services mashing-up between these applications. In the behind-the-firewall world, people like Zenoss, Hyperic, GroundWorks, and openQRM are seeking to build out platforms that others can plug into. But, integration in the hosted world has yet to emerge. Granted, I'm once again asking for the cart before the horse as the current crop of SaaS systems management has only been around for a little over a year.

That said, I'd like to see different hosters like FiveRuns, Netreo, and Versiera work together on at least getting JavaScript include level "integration." A vendor like FiveRuns could only add value to their platform by letting users suck in information from network specialist like Netreo; the same goes the other direction for Netreo.

Systems management is a never ending tension between best-of-breed and good enough platforms. The Big 4 have an advantage here in that they can partner with and/or acquire and "integrate" (at least into their enterprise relationships if not technologically) best-of-breed products into their platforms. Smaller players are spread thin enough as it is without in-housing all of that worrying.

So, why in-house it? Instead, the way is partnering, standards, open APIs, and maybe even some open source for the common code.

Notes

Here are my raw notes on the call:

Disclaimer: FiveRuns, Zenoss, and BMC are clients.

Tags: bmc, fiveruns, hosted, hyperic, netreo, omnicenter, ondemand, platform, saas, versiera, zenoss

As I talk with more and more vendors who are selling support around free or open source software -- like MuleSource or Sun with Java -- the nature of support is becoming more inclusive of what you might traditionally think of as pre-sales and professional services. That is, "support" means not only "support when things break," but "support figuring out how to use the software."

Support becomes a retainer for having consultants on-hand.

Having spent time doing third-level support (access to developers), traditional support can often feel like being a consultant rather than a trouble shooter. Persistent customers are often crafty at turning features and questions into bugs and dilemmas.

For those developers, making "support" officially inclusive of consulting can be a relief. More importantly, as a customer, chances are higher you'll get the right kind of service instead of the "it's not a bug" shuffle dance when you just want help using a vendor's software.

Disclaimer: MuleSource and Sun are clients.

Tags: support

So, what to make of Java SE 6 being released today?

Open Source

Without a doubt, the release of mustang is over shadowed by Java being open sourced. We've talked about -- and still talk about -- the open sourcing of Java at length, so I won't get into that here except for a brief note.

Aside from a governance model for OpenJDK, I'm eagerly awaiting the addition of some open source developers to the JCP. My enthusiasm is tempered by the reality of "things taking time," but that's the next thing I'm on the look out for in Java-land. Along those lines, I need to check-up on the currently being worked on rev of the JCP process. Heather VanCura was nice enough to brief me over coffee at ApacheCon this year and now it's worth a deeper dive.

Release Notes

So, back to Java SE 6.0. As my dev friends often ask me about any topic, "why should I care?" I'll tell you right away that 6.0 is not as exciting as 5.0: there are no language changes. Adding in enums, generics, varargs, the for loop, auto-boxing, and annotations was a big deal and deservedly generated a lot of interest in 5.0.

While 6.0 has many interesting features that are of long-term equal importance -- esp. scripting -- it's not going to get you all hot and bothered like 5.0 did. (Oooo! varargs!) I've been hard pressed to find a Java developer (out of the 10 or so I pinged) who's chomping at the bit to get this release.

All this doesn't mean you should ignore this release: that'd just be silly. There's plenty of interesting things:

Performance

Every release of the VM increases the VM's performance and, of course, fixes bugs. It's worth upgrading your Java version if only for those performance gains. I've been in several discussions over the years about putting time in the schedule to upgrade Java.

While there's always the risks of introducing new bugs and wasting developer and QA time upgrading their own setups to a new version, my default assumption is to upgrade to newer versions of a core platform as they become available. For something like Java where you don't have to re-code for API or functionality change, it's even less risky than something like Struts or Maven that might change more dramatically.

Theoretically, with Java, you just add in the new JDK and JRE and without much hassle get the performance increase and bug fixes for free.

Debugging

As someone who's spent days tracking down Java errors both in lab and in the field, anything to help with debugging a running Java application is much welcome. As this article by Mandy Chung covers in-depth, 6.0 ads many new ways to trouble shoot a Java app, esp. in the area of memory leak hunting.

Part of this is instrumenting the VM better. "Instrumenting" means adding more metrics to the VM that third parties can monitor. Systems management wonks like myself get all tingly at the idea of adding more metrics to anything. Aside from weirdos like that, it's good for trouble shooting applications on the cheap without buying and configuring third party tools like AppVision, Wiley, or Identify.

Bundling jhat for heap analysis is great. Hopefully adding in jhat and related tools to Java means jhat and related tools will scale better than their "experimental" versions have in the past.

As small thing to be excited about, OutOfMemory exceptions will now have stack traces. Sure, who knows if the place you actually got the exception is where the leak is, but at least it's something more than the tight-lipped OutOfMemory we've had in the past.

Web Services

While I'm not a huge WS-* fan, I know that bundling JAX-WS in SE will make fans and unwilling fans lives a little easier. SE 6.0 on it's own can server as both a web services client and server (of course, it's best to add in a more robust server for production) that should make "playing around" with web services easier than having to download that stack separately.

The larger point here is deceptively subtle: part of the "goodness" ruby, python, and other dynamic language stacks are that they come with so many libraries and APIs built into them rather than as add ons. Ruby comes with an RSS library for example. Adding in libraries, like web services, that Java developers increasingly use "all the time" makes the developer's lives easier.

JSR 223: Scripting

The most exciting addition in SE 6.0 is the implementation of JSR 223, or "scripting." If you've listened to me talk about Java for more than 5 minutes, you know that I see becoming a platform for multiple languages as key to Java's future.

The Java language is beginning to show it's age and, more importantly, I think the development world has had a mono-lingual mindset for too long. Increasingly, a platform that supports best of breed approaches to development -- like LAMP mixed with JavaScript for UI and Java for "enterprisey" processing -- helps developers and companies deliver innovative products fast enough to stay afloat.

The addition of JSR 223 to Java doesn't accomplish all of this. Rather, it lays the foundation to make it possible. I'll be watching how the community takes to the scripting API and how Sun and others help encourage making Java truly "talk in tongues.". If you follow my other podcast, you know that I'm already trying to get people moving on this front.

Others

As always, there are numerous other additions. The JDBC 4.0 and SQL via annotations features are particularly interesting to me. As I said back when beta 2 came out, bundling Java DB with the JDK is nice.

There's much to do about the desktop/GUI improvements; I'm more of a server side person, but if you were into Swing/AWT, I can see that access to native services -- like the system tray and web browser -- would be exciting. In the zero-sum mind-set, the open question here is how much help those additions will be in the face of Eclipse RCP, AJAX, Apollo, and every other UI framework that's stolen the collective gaze from Java GUIs.

.Net

As I side note, along with the idea of speaking tongues, taking into account the ongoing module/component work, you might be thinking: this is starting to sound like the CLR and Assemblies, that is, .Net, and how 'bout them annotations?

Indeed! Let's hope Java steals...uh..."gets inspiration from" the way properties are handled in C# and dynamic languages as well. As I said to one reporter last week:

fixing the way properties are done on objects is long overdue: the JavaBean idioms have been a great help for years, but developers are increasingly looking for a better properties system.

I'm not much for the, pardon the phrase, pissing match between Java and .Net. I'd rather see each language and ecosystem pull the best from each and keep truckin' along.

A More Open Platform

My overall sense is that SE 6.0 is opening up the Java platform technologically. "Small" things like access to the complier, better annotations processing, and "large" things like adding in scripting support are helping make Java into more than just Java.

I've made the somewhat controversial statement in the past that Java developers can be technologically myopic. Slowly, I've been seeing this trend change -- with things like Zimbra that mix languages and platforms (Linux/web browser) -- and SE 6.0 should give the underpinnings to help Java developers become developers...who happen to run on the Java platform.

Disclaimer: as mentioned above, I've consulted about this announcement. Not to mention that Sun is a client and I was a Java developer for many years. Eclipse is also a client, as is BMC.

Tags: dynamiclanguages, java, javase6.0, mustang, performance, scripting, se, sunw, sysmgmt, ws-*