All we had to do was purchase the software and several licenses and see how we liked it. We could do the implementation ourselves, at our pace. Overall, xTuple gave us alternatives that no other vendor could.
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.
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.