In this second part of the series, I will discuss what options Compiere has to go forward as an open source product and what prerequisites there are for building a thriving community. The indication for an active community are (user) contributions. In this blog, I will cover why people contributed to Compiere and why not.
In the first part of this blog series, I mentioned that one cause for the diminishing open source community for Compiere was the business model. Compiere started out as free product with revenue generation via services and evolved to a free open source trial/entry product with "real" commercial product and services (Open Core). As mentioned this model only causes conflicts with the community and also customers as they see it as nothing else than a free trial/entry product with restricted functionality or access with the ultimate goal being to 'upgrade to a paid or enterprise version. This 'try before you buy' method is today quite common in non-open source software products, so no advantage for using open source anymore.
One of the biggest assets of an open source product is a thriving community. As a user, you are not restricted to the vendor as source for information and help. Building an active community is not easy and depends on people contributing.
One of the origins came from the lack of (timely) support from the original vendor, so users helped each other. For some time, contributions were just found in open source projects, but today this is no longer true.
Commercial products like SAP and Salesforce have a very active user community and in both cases, you get your question answered probably much faster if you use the support forums then via the formal technical support. Also most product's documentation is provided as Wiki, so that users can make comments and with that contribute to the quality of the documentation. In many cases, commercial companies also now let their users vote on "ideas" (functional improvements) and bug priority. The community of users have always been 'testers' by reporting bugs, and many companies now include customers in focus groups.
So, the only unique domain of contributions left for open source are code contributions (with the restriction that if you get the source as part of the commercial product, companies may also get suggested bug fixes).
In the first part of this blog series, I mentioned that one cause for the diminishing open source community for Compiere was the business model. Compiere started out as free product with revenue generation via services and evolved to a free open source trial/entry product with "real" commercial product and services (Open Core). As mentioned this model only causes conflicts with the community and also customers as they see it as nothing else than a free trial/entry product with restricted functionality or access with the ultimate goal being to 'upgrade to a paid or enterprise version. This 'try before you buy' method is today quite common in non-open source software products, so no advantage for using open source anymore.
One of the biggest assets of an open source product is a thriving community. As a user, you are not restricted to the vendor as source for information and help. Building an active community is not easy and depends on people contributing.
Contributions today
Contributions are the major aspect of open source. The main areas of contributions are support, documentation, testing and functional improvements.One of the origins came from the lack of (timely) support from the original vendor, so users helped each other. For some time, contributions were just found in open source projects, but today this is no longer true.
Commercial products like SAP and Salesforce have a very active user community and in both cases, you get your question answered probably much faster if you use the support forums then via the formal technical support. Also most product's documentation is provided as Wiki, so that users can make comments and with that contribute to the quality of the documentation. In many cases, commercial companies also now let their users vote on "ideas" (functional improvements) and bug priority. The community of users have always been 'testers' by reporting bugs, and many companies now include customers in focus groups.
So, the only unique domain of contributions left for open source are code contributions (with the restriction that if you get the source as part of the commercial product, companies may also get suggested bug fixes).
Contributions in Open Source
The biggest source of contributions in Open Source are the staff contributions of commercial companies to open source projects (i.e. you get paid to do open source development). These open source projects are most often in the "platform" and infrastructure area. The best known are Linux, Apache, etc. mainly to compete against Microsoft offerings.Another big area are industry standards (example Java JSR's), where the different vendors of competing commercial products pool resources for a basic (reference) implementation - to foster the adoption of their technology.
So, the basic motivation here is simply marketing - to make your technology/product more attractive to adopt.
The dynamics of open source code contributions
Let's assume there is a open source word processor, you are using for your work. You require a particular way to underline words, so you add a cool underlining functionality. So what can you do with it? Use it yourself, but no chance of selling it. So, your motivation to contribute is very high, you may be even get some fame for your work or can use it as a "reference" in your CV.Fact:
People only contribute, if they cannot monetize the work.
You provide a free product/contribution in exchange for free publicity / marketing.
- bug fixes / testing
- design / approach / requirements / user-priority
- people did not want to maintain the functionality (e.g. could not monetize it)
Open Source must be free (for me)!
In general, in the lifetime of Compiere I got more contributions from the few end-user companies than from the many (reselling) partners. One would think that partners would be happy to contribute bug fixes, but I came to learn that some used the bugs they fixed against Compiere with a message like "You don't want to use the buggy free open source version but our stable release which you only get from me".The motivation for an ISV or VAR to contribute business functionality is VERY limited, as they want to provide a solution with a market value. The most valuable contributions I received were help with validating (business) requirements and designs. People were motivated here because as a result they expect a more usable product.
The general mindset I found was: everything from Compiere should be free, but you have to pay for what I (the partner) did. I have to say that this mindset evolved. In the beginning, we received, for example, many translation contributions, but as Compiere grew and became popular that stopped. Partners and others were selling Compiere with a language translation and sometimes with some minor localizations. At one point, there were 4 French translations - each was only available if you bought services from these provider.
The most blunt example was when the founders of OpenBravo approached me with the suggestion: For $50k you can buy the enhanced HTML user interface we built (as a university student assignment). When I refused with the hint that maybe it is payback time for the free Compiere product they enjoyed, they bluntly said: if you don't pay, we'll fork Compiere. And so they did months later after receiving some funds from the Spanish government. (Technically I also did not like their product as they went back to the old-fashioned Case Generation model of the mid 1980's rather than the Compiere's dynamic/active dictionary model)
OpenBravo were not the only guys who offered a web user interface for a payment, The University of Champlain also had an improved UI as a student project, but wanted just $20k for the best design and sharing the experience of that project. After the refusal of payment, they did not publish it nor share their experiences or suggestions.
The motivation for the Adempiere fork was, in my opinion, also purely commercial. People are generally in the open source area if you don't want to pay (or cannot pay) - and/or if you want to be independent from your vendor. The latter is certainly a motivation in business applications, if you pay 20%+ maintenance fee and if you perceive to get little value in return. As a Compiere reseller (= partner) every cent you pay to the open source vendor cuts directly into your bottom line. The value the open source vendor provides - innovation and produce stable releases - is regarded as god given or act of nature. As a matter of fact, the most successful open source projects are sponsored by companies to provide alternatives against their competition (e.g. Eclipse vs. MS Visual Studio) to promote their platform - and you can expect that you get Eclipse for fee.
Getting back to the motivation for Adempiere to fork: In early 2006 I changed the license from MPL to GPL. My motivation was to get a fairer share of the value Compiere generated and there are not many reasons to argue against the first and primary open source license. Consequently, there were virtually no objections or discussions voiced in the community and many partners acknowledged the fact that partners should pay their fair share. So, after accepting Venture Capital some people realized that they had to pay in future, so they forked (based on the MPL code). The official reason was that "Jorg does not accept contributions", but I believe it was driven by the attribution clause in the GPL license. Nevertheless, as Compiere got more expensive and "closed" many partners and users were driven towards Adempiere.
If you check out Adempiere, after the first enthusiasm, they basically struggled with the same issues - partners did not contribute, no one wanted to do the grunt work of producing a release for free.
Why it was difficult to contribute to Compiere
Well after venting a bit - actually it was not easy to contribute code to Compiere. Main reason was that there was only one source repository line - no branches - and if there was a fix required, it was done in the main code.
The motivation for this was my mantra of a single version. One of the challenges of ERP vendors is supporting many old versions as customers are hesitant to move to the newest version. For an open source project that is unsustainable, so for me the current version must be easy to migrate to - and for that has to be absolutely stable. This imperative resulted in high productivity and VERY stable daily builds as that was the patch delivery mechanism.Our recommendation was that to implement a fix you use the latest build of the current source version. In the beginning people were a bit uncomfortable, but due to the lack of alternatives and the fact that it worked, it was widely accepted and adopted. If the code was not stable, I did not commit and there was no daily build that day. Consequently, I became a bit hesitant to accept contributions - especially after several instances where I had to 'clean up' contributions to stabilize the code. The worst case resulted in a week of my time to correct a bug fix contribution.
Stable code is the objective for everyone. Current code is the promise of open source. Compiere (as some other open source projects) evolved to provide the code with a delay (i.e. commercial product immediately - open source product 3 months later). This is a clear message to the community: stay out of it - and your contributions will be outdated anyway. So you use your customers to stabilize the code - not the open source community.
Compiere also did not invest enough in an infrastructure to be able to welcome contributions. Automated testing was actually the area I was eagerly seeking for contributions - without luck. As a consequence, for some time now I have adopted a test driven design as my main development methodology.
What will enable and encourage code contributions?
The primary prerequisite is a current line of code - do availability delays.To contribute to a complex project is not easy, so there must be a automatic safety net to protect the project. One of the solutions is automatic tests. Compiere used JUnit in some areas, but in general automatic testing for data driven is not easy. Today, TestNG and Code Review products will enable easier contribution.
In addition to that, I think the project must be a commodity, infrastructure or tool software. Something you want/need to use but does not directly provides a monetizable result/product. If there could be a commercial motivation for users to hold back code, the interests of the open source vendor will always be in conflict with the user community and the product/project will suffer.
In a next blog, I will discuss concrete options of how to revitalize the Compiere project.
