Frequently Asked Questions - How Open Source ERP Works

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 and with modular add-ins (more on that later!) - than in trying to duplicate the tested and battle-hardened functionality in the commercial Editions.

This is our favorite question. The answer is, there are lots of ways - but the most important thing is that we work collaboratively. If you've got the technical expertise, you can write new functionality yourself. You can pay one of our partners to do it. Or you can pay us. Sometimes, there's a big enough chunk of work that we put together a consortium, where several customers can split the cost of developing something new. This approach worked very well for the CRM module in version 2, and the Returns and Service functionality in version 3. Usually, a simple feature request in the issue tracker is the best way to get started. If we decide that a more detailed specification is needed, there is a template that we use as a starting point.

The best part? When you work with us to add new features into the product, you get exactly what you need, implemented into the core system - ensuring that your investment will be future-proof, rather than a one-off customization. Read about our "Greatest Hits" - 13 great examples of this process in action.

There are a number of elements that go into localizing an ERP system. The first, perhaps, is language. Each xTuple ERP client loads a translation file at runtime, so one user can see the application in US English - for example - while others see it in Mexican Spanish, Simplified Chinese, etc. Please visit our Translation Portal to see the current status of the many xTuple ERP international translation efforts. We'd welcome your involvement! The other major element of localization is the accounting, tax, or other local business requirements of a particular market. You might have a look at our wiki for an introduction to our multi-layered tax functionality. Perhaps the best place to start would be a discussion in our International Forums.

xTuple ERP includes powerful tools that can help you deploy an ERP solution that meets the exact requirements of your business.  For most major functionality, our preference is to include the solution in the main, supported product.  That way, no one has to worry about maintaining custom software.  But there are situations where an extremely narrow requirement exists, perhaps a unique business process that needs to be mirrored in the software.  These situations are good candidates for a scripted approach - custom screens built with the xTuple ERP Screen Builder and Qt's implementation of Javascript. We called these scripts "extensions."

Customers can develop their own screens and scripts; they can also have xTuple-trained partners do that work for them.  If the customer engages xTuple itself to develop custom screens and scripts, our policy is that they will be certified for the current release of xTuple ERP only.  That is, there may be minor tweaks required to keep custom scripts working 100% in future versions of the base product.  If xTuple were to do that tweaking, it would be a separate services engagement.

The same rule applies for custom reports built with the integrated OpenRPT report writer.  In both cases, the skills required to build and maintain these custom elements are fairly common - standard SQL for database reporting, and XML and Javascript for custom screens.  It's a good line of business for xTuple partners serving customers who do not have these basic IT skills in-house.  Our goal is not so much to have xTuple maintaining a multitude of customized enhancements, but rather to have as many people as possible using the tools to provide this last 1% of the solution.

mead