Compiere releases V3.0 of its open source ERP package

Compiere just released version 3.0 of its namesake product with “well over 150 improvements“. If you’re not familiar with Compiere (hey, how many of us purchase ERP products), think of Compiere as an open source alternative to SAP or Oracle’s applications. Judging by a quick look at their product line and Compiere’s customer success stories, Compiere is squarely targeted at the SMB customer segment. As such, this would put Compiere up against Microsoft, more than it would against SAP or Oracle.

Compiere offers 3 editions, a free “Community Edition”, a “Standard Edition” priced at $25/user/month and a “Professional Edition” priced at $50/user/month. Maybe it’s the pricing class that I just took this weekend, but I really like how Compiere has been able to differentiate the 3 offering based on features that will lead the buyer to pick “A” vs. “B”. I also like how the “Standard Edition” and “Professional Edition” are following the gated access to OSS products business model that has worked so well for Red Hat and others.

Give Compiere V3.0 a try and let us know what you think. (Personally, I’m not a fan of registering to try out an OSS product. We tried that with WAS CE and some of the contact info we received was quite amusing, not remotely close to PG-rated, but amusing…folks at Compiere: maybe make the info optional, and hence reduce a barrier to trials?)

 

Can OSS guard against “do-overs” and “stupid decisions”?

BTL posted a ‘highlight’ of an interesting interview that Mary Jo Foley did with Iain McDonald, director of project management for Windows Server.

In the interview, McDonald describes “Windows 2000″ as the worst-run project of all time. McDonald says that “stupid decisions” and “7-day weeks for 30 weeks in a row” helped the Windows 2000 project earn that title. Keep in mind that McDonald’s statement is from a project management standpoint, and we shouldn’t equate it to “Windows 2000 was the worst product of all time”.

Larry Dignan goes on to ask:

“Was Windows 2000 really a worse run project than Vista, which had a do-over in the middle of the project?”

If “do-overs” and “stupid decisions” make for the “worst project of all time”, can the OSS development methodology guard against these pitfalls for OSS community projects?

It can be argued that truly open, open source development requires “do-overs” at the core of the project. Well, maybe not “do-overs”, but “do multiple times”. For example, Linux with KDE & Gnome or Apache Geronimo with Tomcat & Jetty. In OSS circles, we talk about better ideas coming from several solutions to the same requirement, but what about the wasted time and effort?

I’d suggest that “stupid decisions” happen in the OSS & Traditional software world at equal proportions. In the OSS world, anyone can reduce the impacts of a “stupid decision” by writing code that addresses the same requirement, without the “stupidity” and let the community pick a winner. But then, we get back to the question of duplicate work.

We’ve seen analysis of what the Linux kernel would have cost to develop inside a Traditional software company. A view of the wasted time and cost would be an interesting adjunct piece of data.

Now, let’s ask if “do-overs” and “stupid decisions” can be minimized at an OSS vendor.

I’d argue no, or yes, but not nearly enough to matter. My premise for this argument is that when a single OSS vendor is driving a project, the majority (90%+) of OSS development work, where the “do-overs” and “stupid decisions” really hit home, is done by internal developers. I’m not saying that the community doesn’t ever contribute valuable code. But if you spend a little time on the mailing lists or Jira’s for some hot OSS vendor-backed OSS products/projects, you’ll find how little the community contributes to the development. (The community definitely contributes in other ways: docs, helping newbies, finding bugs, etc). So, if 90%+ of the core development work, and as a result, core development decisions, occur inside the OSS vendor’s walls, shouldn’t “do-overs” and “stupid decisions” occur at rates similar to those at Traditional vendors?

 

The code isn’t dead, just taking a break

I check my blog stats every few days. There I said it.

When I was checking for the Feed Stats option on the wordpress.com Dashboard and realized it was gone. After some digging, I found this post from Matt at WordPress:

“(It’s) important to us to be constantly adding new features and functionality for you guys, sometimes we have to retire or prune things that just didn’t work out or that we don’t have time to focus on right now.”

From the 2 replies (out of 200+) I read, half seemed to understand and half were upset with the decision.

It would be nearly impossible to do something like this in the traditional software world. Products and features rarely die without a replacement/alternative nearby. Paying customers don’t want to use your software if they can’t trust product/feature continuity with releases.

