mult.ifario.us

Duncan Coutts posted some slides from ICFP about the developing Haskell platform — a set of "known good" and well-maintained libraries — and it is indeed on its way. (Compare with the "batteries included" effort for OCaml.) Here's the stack from slide 13:

It's not in the charter for the Haskell Platform to make general improvements to Hackage, but looking at the stack diagram I couldn't help but thing about a comparison against a language stack like Java (JDK, Maven, Codehaus, JCP) or Ruby (C ruby, rake, RubyGems, RubyForge) instead of Linux. Quality, collaboration, and liveness are important aspects to assess for a project, but that's next to impossible without publicly accessible (and relatively standardized) bug tracking, source control, and discussion. (Things like continuous integration are niceties but provide somewhat lower utility than the big three I just mentioned.) With 754 libraries, there's a lot of meat and a lot of mystery that's impossible to assess at a glance from the current HackageDB package list web interface. The "heuristic" requirements for libraries in the Haskell platform does include a bug tracker and good basic hygeine (build portably with standard tools, proper releases, maintainer), but it's missing those other touchpoints.

Lest I be perceived as casting stones, my experience is that even in the current circumstances and in spite of the lack of visibility, the Haskell community is vibrant and active. The Cafe and IRC are bustling, and troll-free and flame-free with very rare exceptions. Community leaders are friendly and approachable. Where I've found issues with libraries (resource leak in HTTP, QName equality bug in HXT, attribute qualification issue in "light" xml), maintainers have been helpful and receptive. It would be even better if it was straightforward to collaborate with other users on dedicated mailing lists, post or consume bug fixes via darcs or git branches (the good kind of fork), and track updates. (Use of distributed VCS tools like Darcs and git exponentially increases the utility of a publicly available project VCS.) There is no reason that this should be limited to just a blessed core, as it will help in the growth and refinement of other libraries as well. Posting to Hackage should entail the creation of a mailing list, the provisioning of a bug tracker, and either a check-in of the source for the posted library to a central repository or a reference to a publicly available git or darcs repository.

More than most and less than some, I appreciate the difficulties in providing community infrastructure, having observed Bob and Ben in action at the Haus and watched a top-level project at Apache (ODE) from proposal through graduation. I also appreciate the role of the infrastructure in creating and reinforcing community — it's no accident that a fair proportion of the most widely used open souce libraries on the Java platform have grown either at Apache or at the Codehaus.

Dan in the booth

Manning the Envoi Solutions booth at JavaOne with Dan was a good time. The overall win from the show was getting to talk to lots of people who are happy users of the XFire project at the Codehaus. The unfortunate thing was that not many of them were aware that XFire has evolved into CXF, a project under incubation at Apache and rolling up to a 2.0 release, and even fewer of them were aware that Envoi Solutions was the company founded by the same guy who founded the XFire project, i.e., Dan. In an open source project, especially a project that's got relatively low barriers to entry and few major issues, you don't get many opportunities to touch your customer, and it's poor etiquette to make the first move — the download and evaluation process should be frictionless and as anonymous as possible. You're stuck waiting for the customer to touch you first, and they may not even know you're there.

One place to attack the anonymity issue is at the point of distribution, and done right, this doesn't need to taint the community or the company. Introducing a level of indirection should be an obvious trick for a software developer, and the idea is the same classic that the various Linux companies have been using for a long time — distribute a slightly more polished or otherwise augmented version through a channel that's separate from the project, and use that indirection to associate the distribution with the company. Some of the goodies that Dan's got underway (some private as yet and some public, e.g., SXC) should help create that level of indirection.

The negative from the conference was the pavilion layout. The Envoi booth was in the "startup exhibitor alley", and like many things, it sounded like a good idea at the time. The floor layout showed the alley as a rectangular placeholder, but the actual layout was a bunch of angled walls spaced about eight feet apart with one vendor assigned to the front and back of each wall. The vendors on the ends had a great deal, but the vendors in the middle essentially shared a narrow strip of floor space and had to generate traffic by tackling passers-by. (Nonetheless, we were in good company, sandwiched between Talend and Hyperic.) The conference representative was impressively unapologetic. Not quite verbatim, but close: "If you choose to come next year, you won't be eligible for the startup alley, so you'd be in one of the booths on the floor. This was just something we tried, and we'll do it differently next year." Caveat exhibitor...

