Not Sweet

Some great insights from Forrester's Tim Harmon in a writeup on SMBs' use of open source in a shift from traditional IT to what they call "business technology" - including mission critical apps like ERP.

One of his points will surprise some: "SMBs are not ramping software-as-a-service (SaaS) as fast as large enterprises and are taking greater advantage of open source software."

Harmon particularly notes that SMBs are "suffering from monthly SaaS subscription-fee indigestion." Boy is he right about this - we hear this a lot at xTuple now. People bought in to a SaaS solution a year or two ago, lured in by a promotional rate, then are surprised when the renewal the following years is double or even triple what they paid before. We just signed a new customer today that was featured prominently in promotional activities for a leading SaaS player; believe me, they were ready to move.

There's a lot to like about software as a service, to be sure - but it's also true that it does very little to ameliorate the persistent problem of vendor lock-in, and the bad behavior that inevitably follows a tilted scale like that.

Infor's new CEO: What's behind Curtain #2?

Very interesting. After the HP/Oracle/SAP shuffle with Mark Hurd and Leo Apotheker, now comes news that Charles Phillips, the former Wall Street analyst who was #2 at Oracle for many years, has taken over the top job at Infor.

Sure sounds like somebody's trying to get bought.

The company apparently gave the scoop to the NY Times' Ashlee Vance, who noted, "Infor would appear on the track to file for an I.P.O. or certainly to be acquired by the likes of Oracle, SAP and I.B.M."

Or maybe Microsoft, given Infor's recent decision to junk their tool business, and use all MS stuff.

Not sure I buy the IPO prospects - but they gotta do something, if you believe the whispers about impatient bankers at Golden Gate and elsewhere. And big-time M&A is a world, and a process, that Phillips is said to know well.

But as we've said before, it's a short list of potential buyers. And I'm not sure that it realistically includes anyone besides SAP.

5 Tips on Engaging with Open Source Communities

So, given my merciless dissection of the Compiere train wreck, as well as years of poking our proprietary ERP competitors in the eye, it might seem fair - and in fact overdue - to ask your humble correspondent just how one goes about engaging with open source communities.

Fair question. And it gives me a good place to start what I hope will be a more regular discussion of such topics here, rather than the headline-driven reactions that have characterized this blog heretofore.

So, without any further ado, here are five tips on how to work with your open source community!

1. First and foremost, always err on the side of transparency. Even if your business model, like xTuple's, involves selling commercially-licensed products, you'll still pay a heavy price if you're perceived as trying to hide stuff. Forum discussions, bug trackers, and the like should all be completely public. Your source control for the free product (SVN, Git, CVS) should be publicly accessible, and you should also have as much documentation publicly available as possible.
   
2. Related concept - publish your pricing. Especially if you're coming from a proprietary world like ERP, where the whole game in the sales cycle was NOT to reveal the pricing -- until the hook was so far in the prospect's gills that they couldn't shake free. It turns out that people want to understand how you're going to make money, and survive as a business; while there will always be people looking for a completely free lunch, most serious business customers will eventually want to strike a fair economic balance with you. (Note: that might well entail some kind of non-monetary exchange, such as code contributions, translation/localization, or just community support. But that has an economic value to your company too).
   
3. On to the development process... by all means, engage with potential contributors as early in the process as possible. One of the saddest things to happen in open source - and I daresay it's happened to most any project of any size - is when a contributor comes in out of the blue, and dumps a pile of code in your lap that you can't use. Shame on them, I guess, for toiling in obscurity without learning the rules of the road - but more shame on you, probably, for not leaving the right trail of bread crumbs for them to follow. In xTuple's case, discussions of new features typically start in the forums (here's a good example having to do with Fixed Asset management), then - if it's a significant enough development effort, it will likely require some sort of specification. For smaller efforts, a detailed description in the issue tracker might be enough (here's a good example of a contributor's work on an integrated spell checker.)
4. The spell checker example above also illustrates the next tip: Keep communicating! Once you've got an initial idea of how to get started, active two-way communication between the developer and the rest of the community is crucial. Both in the proactive sense of not conflicting with other people's work, but also in the reactive - back and forth discussion over the planned approach, and of course the results of actual testing. This generally happens in the form of additional notes and comments - either in the bug tracker, forum topic, or even comments on a published document like a spec.
   