In the open source world, it’s much more common to add a feature, only to drop it in a future release. Or to add two implementations of the same feature and see which one users like more. For example, Apache Geronimo recently passed 100% of the JEE5 TCK tests using the CXF Web services stack. However, I hear they’re planning to ship CXF and the Axis2 Web services stack when a JEE5 certified Geronimo 2.0 ships later this summer.

The “see if it sticks to the wall” approach used within most open source projects helps drive innovation. It can also be a pitfall for a customer that picked a “didn’t stick” technology/feature. Sure, you have the code, so you could support yourself on the technology/feature, but that’s not realistic for most enterprises.

Definitely a double edged sword, but still very cool to see in action!

 

The Impact of an 85% OSS Renewal Rate

Another tidbit that David Skok (JBoss VC) gave at OSBC was that the JBoss support renewal rate was 85% (likely at the time that JBoss was sold to Red Hat).

It seems strange that a customer would buy support in year 1 and then decide not to renew the support agreement in year 2. Remember, 15% isn’t chump change. An 85% renewal rate means that you have to “grow” 15% just to stay flat with your previous year’s # of customers, or potentially, revenue. In most software markets, 15% is about 1.5x or more of the market growth rate.

Why didn’t the 15% renew?

1] The OSS product is no longer being used, in favour of a different (OSS?) product
2] The application running on the OSS product is no longer required
3] The level of support that a paid subscription/license provides didn’t meet the customer need (either because of under utilization of support or under-delivery of the support experience)
4] Something else?

You can’t do much about #1 or #2, although you’d hope that growing use of OSS, and in particular, your OSS product, would ensure a near 100% renewal rate with customers you already had.

But #3 appears to be a much larger concern. What happens when 15% of your current paying customers decide they can use your OSS product without paying you a dollar. Worse still, these are users you convinced to buy support/license from the mass of non-paying users. Customers surely realize that their support/license payments enable the OSS vendor to continue developing the product in question. Sure, you get some free development from the community, but 95%+ is still done by the vendor’s employees. What happens when more and more customers pass the “pay for continued development” buck and simply become users???

Traditional software renewals rates aren’t 100%. But you’d expect higher than 85% from OSS, since conventional wisdom tells us OSS tracks closer to customer needs and does away with the ‘pitfalls’ of the traditional software business model.

 

Adding Risk into the OSS Customer Equation

Finally catching up on some reading…I came across this post at ZDNet that discusses an upgrade of Red Hat’s stock by Credit Suisse.

The analyst (Jason Maynard) seems to be on the same point that David Skok (of JBoss VC fame) made at OSBC. How can JBoss/Red Hat monetize a larger percentage of their user base? Currently only 3% of JBoss customers (or downloads? How would JBoss have a count of non-paying customers) actually pay for support.

I quickly thought about Marten’s customer groupings that he summarized at OSBC.

[1] Those willing to spend time to save money
[2] Those willing to spend money to save time

I knew that I liked his two groups for a reason. I totally forgot that I had come up with 3 groups of OSS users a little while back. My groupings were, more or less, based on willingness to accept risk.

{1} Cost Contentious: Unlikely to ever pay
{2} Scope Contentious: Pay based on app criticality & perceived need for support
{3} Risk Contentious: Likely to always pay (i.e. CYA)

Both views make sense, but willingness to trade off Time & Money doesn’t happen in a vacuum. That’s why I believe willingness to accept (varying levels of) risk is important when trying to categorize OSS users.

On the surface, there is little change to the Time vs. Money equation as a result of JBoss adopting the Fedora model. A customer that wants to spend time to save money can continue to use JBoss “Community Edition”. As a result, one could refute Mr. Maynard’s claims that JBoss adopting the Fedora model will drive more revenue.

This is where risk comes into play. Keep in mind that the JBoss “Community Edition” will include the latest features, some of which won’t make it to the JBoss “RHEL” version or may be dropped from future JBoss “Community Edition” versions. JBoss is clear that backwards compatibility isn’t guaranteed with JBoss “Community Edition”.

If you’re a customer that wants to spend time to save money, and you’re somewhat risk averse, than you don’t like using a product with features that may disappear in the future. You have the option of buying JBoss “RHEL” and getting backwards compatibility. You can also look elsewhere for an application server solution.

Taking Risk into consideration is likely the #1 reason that an OSS user will turn into an OSS paying customer.

 <Updated 2007-05-30> “Risk aversion” shouldn’t be considered a dirty secret of OSS.  I can’t think of an analogy in the traditional software market. But you don’t get to choose whether to pay for traditional software or not :-) </updated>

 

