Frequently Asked Questions

What's in a name? Or, why "xTuple"?

Good question. Renaming a company and launching a new brand is not something anyone should undertake lightly. But we felt that with the expanded line of products and services, and a broadening of our target audience to include companies who might not do much actual manufacturing, the time was right. We were looking for something exciting, that speaks powerfully to the possibilty for exponential growth in the key business metrics that are important to our customers. Double, quadruple, quintuple ... xTuple.

There's also, we confess, a bit of a geek insider joke here (there always is, with software companies). In computer science and mathematics, a "tuple" is a name for any two or more points of data that you wish to analyze. In fact, in database circles, rows of the database are often referred to as tuples. So it's ex-tuple, from the database. Get it? You don't? Well, never mind! :)

What's wrong with OpenMFG? Does this mean you're scaling back your commitment to manufacturers?

Goodness, no! OpenMFG continues to be our flagship product, and our licensing and pricing for it is unaffected by all this excitement. Quite the contrary, our support of manufacturers has never been stronger - here's why. Very simply, it is the most advanced manufacturing functionality that constitutes most of the difference between the free PostBooks product and the paid OpenMFG product. That has two very significant implications for manufacturing:

1. Our biggest paying customers will continue to be manufacturers, and we will do everything in our power to make sure they are deliriously happy with the OpenMFG product and level of service they receive.

2. In order for us to continue to command a premium for the OpenMFG product, we will have to keep innovating - and adding advanced functionality that the larger PostBooks community might not find interesting or necessary.

So what are the differences between OpenMFG and PostBooks anyway?

There's a detailed comparison, and an explanation of how we manage both products simultaneously, here.

Why would I pay for OpenMFG when PostBooks is out there for free? And there's an open source community working on PostBooks. Won't the child surpass the parent at some point?

In all honesty - maybe. That's part of what a software vendor has to get comfortable with in open source, especially if they're pursuing a dual-licensing model like we are. Fundamentally, we believe it will come down to how well we do our jobs managing the PostBooks community. If we're unresponsive, don't give a good sense of overall roadmap and guidance, or needlessly antagonize community members, there's a good chance the project will be "forked" ... and maybe someone will start a PostPostBooks project.

But our hunch is that there's a much bigger interest in expanding PostBooks horizontally - into adjacent markets such as distribution, retail, professional services, government, nonprofits, and the like - than in trying to duplicate the comparatively narrow, vertical manufacturing functionality that is the focus of OpenMFG. Plus, let's be honest - manufacturing is hard. There's a reason that all those low-end commercial accounting packages have stinky manufacturing functionality - it's hard, and messy, to try and bolt it on after the fact. We believe that we'll be able to continue to make a compelling case to the manufacturing world that OpenMFG is worth paying for. And if we don't, shame on us.

Do you publish your pricing?

Yes, all of it. Here.

What about local VARs and solution providers? Where do they fit into all of this?

Simple answer: they are more important than ever. There is a temptation with free software to think that you can do it all yourself - download, install, and have the business up and running on the new software before you know it. It's easy, right? Just read the documentation, follow the basic steps, and presto!

That sound you're hearing is the gnashing of teeth by experienced ERP professionals around the world. You may be aware of the widely-publicized statistic that over 80% of ERP implementation projects - in companies of all sizes - fail, and often spectacularly. We're software people with what we believe is a pretty strong product, so we like to believe that software choice has a lot to do with it. And it's certainly a significant piece of the puzzle; despite everything we say about rising commoditization of software, not all ERPs are created equal. And many get worse over time!

But the simple fact of the matter is that the human component of an ERP implementation is by far the most important. By that, we mean developing and following a firm project plan, with strong buy-in from management, and strong leadership of the overall project effort. Business process assessment, data migration and entry, configuration and setup of hundreds of details that supports the observed and desired business processes... these are the kind of things that xTuple business partners have been doing for decades.

Whether you're considering OpenMFG or PostBooks, we urge you to reach out to an xTuple business partner first. Or, if you prefer, talk to us - and we'll work with our partners to put together the right combination of resources that fits your goals, and your budget.