Dave Rosenberg, the CEO of the recently funded MuleSource, wrote an op-ed for Sandhill.com about wrapping a business around the Mule project. (And, of course, way to go Ross! Another great project incubated at the Codehaus.) Two of Dave's comments struck a chord with me, since I'd gone over the same ground many times over the six years I spent on FiveSight.

On market sizing:

Market data is fairly easy to find. Analyst firms such as Gartner and IDC frequently publish data that provide a base for your research. In our case we looked at the broadest market opportunity for our product over the next five years. We were able to determine that the aggregate market was $8.5 billion.

Of course, looking at their track records in terms of correct predictions, you realize that folks like Gartner, Forrester, and IDC are usually wrong, and most VCs, being smart folks, know this, too. Moreover, injecting change into a market will change the size and dynamics of the market, and exerting pressure on incumbents will cause them to change their tactics. As an example, one of the things that we ran into was "red" (Oracle) or "blue" (IBM) companies where all-you-can-eat licensing combined with single-sourcing initiatives made selling into those companies impossible, and trying to back those numbers out of broad predictions was pretty much impossible without gathering new data. Selection, adoption, and installation cycles further complicate making naive estimates, and this especially true if your revenue is concentrated in one phase of the customer lifecycle (e.g., up front with training or in back with production support). Nonetheless, the market size slide with at least a $1B market is part of the obligatory small talk that's part of any funding pitch; I just have trouble doing it with a straight face.

On the other hand, you can attack the sizing challenge from the bottom up, and Dave hints at that — the community around the project is all of the data you need. What's the composition of your community? At what rate and under what conditions are community participants converted to customers? What products are people asking for? Part of the beauty and magic of open source is that your customers come to you, and preserving the polarity of that relationship is important. The community activity is really the first stage in the sales funnel for an open source customer, and you can choose the levers that you want to pull (evangelism, training, partnering) to alter the rate and composition of the flow. My preference would be to use this approach combined with rough market segment sizes (number of servers, etc.) to build projections. In FiveSight's case (BPEL execution component), the data told us that our product offering didn't have the breadth (e.g., full BPM platform, full ESB, full integration product) to appeal to a large market but that we could build a profitable OEM-oriented business, and that's the direction that led us to an (intended and expected) exit via acquisition.

On pricing:

Pricing remains one of the great mysteries of any business. Open source companies tend to look at the cost of their nearest competitor and price their offering at some percentage discount.

From my perspective, open source is a method of packaging and delivery of software, which if you're not selling the software, is irrelevant to pricing. Services, support, training, and access to information have the same value as they do for "proprietary" vendors, and the fine line for the open source vendor to walk is in charging for access to information while reinforcing and nurturing the community.