Analysis: JBoss to follow Fedora-RHEL model

Before I get started, Red Hat/JBoss have the right & duty to their investors to grow revenue & profits as they see fit. I am certain that a good deal of thinking went into making this decision, especially to consider the customer impact.

Here’s a table that summarizes the likely announcement from RH/JBoss (where JBoss “retro” represents their business model as of 2007-04-23):

Product	Source Code	CVS Access	Binary Access
Fedora	Free	Open	Free
RHEL	Free	Closed	Paid
JBoss “Retro”	Free	Open	Free or Paid
JBoss “Fedora”	Free	Open	Free
JBoss “RHEL”	Free	Open	Paid

 
The major change is that non-paying JBoss customers will have to build JBoss from source or use the JBoss “community edition” version (whatever they decide to name it) binary. (See below for why each may not be an optimal choice).

If I had to group OSS customers by their likelihood of paying for support/services, I’d suggest these three (other classifications are likely valid also):

1. Cost Contentious: Unlikely to ever pay
2. Scope Contentious: Pay based on app criticality & perceived need for support
3. Risk Contentious: Likely to always pay (i.e. CYA)

Let’s use these 3 categories to analyze the customer impact of using the Fedora/RHEL model for JBoss.

Cost Contentious:
1A] Build JBoss from source: Not sure how many customers will do this. For example, how many customers build RHEL from source (although it’s a different ball of wax with an OS vs. an app server). Sometimes it’s not as easy as it sounds as builds don’t always complete on the first try. I haven’t built JBoss from source (so please leave a comment if you have), but at the very least, it’s one more hoop to jump through. Maybe there will be a market need for something like CentOS around JBoss products?
1B] Use JBoss “Community edition” (or whatever it is called): May not be appealing for production use, since “backwards compatibility” is not guaranteed and you may (inadvertently) use a feature that doesn’t make it to the next release.
1C] Consider an alternative: Customers will choose based on their needs and their comfort with one open source app server community over another.

Scope Contentious:
2A] If the application isn’t business critical: and the impact of a few minutes/hours/days down time does not justify any spending, then see [1A], [1B] and [1C] from above. (Note: customers can define “business critical” differently).
2B] If the application is business critical: and you’ve been using JBoss without support, this move should help you decide to go get support.

Risk Contentious:
3A] Already paying for support/services: Not a whole lot new for you

This move is definitely intended to drive more revenue to RH/JBoss from customers already using JBoss products without paying for support. There is a risk that some portion of these customers will view the move as a reason to consider alternative products. It appears that RH/JBoss feels that there’s more revenue to be had from [2B] than the risk of losing customers from [1C] and some folks in [2A]. And if these non-paying customers leave, did it really cost RH/JBoss something? (Methinks yes, but from a revenue standpoint, no, at least not now).

Interesting times … and definitely worth looking at alternatives (my biased opinion is that you start with Apache Geronimo or WAS Community Edition).

 

IBM and OSS - Buring Boats

Okay, I do not speak for IBM in any way (read full disclaimer here). But after reading the following from Matt Asay’s post today, I couldn’t resist.

“IBM uses Apache/BSD to burn boats…everyone else’s. :-) The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.) This is classic Martin Fink-type thinking, i.e., open source your complements which also happen to be your competitors’ core competencies. The problem is, they’ll likely do the same. Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”

Let’s dig into Matt’s statement:

MA: “IBM uses Apache/BSD to burn boats…everyone else’s. :-)”
How many open source projects does IBM contribute developers, hardware and/or fund to? Let’s take the example of Apache HTTP Server. Long ago, (the royal) we decided that web serving was a commodity and it didn’t make sense to build our own web server to use inside of WebSphere Application Server. Fancy thing was that BEA and Oracle made the same decision. Does IBM get more than it gives to the Apache HTTP project? Yep, that’s what you’d expect from an open community project. But we have a team that is works on the Apache HTTP project day in and day out. What about Apache Geronimo? Yep, it’s the base for WAS Community Edition and yes we have a sizable number of IBMers who work on Geronimo as their day jobs. What about Linux (let’s throw in a GPL project), again, yes, IBMers work inside the Linux community as their day job. Eclipse, check. OSGi, check. OASIS, check. I could go on….

