Blogs

RedMonk

Skip to content

MuleCon Wrap-up: Rouge IT, Open Source in the Water, Support Response Time, and Reputation

MuleCon is now officially over and my luggage is a few items of schwag heavier. Namely, these little gems of schwagage:

MuleSource Schwag - Cufflinks!

Note the attention to humor-detail what with the hay. I think the Blogger gloves from SXSWi still rank as #1 schwag, but these cuff-links have a certain category of their own.

But, sadly, my work-life hasn’t turned into one of simply showing up at conferences and collecting schwag. It’s still the “slowly but efficiently” blimp-days for me.

Panels – Enterprise Infrastructure and Using Mule

I moderated two panels today both who’s titles were, as always, more general guides (much welcomed) for discussion than exact summaries of the resulting conversation:

  • Are They Smarter Than a 5th Grader: Enterprise Infrastructure Panel, with Dave Rosenberg, Jason Maynard, Matt Asay, and Larry Augustin – which turned into a discussion of the current state of open source and enterprise software adoption.
  • Maximizing ROI for Mule Implementation, with John Davies, Eugene Ciurana, John Rowell, and John Gardner – which fit pretty well to the title as we discussed how to get the business to buy into using Mule versus the “golf course” ESBs and a bit of a Mule love-fest.

M. di Paolantonio has a nice summary of the first panel, as well as the second.

Taking one slice of the conversation, the topic of open source in the enterprise came up frequently. While the first panel pretty much assumed that open source was the primary “nature” of software going forward, the second panel (packed with practitioners) said that open source seems to be more so the currently best option, in general, rather than the only one. The second panel addressed the question of “what’s the ROI on using Mule” and open source in general. The way the answer was phrased was interesting in itself.

The ROI of open source is all about cost, the panel answered. It’s just cheaper. And also, the response time for support tends to be shorter. And also you can sort of trust the open source consultants more because they have an established reputation in the open source community – that transparency of openness is great for making sure you don’t get a “moron” consultant.

I say the answer was interesting, because to me these second points are more than just “And also”‘s, but core ROI. Now, I don’t think most people think of “better support” and “don’t get dud-consultants” as a return on investment. You can’t really quantify those enough to put them in a spreadsheet and say, “yup, we got the return on our investment.” You can be damn sure, though, that they make a huge difference in finally making money with whatever software you’re building.

The topic of Rouge IT came up as well, originally introduced by Jason. He noted that he’s “terrible” at just using whatever tool works rather than using the standard issue software from IT. There’s all sorts of GRC problems to sort out there, but the general consensus of the first panel was two thumbs up each for “the consumerization of IT.” I suggested that there was some disintermediation going on here – that IT was being cut-out as a middle-man – but Larry sort of jumped to IT’s defense and said they’d love it if it just became sanctioned and “safe.” An audience member from BoA pointed out that IT would probably love it, but no one’s going to stick out their neck to make it happen. Better to be a gate-keeper than fired, I’d say the thinking goes.

I brush up this problem frequently when it comes to enterprise search: things just don’t seem to be working out as brilliantly as we’d hoped for when it comes to yanking public web technologies (like search) behind-the-firewall. To be honest, I have no answers. But the word “lawyers” keeps coming up, which probably points to the need for more of a cultural change in any given company’s corporate bureaucracy more than any technical problems.

SOA, The Stackless Stack, OSGi

MuleCon

Bouncing off that, it’s been interesting as ever to see how technologies like Mule are wiggling themselves into the answer to the question “what’s an SOA?” None of the speakers today or questioners for that matter had much good to say about what you might call Classic SOA. There was some gas and a match thrown on things like UDDI and JBI. Instead, people seem keen to build up only what they need for an SOA.

Dare we suggest they want a “stackless stack”?

Indeed, OSGi cropped up at the end as something, if you read between the lines, core to the future of Mule. After seeing the Mule run and deployed into through a Knopflerfish OSGi console, an audience member asked “when can I get that?” about three times until he got the answer “when we’re done.” Point being, at least one user out there was hot to get his hands on it, even with the gentle-threat of “I need something to tell my boss so we don’t go with someone else.”

Disclaimer: MuleSource is a client.

Technorati Tags: , , ,

Categories: Conferences, Enterprise Software, Open Source.

Comment Feed

4 Responses

  1. Re – OSGi and Mule.

    Check out http://mule4newton.codecauldron.org/ For the use Mule as part of a high adaptive OSGi based distributed runtime.

    Regards

    Richard

Continuing the Discussion

  1. […] Having just come from MuleCon myself, as I was getting a cup of coffee this morning I was thinking one thing: So, open source gave commercial application servers beat things up pretty poorly there for awhile, and now we’ve got things like Mule and the old stackless-stack. That is: simplified, cheap, lean SOA. Now, never mind if those startups aren’t doing gang-busters. Worse-case: what if they’ve figured out the right price for those technologies – free or cheap – and just haven’t figured out the business model around them? […]

  2. […] we discussed in a panel last week at MuleCon, getting tech people to take on that mind-set is tough. We’re not yet trained to think that […]

  3. […] we discussed in a panel last week at MuleCon, getting tech people to take on that mind-set is tough. We’re not yet trained to think that […]