Thursday, June 14, 2007

Thoughts on OFBiz Derivative Works, the PMC, and Opentaps Past and Present

In the email Si sent about resigning from the PMC he referenced reasons described in emails between Si and Andrew. I got with Andrew to review these and just wanted to comment briefly on them and what seems to be the issue.

From my point of view this is just the most recent incarnation of a problem that has been around for at least a couple of years now, and I've been more concerned over time about it but had decided to give it time and see how things have progressed. Initially this started with the financials module that was developed as an investment to be licensed for income until the development cost was recovered, but Si at one point decided he would rather put what Undersun had worked on back into OFBiz, and take full ownership of the rest to dual license (commercial and GPL open source). This resulted in something that is core to the mission of OFBiz being part of an outside project, which at the time seemed a reasonable compromise.

At the time and at various times since then I have had conversations with Si to warn him that this is not a tenable long term business model and eventually something would be developed as part of OFBiz to satisfy these requirements and encouraged him to consider licensing these back to OFBiz to be included in the project should a large user come along that had a sufficient budget and desire to re-develop it anyway.

Over time the scope of the financials application expanded to include refactorings and rewrite of functionality in OFBiz. The crmsfa component was also added to implement a SalesForce or SugarCRM type of sales management application (this was a piece that was originally designed for a client and proposed to be added back to OFBiz, but Si underbid the implementation to retain the IP and add it to the dual-licensed modules. More recently additional modules and rewrites have been added to the Open Source Strategies library of OFBiz extensions.

The reason these have become a problem is because they are within the established scope for OFBiz and this represent a competition for resources to build and maintain them. Various people have complained to me personally about this, and a few times various people have complained more generally on the OFBiz mailing lists. Things that have prompted these complaints include things like: requests on the OFBiz mailing lists for people to work on and contribute to opentaps/OSS components instead of to OFBiz, statements that represent the scope of OFBiz being limited to not conflict with what is being developed by Open Source Strategies (ie that it is a low level set of tools and application elements and not meant to be used by end users), statements about the nature of the OFBiz community and management process, etc.

I spent a bit of time with Andrew reviewing the emails between Andrew and Si. The main thing Andrew was complaining about was this conflict of interest and that it did not seem appropriate for someone to be on the OFBiz management committee who was, in order to further their own business interests, was trying to limit the scope of the project and recruit resources from the project community. Based on this Andrew expressed to Si that PMC members really should be advocates of the project and not send mixed messages, so it might be best to resign from the PMC if we was going to continue and expand these operations.

It should be noted that this was not a request by the OFBiz PMC in any official way, or even by Andrew as I understand it, but rather communication between two PMC members about a concern over something that is having an impact on the project. That said, as should be clear by my short history behind this conflict I definitely agree with Andrew that it is a problem and I think it is good as it is starting to have a greater impact that something was done.

Back to my thoughts on this... Part of the motivation for choosing the MIT license originally, and moving to the Apache 2.0 license as part of the ASF move, was to facilitate use of the software and participation in the project by a large number and variety of individuals and organizations (Person and PartyGroup in OFBiz lingo ;) ).

This means that according to the license what Open Source Strategies is doing is totally fine. From a community building perspective I think it is also okay as it is better than nothing. In other words if this is the only way we can get help from the people at Open Source Strategies, then so be it, we'll still take it! This is why I personally have decided not to do anything about this. Of course, the more they separate from OFBiz and fork certain components the less this will be true, and at some point the competition and dilution of resources that might contribute to OFBiz is more than the benefit to OFBiz from the indirect use.

I don't know if we've reached that point with either Neogia or Opentaps, which are the two main projects based on OFBiz that have forked certain parts, and extended independent of OFBiz. The reason I say that is that the OFBiz community is still strong and making good progress and is in fact growing rapidly and getting a lot of end user attention that is translating into even more contributor attention. We are also seeing a trend that those experienced with OFBiz are doing more dedicated work based on OFBiz and that is resulting in more contributions and more time spent on the project.

In general less involved users like this are great for the project, but really in order for the project to progress and fill the intended scope we need contributor individuals and organizations that practice a process of operation that meets client requirements by starting with generic development that goes back into OFBiz, and then continues with configuration or customization to meet the non-generic aspects of the requirements.

As for what is best for businesses trying to make a profit while working with the open source project, there are many models and many of them are viable and sustainable, and which one is best for the company the market (the customers) is yet to be seen. Here are some of them (a small selection):

1. dual licensed components or whole applications (commercial and generally GPL on the open source side, though opentaps using HPL which is more restrictive AND which is not truly "open source" as it is NOT OSI approved)
1.a. general purpose software
1.b. industry (niche industry or business type) specific solutions

2. commercial derivative works
2.a. general purpose software
2.b. industry (niche industry or business type) specific solutions

3. services and custom solutions

Based on talking with a lot of people there seems to be a continuum of opinion about open source versus commercial development models. To be clear, for this to make sense the goal is to create and maintain software that individuals or organizations can use. We're not talking about how to make a company that can produce a profit, but rather create an organization and collaboration model for the creation and maintenance and use of software. Some are totally on the open source side and think that is the answer to every question. Some are on the commercial side and believe _that_ is the answer to every question. Think of it kind of like the Kinsey scale, and just as with the Kinsey scale most people fall somewhere around one side or the other but not right at either side, and not so much right in the middle either. Perhaps someday this scale will have an official name and even an official diagnosis test to determine where someone's opinions lie on the scale. This might be an ente
rtaining research project.

At Hotwax Media, Inc. we have chosen #3 for now and we are growing quickly and having great success with a growingly impressive set of sites and companies we are working with. We believe, and are proving, that this is the best model for our company and for OFBiz itself as well. It allows us to stay close to the project, collaborate well with others, efficiently meet client requirements, and contribute major sets of functionality back to OFBiz. We are also working on extending OFBiz to implement software to support our own operations and make them more efficient, and that means even more goes back to the project, and is cheaper for us to develop and maintain.

I should make it clear that another commercial model that I've had in mind since the beginning of OFBiz is to create commercial derivative works for niche industries based on the generic open source software. The idea here is that the open source model doesn't work so well because in many industries the companies are too small and need too much software to customize it for a single business or for people from the various companies to collaborate on creating the software.

In other words many prospective users of OFBiz just can't effectively use the generic software as it is OOTB because it is way more than the need and probably too much for them to maintain as well. In order for those companies to use OFBiz they will need something customized for their type of business, and unable to collaborate directly in creating and maintaining that what makes the most sense is to collaborate through commercial means. Given the basis on open source generic enterprise applications these solutions can compete well because for a reasonable development expense something that targets a very specific market can be created. The customer gets a system that effectively automates all information management they need while still remaining highly affordable. Of course, this model is mostly theoretical as only very little has been done with it so far...

No comments: