In Part I of this 3-part series we noted the importance of finding an open source service provider that serves companies of your size and type with the specific services you need. In Part 2 we considered the “engagement model”, and gave examples of how misalignment in that area can trip you up.

We close in Part 3 with an important consideration that is very specific to open source: the relationship between the service provider and the open source vendor.  In this article we focus specifically on the case of an ERP project being used by  enterprise (mid to large) customers, a scenario where we have extensive direct experience.

Why does this relationship matter? The reason is that as a customer commits strategically to an open source project, the value of collaborating around core code contributions becomes apparent. Here is the reality of open source ERP use by enterprise customers:

1. Some functional and / or performance gaps are very likely to be identified as a large customer increases it’s use of the platform over time
2. Depending on the particular issue, it can make more sense for the open source vendor to create and maintain the code (vs. the partner or customer)

The reason for 2 is that some functionality is inherently “core” by nature due to its functional and technical dependencies with the rest of the ERP system. In such cases the core ERP platform team is the best group to develop and maintain the feature over time. The service provider could deliver the functionality in a very custom way, but sometimes a generalized implementation of the functionality makes business sense for everyone.

For example, in the case of Openbravo we have a large customer who needed to manage significant quantities of hierarchical master file information (a hierarchy of 10s of thousands of categories, up to 8 levels deep, cross-referenced to an Item table with several million rows). The standard Openbravo tree control was not designed to handle such data volumes, and did not include the required searching and selection functionality.

As a partner with a close relationship to Openbravo, Agility ERP was able to define and execute a collaborative development project that achieved these goals:

• Deliver the required functionality to the customer as a generalized feature, without any custom code at all (only application dictionary configuration)
• Relieve the customer of any future maintenance burden
• Enrich the core Openbravo platform with capabilities that are useful to other enterprise customers, via this customer-funded development that Openbravo incorporated into their roadmap.

The Agility ERP role in this transaction was to:

1. Identify and formally document the need with the customer
2. Establish feasibility of a sponsored development option with Openbravo
3. Present options to the customer for both a specific custom solution and a generic sponsored development option
4. Co-design the general solution with Openbravo to ensure that the specific customer need is met and that the solution will work generically for all other customers
5. Provide Openbravo with a copy of the customer’s Oracle database to enable testing on a large, real world dataset
6. Work with Openbravo to configure and test the solution on behalf of the customer
7. Apply the patch from Openbravo on the specific customer release, and train the customer on the new feature
8. When this feature became a part of Openbravo core platform, upgrade the customer and remove the temporary patch

Even though Openbravo is very modular, the fact is that some features require close collaboration with the Openbravo core team in order to be successfully implemented in a sustainable way. Agility ERP has that close relationship with Openbravo, and routinely brokers such efforts on behalf of our customers (see here for other examples).

So, can’t your staff engage directly with the open source vendor?  It all depends. In the case of Openbravo, their business model is to work through partners, not to engage end customers directly.

 Note: Hypothetically, if your requirements are basic (and not likely to change in the future), you may not ever require this type of collaboration option. Regardless of your partner choice, however, one thing you should always do is fully understand the project roadmap before contracting your open source service provider to build custom functionality. Open source projects tend to release new functionality quite often (Openbravo does so 4 times per year), so your gap may be filled by simply waiting–and working through your service provider to ensure that the roadmap feature delivered by the vendor will meet your specific needs.

In many cases the appropriate course of action is for the service provider to directly deliver a customer-specific extension, and not engage the open source vendor (which typically involves a longer lead time and greater expense to deliver a more general solution). The point is that sometimes the standard approach is not the appropriate course of action, and following it can lead to narrow, brittle functionality that incurs significant costs at upgrade time (and may not fully satisfy the end users).

So, if you plan to use a commercial open source platform strategically, you must be able to collaborate effectively with the core development team. In many cases that will be through your service provider, so make sure your provider has a good working relationship with the team, and a track record of collaborative development to prove it.

Conclusion

Open source projects can be a strategic asset and a source of great competitive advantage for organizations that understand the value of a best in class open source platform, and how to unlock that value over time. If SaaS is a 5km race, then open source can be more like a marathon–it may take more time and effort, but the payoff at the finish line is much bigger. To use open source strategically, you will need an experienced partner that will be there to provide you with the right services at the right times, to successfully go live and keep you on the route to success.

 The right partner can be the difference between success and failure–especially for large, cross-functional projects like ERP–and it can be expensive to have to switch horses in mid-stream. So don’t be afraid to fill out a contact form or directly pick up the phone and ask the 3 important questions we’ve identified in this series of Agility ERP blog posts.