MA: “The company builds its software business on proprietary software and its services and hardware businesses on open source software (as well as its proprietary software.)”
Umm, so yes, IGS will work with OSS based on client needs. But heck, they’ll work with IBM products, Microsoft product, Oracle products or any software the client seeks. Next, does Linux help drive hardware sales? Sure, but remember we spend resources inside the Linux community, so we’re not taking without giving. While IBM may drive $1B (or whatever it was in 2006) from Linux-based software, hardware and services, it is a small portion of our total $90+ billion in revenue. I’d suggest you want to rephrase the statement to read “(as well as open source software)” in brackets.

MA: “Or, more pertinently, an open source competitor will come along that doesn’t have the same need to keep sacred any proprietary software. How do you compete with someone that can drive all software value to $0.00?”
Umm, we’re competing and winning quite well. Thanks for asking :-)

Anywho, aside from this paragraph on IBM that I take exception with, Matt’s post is well worth the read. He hits the nail on the head when he summarizes with:

“Net net: burning the boats is the right thing to do, but which boats to burn…?”

Indeed…Which boats, when and how does lighting the fire help customers? That customer angle is very important and likely the reason that we’ll see OSS and traditional software (happily) coexisting. (Much more on this in a later post)

 

Sourceforge OSS Marketplace - A Place for the Long Tail?

Roberto writes that Sourceforge (SF) is adding the ability for OSS projects hosted on Sourceforge.net to sell support & services, and for users to buy these services. SF plans to launch Marketplace in late spring/early summer.

Kudos to Roberto for not only blogging about the Marketplace announcement, but also for finding the Senior Market Management position for SF Marketplace and linking to VA Software’s (SF’s parent company) latest 10Q. It’s amazing that they made $13M in e-commerce revenue in the most recent quarter from selling consumer goods through ThinkGeek. Also interesting is that VA made $3.8M from online media, mostly advertising. I would have guessed sites like Sourceforge.net and Slashdot.org would drive more than ~$4M in Ad revenue per quarter. But maybe geeks don’t click banner ads because they use Firefox with Adblock Plus ;-)

Anywho, so now it gets interesting between SF Marketplace & Red Hat Exchange, although they appear to be going after different projects & customers.

Red Hat is definitely going after the enterprise customer who has (by in large) made the decision to run the given product on RHEL. So, the testing and certification of a product with RHEL is critical to being included in the Red Hat Exchange.

But a majority of customers don’t run OSS on RHEL. A lot of folks run on Windows. Even JBoss use on Windows was 50% or so, which is somewhat lower than similar figures we saw from our WAS CE downloads about a year ago - things may have changed since though.

Today, SF is a leading destination for finding & downloading OSS products. The SF Marketplace appears to be the next logical step.

For the large projects on SF who already have support & services business attached, I doubt that this announcement changes much at all. Customers interested in, for example, Hibernate support, will find their way to hibernate.org and then to jboss.com. So I’m not sure why RH/JBoss would want to give up a percentage of their revenue to VA/SF just to get included in the SF Marketplace.

For emerging projects or for projects with a small development team/community, a majority of the 144,548 projects on SF (i.e. Longtail projects), getting included in the Marketplace would make a lot of sense. Why spend time and resources building & managing the support infrastructure and marketing your support & services if SF can provide that to you for a (small?) cut of your revenue.

Experience tells me that customers are cautious when it comes to spending money. When they do, they want to spend with vendors that have a strong future. So, for longtail projects on SF, I’m not sure that the SF Marketplace will change much of this customer behaviour. Remember, downloads are a badge of credibility, something that longtail projects lack as you move further down the tail. So, if the SF Marketplace won’t drive a lot of revenue for longtail projects and the large projects on SF already have a Support & Service offering through the vendor site, what’s left for SF Marketplace?

I could be proven wrong, and maybe users of longtail SF projects will decide to fund future development through support purchases.

I wonder if SF Marketplace will allow me to see who is offering support & services for, say, Hibernate in one place (i.e. JBoss, Virtuas, Neward & Associates, etc.). But maybe the project owner would have a say in who can offer support for said project? :-)

It will definitely be interesting to see how customers adopt SF Marketplace & Red Hat Exchange.

 

More on Defining Community

I haven’t posted in a little while due to travel (who says offline RSS readers aren’t necessary) and my attention being elsewhere. But I’ve been catching up on some reading.

First I read this very interesting post from Shaun Connolly from JBoss in response to my questions about JBoss community.

Shaun says:

“Open source communities extend beyond those who interact directly on the open source projects, mailing lists and forums, and include the users, customers and partners in a wide variety of ways. In my opinion, there are neighborhoods within the larger community that have their own perspectives and ways of interacting with the larger community.”

