Infor-Lawson: I think Icahn, I think Icahn

Surprising exactly no one, the serial acquirers at Infor and their private equity sugar daddies at Golden Gate Capital have submitted an "unsolicited" takeover bid for Lawson Software.  (Lawson's hiring of an investment bank last week wasn't technically a solicitation of the most acquisitive ERP vendor in the universe, but the smell of expensive perfume is hanging in the air over St. Paul).

Really, the only question here is, "what took you so long"?  Activist investor Carl Icahn has apparently been looking for some kind of deal for some time, and it was widely believed that Infor brought on former Oracle exec and banker/dealmaker Charles Phillips as CEO to rev up the deal machine again.

The wire release cited in the New York Times article was dated Friday - but so far I haven't seen much coverage of this.  Attention financial and software media....

UPDATE:  Chris Kanaracus at IDG speculates that other bids might be forthcoming.

DumDum

Salesforce.com has acquired the popular open source collaboration platform DimDim, and surprise, has closed the door on future contributions to the open source project. We've

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...