5. Understand the project's timelines, as well as standards and processes for QA testing. and documentation. Some projects (often corporate-sponsored ones) are more focused on meeting particular release date goals, others (such as the outstanding PostgreSQL database) take more of a "when it's ready, it's ready" approach. In the case of xTuple, we do try to keep to the general outlines of our published roadmap, and have apportioned dedicated company resources not just to coding, but also working with community volunteers, and managing a rigorous QA and documentation process.

Would welcome any comments below. I suspect I'll have another five tips before long, but these are key points that have served us well at xTuple as we've built the #1 most active project on Sourceforge for almost two years running...

Who's next for Oracle?

Here's a fun exercise from Stephen Jannise at ERP Software Advice. Vote on who you think Oracle's next big acquisition will be...

Consona-Compiere

So mixed emotions here in the ERP Graveyard today. Our sometimes cohorts in the world of open source ERP, Compiere, have been acquired by Consona - the Infor wannabe funded by Battery Ventures and Thoma Bravo that has previously rolled up midmarket packages like Made2Manage, Intuitive, and the like. (See the Scorecard for a full roster)

Here's the press release. A few thoughts, and I'll trust you, gentle reader, to recall my more than usual conflict of interest in commenting on this.

There are two names that are not mentioned in the press release. That of the Compiere author and founder, Jorg Janke - who was Compiere for years and years, and can quite reasonably take credit for the "modern architecture," etc., that Consona highlights. It's true that Jorg didn't always see eye-to-eye with the open source community he helped create, and this was one of many factors that led to the Adempiere fork of the Compiere software.

Of course, probably the major factor was the initial VC investment from NEA back in 2006. And as is often the case when the VC's come in, Jorg was moved aside at some point to make way for Don Klaiss and some other managers transplanted from Oracle. But it was particularly graceless of Consona not to mention Jorg at all here; he deserves better.

The second name not mentioned, of course, is Klaiss - the (presumably outgoing) Compiere CEO. I think it would be fair to say that his tenure at Compiere was not an overwhelming success. On his watch, the company further alienated their dwindling open source community, including many of their reseller partners, by driving new product development in a more closed direction and not making source code available for new modules.

NEA put a great deal of money into Compiere, and since the value of the deal wasn't disclosed, we can only speculate about their return on that investment. But it's clear from talking to people who have become xTuple customers and partners over the past few years that they burned through a lot of money, and didn't have a great deal to show for it:

• huge overseas development projects for new binary-only commercial products
• salaries for a ballooning management team
• multiple office relocations, presumably to be ever-nearer to the various centers of gravity in the California VC/software industrial complex
• and, oh yes, just 130 customers. And that number's even lower than it sounds.
  

Lots of people will be asking what this means for open source, software business models, and of course, one of the core tenets of this humble Graveyard: that with all the crazy, finance-fueled M&A activity in the ERP software space, open source is a powerful defense for companies concerned about the longevity of their ERP investment.

I would humbly submit that the fate of Compiere (please don't even ask me to comment on Consona's plans for the product - see also the Infor SOA offering and Nixon's secret plan to win the war) stands as an object lesson in support of that theory.

Compiere failed as a company because it turned its back on open source - on its community of free users, and partners and customers who wanted to be full participants in the ongoing development and maintenance of the software. It's just especially ironic that the bullet was fired by someone like Consona.

More thoughts soon.

Update: Interesting questions from Frank Scavo at the Enterprise System Spectator...

This blog has moved

This blog is now located at __FTP_MIGRATION_NEW_URL__.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
__FTP_MIGRATION_FEED_URL__.