I really like the neighborhood approach that Shaun suggests - I’ll need to think more about this one. I’m just not sure how or why third party users, customers and partners would be differently motivated than third parties who “interact directly on the open source projects”. Aren’t third party contributors users or partners, or don’t they sit inside of a customer shop?

The point that Shaun makes about how Red Hat serves expands and recognizes their community could very well have been written by IBM, Oracle, Microsoft or any other traditional software vendor. Not surprising considering how Red Hat tracks with traditional software vendors in many aspects of their business.

Then I read “My thoughts on communities backed by companies” from Jordi Mas, (linked via Matt’s Infoworld blog). Jordi poses a few questions to rate how community driven your development is (regardless of whether you’re open source or not, because, as Jordi points out, Microsoft and other traditional vendors also have strong user communities).

Jordi poses questions like

“Is the product roadmap publicly available?” or “Do developers from outside your company have privileges to make changes on the code base based on their knowledge? (Meritocracy) Or are they second class citizens?”.

I like the questions, but what’s missing (and likely always will be) is a way to assign an importance rating for each question. So, what if the product roadmap isn’t publicly available, but commit privileges are dolled out based on merit? Does that make the company in question less, the same, or more “community driven” than a company with a public roadmap that only gives commit access to employees?

But clearly there is a difference between a community found at Apache, Eclipse or PHP.net than other communities. It’s just not easy to define.  But, that doesn’t mean we shouldn’t try.

 

Exadel Partnership - A Rose By Any Other Name

I purposely didn’t write about the Exadel partnership when it was announced as I wanted to get some more details on it. A week has passed and little has been written that furthers my understanding. And I must apologize for not emailing someone at JBoss to get some clarification (it’s been busy here). As such, I ask you to read the comments before finishing this post, in case one of my JBoss readers writes in to correct my take on the deal.

Here is the quote from the TSS discussion on this deal:

Sacha Labourey: “The Red Hat and Exadel partnership is twofold. First, Exadel will open source its commercial products — Exadel Studio Pro and RichFaces — at JBoss.org as Red Hat Studio Developer and JBoss RichFaces, respectively. Exadel is also moving its popular Ajax4jsf project, currently hosted on java.net, to JBoss.org, where it will become JBoss Ajax4jsf. Second, Red Hat and Exadel will continue developing the three projects going forward, including integration with existing JBoss platform technologies such as JBoss Seam. This ongoing development will be done under JBoss’s leadership.”

Then, JBoss/RH’s Gavin King comments:

“….. Seems like their (i.e. Exadel - added for clarity by Savio) business has actually worked out pretty damn well, given that we just paid them a whole bundle of money to get this deal done. ;-) This is not a typical case of a commercial vendor deciding to give away a product they couldn’t sell, in a last-ditch attempt to get users. Rather, this is an acquisition of successful technology, for money. It follows the model of JBoss Transactions, which was acquired from Arjuna, and JBoss ESB, which was acquired from Aviva. …..”

Am I off in left field when I think that this is little more than JBoss/RH acquiring technology from Exadel for a price? That the “….decided to open source the products at jboss.org” parts of the announcement are more about the cash that changed hands and less about validation of any community site? Reading Gavin’s comments leads me to think as much.

Don’t get me wrong, there is absolutely nothing wrong with that, acquisitions are a way of life in the software industry.

What doesn’t sit well with me is that the TSS Q&A with Sacha and the JBoss/RH Q&A about the deal don’t really clarify if:

• (A) Exadel decided to open source their products and choose the JBoss/RH community because of its strategic fit with Exadel goals or for whatever reason that Exadel would feel that one ‘community’ is better than another ‘community’
• (B) Exadel was paid to transfer their copyrights to JBoss/RH, and the open sourcing of Exadel products at JBoss/RH was part of the deal

I’m not the expert, but I don’t think that the Apache Software Foundation or Eclipse ever paid a 3rd party to decide to open source a product into the Apache or Eclipse community. When IBM acquired Gluecode, (which was building products on top of Apache Geronimo), we positioned the deal as what it was, an acquisition. Nice and clear.

Can anyone at JBoss/RH shed some light on who owns the copyrights to the code going forward? Because that should be a simple way of knowing if this was a 3rd party endorsing the JBoss/RH community or a 3rd party selling their IP to JBoss/RH.

Either way, it’s a business decision. But I don’t think it’s cool to paint an acquisition of technology as a partnership that endorses a community/external development site.