As a consumer/producer of open source, it was interesting to see Google Code hosting launch today. It also explains why people from Google were trolling with questions about how Google could help open source... (I should have asked for a search appliance for the Haus now that I'm thinking about it.) It's pleasantly minimal in that it fits cleanly into the spectrum of available infrastructure below the level of a SourceForge, RubyForge, or Java.net: no mailing lists, no forums, no releases, and no project entry criteria — just fill-in a form to get 100Mb of subversion space and an ultralight bugtracker.

From a producer perspective, no strings attached, free subversion hosting is a great offering, although I'd be more likely to use something private and something cooler than subversion — like darcs or Bazaar or another system that supports both push and pull branching semantics — until and even after a project is ready for public consumption. (Subversion+svk would count.) As a consumer, my question is how I'm going to filter out the crap. Nothing is worse than seeing a promising-sounding project and then finding out that there's nothing of value there. On SourceForge, there's plenty of deadwood, but I can look for releases, at activity levels on mailing lists, or at project statistics. On Java.net, I can look at releases, mailing lists, or at rankings. A good start on a crap filter would be a simple voting model for projects, e.g., allow a user to leave a star on a project that they found actually useful. (Of course, something like the Google Finance plotting widget applied to subversion activity and branches/tags wouldn't hurt, either.)

My answer to the “How could Google help open source?” at the time was straightforward: contribute effort and even sponsorship to the projects that Google developers find useful. This is what everyone does (or at least what everyone is supposed to do). Barriers to entry have never been an issue for open source projects, but drawing together a community and channeling combined energy into defining and creating good software have always been and remains a challenge.

A while back, in order to get the tag functionality in Typo, I upgraded from the stable download to the trunk. Typo is in flagrant and ongoing violation of the “release early, release often” directive for software projects, but it's been a nearly painless experience each time. Except for this last time. To get an update to the Typo sidebar plugin API, I ran svn update on the Typo on my local machine, tweaked a couple of things, and tested; then I ran svn update on the Typo on my remote machine, and... crash. The difference was the theme that I use on the production server, and I resorted to Google before fishing through the theme layouts for issues. Ironically, I found a quick answer on Phil Cryer's blog and had things back to (what passes for) normal in a few minutes.

I say ironically for two reasons. First, it's ironic for me to find the answer on Phil's blog because he just gave up on Typo and went to WordPress over this very issue. And that is ironic because I gave up on Wordpress over a recurring annoyance with incorrectly set Media-type and encoding (see RFC3023 and Mark Pilgrim's discussion for some background) where I had to trace through multiple noodles of PHP spaghetti code to fix it each time Wordpress shipped a new version. (Each time, the upgrade was security related, so I felt obliged to apply it.)

Ismael pinged me today with an email that he sent to the Apache Incubator list:

[...] Our company [Intalio] would be interested in participating to the Ode project through a donation of the PXE BPEL 2.0 engine and the dedication of development resources to the project. [...]

There is already the Agila BPM project under incubation, and there was recently the contribution of a BPEL4WS 1.1 implementation by Sybase. It's my opinion that adding PXE to the mix should actually help clear things up and shorten the time to market for the combined effort — PXE is a complete implementation of the WS-BPEL 2.0 standard with a great team behind it, and it will round out the set of ideas and concepts that the Twister/Agila and Sybase codebases embody. Bill Flood, who represents Sybase on the OASIS BPEL committee, put it in perspective succinctly:

It's all good news for the community at large!

On December 6, Intalio announced that it acquired FiveSight, the company that I founded in 1999 and then led through six years of ups and downs.

SteveShu has a few comments on the FiveSight experience. (Steve has always been too humble for his own good; he was a vital member of the team from the moment he joined and played a key role in every win that the company had, including our relationship with Union Pacific and our distribution partner in Japan.) I can still remember Steve's first day on November 6, 2000. He showed up at my apartment in Chicago, and we went over FiveSight's "books" (an Excel sheet) at the kitchen table. That was just before FiveSight kicked-off in earnest with the original crew of six in a big loft in downtown Chicago, complete with a coffee maker, a pool table, and a fish tank.

Looking back, I like to think of FiveSight like a piece of software. We had a pretty good v1.0 release with a good product and some great customers, all driven by the moxie to turn minimal funding and maximal ambition into a going concern. FiveSight v1.0 won awards for rapid growth (426% for 2002, not half bad...) from Deloitte & Touche and the Chicago Software Association. We hit growing pains in 2003, trying to get over the $3M/year revenue hump against an increasingly competitive Java EAI market and the IT spending doldrums that followed the bubble burst and the 9/11 attack.

PXE was FiveSight's v2.0 business. We took stock in the middle of 2003, ramped-down FiveSight v1.0, and decided to bet on BPEL as a standard that would decouple design and protocols from execution. The first version of the BPM component for our previous platform morphed into Maciej's elegant design for the PXE execution core, and we were off to the races with an OEM-focused strategy that emphasized our strengths in low-level Java and high-level, targeted sales focused on the build/buy proposition. (I picked Sleepycat (for their OEM business) and Zope (for their community) as businesses to emulate, but I also started with the assumption that the market for BPEL execution and the overall market context would be completely different — FiveSight v2.0 would have to find its own way.) Open source was part of the thinking from the beginning but not part of the public strategy until June of 2005, when we posted PXE as open source to accompany SUN's tooling demo at JavaOne.

I'll be watching Intalio's progress from my seat on the sidelines, but more on that later.