Open Source Community Collaboration Best Practices

WARNING: This is a long post, approaching a dissertation on the topic. I recommend that you glance over the headings, and then go get some tea and cakes, coffee and donuts, or whatever it is you enjoy consuming casually while having your brain tickled.

The Best of Practices

The title to this article falls a little bit short of accurate... I actually only want to talk about a single best practice that seems to consistently determine whether or not an interaction with others in the community will be successful or not. The idea of this give and take is really simple, and goes back to the basic definition of collaboration:

1. the action of working with someone to produce or create something

2. traitorous cooperation with an enemy

Both parts of this definition are interesting, because the practice that leads to success in community collaboration is one that aligns well with #1 and avoids any appearance of #2. On either side of the definition it comes down to who you choose to collaborate with, and that's the most important thing to keep in mind in an open source project: you are collaborating with people and expecting to both give and take as part of your interactions with them.

If you want other people to collaborate with you, first you need to collaborate with them. If you are hoping for some benefit of the collaboration you first need to set the stage for the collaboration and invite others to collaborate by starting first and giving what you have, then invite others to get involved. The important thing to keep in mind is that collaboration implies a two-way street and if you try to make it one way by not trying to collaborate with others, but still expecting them to collaborate with you, then you will most likely be disappointed by either no collaboration at all, or a good-will attempt by someone else to collaborate with you that will fail because no stage was set for the collaboration and they will likely help in a way you don't need.

Now a quick "anti-pattern" to explore what this implies... you may be wondering: "how can I be sure that other people will collaborate and I'm not just giving stuff away and will never get anything back?" That issue is certainly one that stands in the way of collaboration and basically represents a lack of confidence in the possibility of collaboration. The problem is that if you are unwilling to give it a chance and "cast your bread upon the waters" as it were, then there is not even a chance that you will be the fortunate recipient of collaboration in return.

If you can't give for the sake of fostering collaboration and good will, then community collaboration may not be for you. The best path may be to continue to collaborate through the financial and legal means that are the common operating mode of commercial software and result in a very inefficient form of collaboration (if you can even call it collaboration) that causes many of the problems that people and organizations face with the software they currently use. Unfortunately many commercial software organizations would consider open source collaboration to be firmly in the camp of definition #2 above.

One good concept to keep in mind when working with others is the "burden of proof." A good way to be generous with others and to make it clear to others that you are putting efforts into collaboration is to take upon yourself the burden of proof, and not ask others to take it on. When you do this you will communicate more clearly and others will tend to reciprocate and do their own research, puts their thoughts and effort into it, and make things flow back and forth more smoothly. What this means in daily practice is usually to just research things well and before proposing something or asking a question thoroughly present your research, including references and links where possible. In the Apache OFBiz Committer's Best Practices Guide this is referred to as "read before you write" and the burden of proof concept takes it one step further to sharing with others what you read so that you can collaborate on the writing side of things.

A Case for Collaboration

This reminds me of a quote from a movie scene (whose name I can't remember and google isn't helping): "Qui bono?" The line is from an old politician who has a clear set of priorities. I'm not referring to the "Qui bono" line from The Departed, though that one is more entertaining, and I guess almost equally as enlightening. Whatever the case, the point is: who benefits? I suppose the point from The Departed is also appropriate: who cares?

Commercial software organizations operate under a specific model and that is very understandable from their perspective with their investors and a wide variety of stakeholders that they need to make a profit and leverage whatever assets they have available in order to do so. Software is often considered such an asset, and treating it that way is extremely well supported by modern intellectual property laws. So, is that a good model or a bad model? In the abstract I think that's impossible to answer, and it depends on whose perspective you are looking at.

What about the perspective of the end-user? Which approach best benefits the end-user (individual or organization)? Is there a conflict between what benefits software producers and consumers? My opinion on this topic is that again the answers depend on who you ask and that nearly all large commercial software producers will answer in their favor, and some end-users may as well (perhaps because they are influenced by marketing messages) though for the most part they will answer differently based on actual experience with those large commercial software producers.

All of that introduces a lot of complexity, and it is possible to look at the simple flow of information under the assertion that the more end-users have influence over software the better it will meet their needs. Through open source collaboration end-users can very directly influence the direction of the software by participating in the project and collaborating with other contributors and users. And what about the crazy things that some companies do? The collaboration tends to be very effective for filtering out or refining ideas that aren't so great. On the other hand, sometimes the "crazy" ideas turn out to be a differentiator for the company and result in a huge benefit over competitors. With open source software they have the flexibility to implement such things anyway (and do so efficiently) and even keep those changes private if they desire (well, unless the software is GPL licensed, which I would assert is not a good license for business software that is meant to be customized).

On a more day-to-day note direct collaboration is powerful in many situations that users and developers run into. It allows new users to get feedback on what they are trying to do and either open the way for new functionality or get recommendations on how to better use existing functionality. On the other end of the spectrum, it allows experienced users and contributors to get feedback on both their requirements, designs and implementation approach and ultimately results in far better software that will generally meet current needs better and also be more likely to handle changing future needs. In other words, whether you are experienced or not direct community collaboration can very efficiently help you to resolve issues that you face, and exploit opportunities that arise.

In short the ultimate reason for direct collaboration, as opposed to collaboration through financial and legal means, is that it results in software that better meets the needs of end-users (more flexible), better protects the interests of end-users (more private), and is also less costly for end-users. That reason will always be true.

Right now there is another reason to consider more direct collaboration and that is that commercial software companies have become massive entities with a lot of influence over governments as well as end-user organizations... and this means that they are able to put their own interests above those of end-users and get their way as much as they want. Very large end-user organizations can sometimes stand up to them, but that is still a small minority, even in this modern world of business. Shifting that balance to something more in favour of end-user organizations will make non-software commerce more efficient and allow software to be more an enabling industry instead of a controlling one and ultimately enable general economic growth and stability.

For commercial software vendors there doesn't have to be a conflict with open source collaboration. They don't HAVE to consider that collaboration to fall under definition #2 above. It may require some adjustments, and ultimately by better serving their end-users they will offer better solutions and keep clients and customers for the long term. The downside is the sacrifice of short-term profits and the ability to boost profits by pushing clients to buy things at certain points in time, like scheduling releases and upgrades to boost revenue or introduce separate products instead of adding features to existing products and including them in free service packs. End-users don't like such practices and if they perceive a viable alternative they will leave... so why not change practices and find more profitable approaches that also better serve the end-user who ultimately pays all of our bills...

Collaboration on Software

Going beyond general collaboration there are certain things that must be done to more effectively collaborate when working specifically on software.

The most important is to collaborate on designs and not just on implementation, keeping in mind that to collaborate you need to start out by collaborating with others and giving them a chance to collaborate with you. In the software world that means don't just implement something and throw it out for everyone to try to digest and react to. Instead, write up what you want to do and give other people a chance to send their feedback. Depending on the complexity of what you are working on this could take from days to weeks.

So why do this? Won't it just delay your work? Consider that if you create a design on your own chances are you'll forget things or not be aware of requirements that are common and important to that design. If you leave those out and implement something then sooner or later what you implement will be changed, or thrown out and re-written. Why is that? Because important requirements were left out of the initial design, and those requirements won't just go away. If you're lucky the requirements will have a small impact and won't require significant changes to the design or the implementation. However, especially if you are not trying to make things as broadly applicable as possible then it is easy to ignore big things that will impact the design a lot, and then it may be impossible to just refactor and extend the implementation to support the new design.

How can we avoid this? The answer, as would be expected in an article about collaboration... is to collaborate in advance on requirements and get the design to a solid point before you start implementation. Your code will have a longer lifespan and almost always also be more useful to you and your clients.

Some Short How-To Scenarios

1. I want big feature XYZ to be developed and I would like to work with others on it to ensure the best possible design and so I don't have to implement all of it.

2. I want big feature ABC to be developed and I'm not a developer so I can't help with development.

3. I have a question and I'd like to get an answer through the community (I can't afford to pay someone to support me, or I think this is an issue that the community should address).

4. There is something that exists in the software that I think should work differently.

For all of these the pattern is the same. Start with research on what exists in OFBiz, the requirements driving what you want, what can already be done and what can't be done or that you can't figure out how to do, then present your findings and requests for help and collaboration that you would like to see happen.

Collaboration Anti-Patterns

In the software world one way to clearly not collaborate is to totally rewrite something instead of improving something that exists, especially if this involves no attempt to understand what already exists and make sure that the replacement is sufficiently better to be worth the change and also does everything that the old stuff did. To understand more of why this is bad for collaboration, and sometimes bad for design and implementation as well, consider some of the things that you would be implicitly doing:

1. throwing away the feedback (or potential feedback) from others on the mailing lists

2. throwing away the various fixes and improvements that people have put in

3. in doing #1 and #2 you are making it impossible for people to collaborate with you... as much as many people are trying when you take this approach you are not allowing people to do so

4. large scale re-writes when there are issues instead of addressing the issues usually results in things NEVER becoming refined (since the focus is on starting over instead of on refinement), and in addition leaves a very large wake of orphaned code

Final Summary

In short the best way to collaborate with others, especially in a volunteer situation like an open source project, is to start by investing in the direction you want and then giving that investment away and soliciting involvement from others (including a write up on what you've done and your vision of what it can/should be and perhaps even on how others might get involved). By "casting your bread upon the waters" in this way you open the way for others to join in and give back, to collaborate back with you. Others may not collaborate back in the way or on the timeline that you had in mind, so be patient on both aspects. Consider what others suggest and appreciate their suggestions and discuss them in the open. This will foster more collaboration and allow the end result to be far superior to what you are capable of on your own... no matter how talented and/or experienced you are.

This direct collaboration model is a powerful way of getting things done and maintaining them over long periods of time in inherently stable ways. It enables a high degree of innovation and eventually results in solutions that are eventually clean and efficient and effective. Again, be patient with it as things are generally not perfect on the first pass or during the height of the collaboration activity, but rather when the collaboration has taken its course.

A Time for Change

I have had the pleasure of working with a number of great people over the 8 years I've been involved with OFBiz. For the last 2.5 years I've been a part of a great and growing company, Hotwax Media, and it has been amazing to see the number of people involved with Apache OFBiz increase as well as the work done over the years (including excellent custom work and a large number of contributions back to the open source project).

Much of the world seems to be changing right now and more changes are coming as people adjust their priorities and move on to new opportunities. For me personally the time has certainly come to make some changes. I'm cutting back on both expenses and investments, and getting back to what I know best and enjoy doing most: independent consulting.

On Saturday June 6th I resigned from Hotwax Media, leaving behind a great group of people and even some cash on the table, and moving toward the many and growing opportunities for doing other OFBiz-related work. Apache OFBiz is a great solution in an economic environment (similar to the one it started in) where organizations are moving back to core values and focusing on accomplishing their core objectives. In some cases that means doing more with less, and in nearly all cases it means doing more of what distinguishes the organization, and doing that requires more control over the business and the software that helps automate and manage it.

While it's been great working with the people at Hotwax and with many clients through the company, I miss working more with others in the community and seeing more of what other service providers and end-users are doing. I'm truly looking forward to doing work similar to what I did a few years ago and working with a larger group of individuals and organizations.

Along with this I'm also looking forward to putting more time and effort into new objectives for Apache OFBiz, including adding collaboration on requirements and designs to the existing highly successful collaboration on implementation, and along with that creating some applications meant to be used out-of-the-box by specific types of organizations or individual end-users.

If you think I might be able to help you with something you have going, please look at my web site at http://www.dejc.com/ for contact information and more details on the types of services I am offering.

Apache OFBiz at OSCON 2009

O'Reilly OSCON 2009 is taking place in San Jose, CA, USA on the 20-24 July 2009. For details on the conference see:

http://en.oreilly.com/oscon2009

Apache OFBiz was going to have a booth there but that has been cancelled because I was unable to line up enough resources to make it happen.

An OFBiz-related thing at the conference that is still happening is the presentation I will be giving on Thursday the 23rd at 2:35 PM. The title of the presentation is "Apache's Open For Business: Holistic Analysis and Design." For more details about the presentation please see the schedule here:

http://en.oreilly.com/oscon2009/public/schedule/detail/7453

I look forward to seeing everyone there and enjoying some conversation and collaboration during a bit of the Northern California Summer.

Apache OFBiz Community Building Tour - Mid-western USA, April 2009

As a follow-on to the April release branch, and to help encourage community growth and participation for Apache OFBiz, I'm planning a tour of the Mid-western United States. As part of this tour I'd like to visit with individuals and organizations who are current and prospective users, contributors, and others involved with or interested in OFBiz.

In these visits I will be available to spend 1-3 hours with you and answer questions about Apache OFBiz and how you can use it most effectively. I would be happy to speak with individuals or as many people from your organization as you would like.

If you would like to better leverage opportunities to collaborate with others in the community or there are specific things you'd like to see in OFBiz, or be able to do with OFBiz, this is a great time to chat about it. Also if you'd like general business level or technical help with the software I'm happy to go over those sorts of things as well.

I am doing this as the PMC Chair of Apache Open For Business with the intent of helping grow the community and not in my role as an officer of Hotwax Media. If you are interested in the services of Hotwax I'll be happy to briefly answer questions and refer you to the Hotwax sales people.

Below is the rough schedule I have in mind and the general areas I plan to be in. I'll be changing it as needed to accommodate what people are available for. If you're around these areas and available around these times, please let me know!

17 April (Fri): Omaha NE, Des Moines IA, Kansas City MO
20 April (Mon): St. Louis MO
22 April (Wed): Indianapolis IN, Louisville KY (maybe Chicago IL)
24 April (Fri): Memphis TN, Nashville TN
27 April (Mon): Dallas TX, Oklahoma City OK

Please contact me directly by email if you're interested in a visit. If you know of someone else who might be interested in a visit, please make an introduction and if they are interested I'm happy to play along. My schedule is flexible on this trip so morning, lunch and evening visits along with normal business hours are fine.

There is no fee for this, but I won't refuse a free meal if offered. I'm traveling in a 40' motorhome, so hints for parking somewhat nearby are also appreciated.

I am planning to do this in other areas in the near future, but don't have firm plans yet. The next likely area will be the north-western USA in July (around the time and place of OSCON which I'll be speaking at on July 23rd in San Jose, CA).

Re-Reference Post: Community versus Code and Glass Cathedrals

Some feeds missed this post (or weren't setup yet), so this is a short post to point back to it. There are some ideas of interest to the open source world, and as a bonus I've made an attempt at coining a new term: Glass Cathedral.

http://osofbiz.blogspot.com/2008/01/glass-cathedrals-and-community-versus.html

Glass Cathedrals and Community versus Code

Collaboration

From the proverbial "Day One" of thinking about OFBiz it was clear to me that I couldn't do it alone, and in the financial environment of the day (early 2001) it was also clear that there was no way I could raise the money necessary to make the dream a reality. That was especially true for me because I had nothing in my background other than a couple of years of research and failed commercial attempts to set me apart and make me of interest to prospective investors and partners.

Enterprise systems in general are large, complex things and require hundreds of thousands of man-hours to implement. On top of that with such a wide variety of businesses and real-world requirements designing something that would be flexible enough to be a good starting point and that would not require rewriting significant parts of the software would require a body of knowledge and experience that would be almost impossible to pay for. To start from scratch and build such a system would require a lot of collaboration.

The traditional means of collaboration in the commercial software world is to pay for a license and hopefully influence the vendor to add or fix things. There is little influence in this. Some vendors will accept payment for development of specific features, but for the most part customizations and specific features are built outside of the core product and never shared. This is a very limiting form of collaboration.

I worked with open source software before getting into all of this enterprise systems stuff as part of a company called Lineo that was creating products for embedded systems based on Linux, and in college as well. While doing R&D for an ecommerce startup I also ran into a number of open source alternatives, but mostly in infrastructure software, there just wasn't anything real happening in enterprise automation at the time.

The collaboration problem and the open source solution seemed the perfect match. Collaboration through a non-profit, open source effort seemed like a significantly more efficient way to go about things that collaboration through commercial licensing and the often disposable results of consulting engagements. With no financial entanglements collaboration can focus on solving problems and creating solutions with a long life span. Speaking of life span, the likelihood of survival for a piece of software is much greater when no one company can fall and take the software with it.

And there was more. I saw quickly that in addition to making the development of such a system from scratch possible, it also made the results of the development effort far better than any individual or static team working in isolation ever could. I started to see the lack of funding and the necessity of working on contracts to survive as a great benefit to the effort rather than a distraction from it. In short if I had personally had all the time and money I needed to site in a room and build this system, or even just the framework part of the system, it would not be anything like the real world need driven framework and application set that it is today.

The collaboration was just amazing. So many people suggested things over time and even though the majority of the suggestion never yielded anything immediately fruitful, there were so many that were critical and that pushed us in the direction we wanted to go by paths we hadn't even considered. I'm comfortable admitting that there is no way I could have built OFBiz the way it is now on my own. Over time I have also learned to accept that in many cases things I built and thought were great were inferior to existing alternatives or ideas about better ways of doing things. In the first 2-3 years of OFBiz we threw out as many lines of code as we kept. There was continual housekeeping and refinement, and there still is today even though these days the patterns and practices are more established and tried and proven, so the need for this is less frequent (on a large scale at least...).

After running OFBiz this way for years there were various people and organizations involved and this means of collaboration was proving to be very successful and stable. We were certainly not the only ones to run a software project this way and in 2006 some people from the Apache Software Foundation approached us, recognizing the similarities in philosophy, and inviting us to join the ASF. The more I read about Apache the more I came to see things this way as well, and the more I could see that they had the same emphasis on how to structure an open source project that I had come to. The great thing was that they had a much better organization and much better legal infrastructure (including the Apache License 2.0).

One of the main tenets of the Apache Software Foundation is that the community is the most important thing, and if you get that right then good code and other things naturally follow. In other words, if people are brought together in a way that enables minimally encumbered collaboration they will create something good, and something far better than if that collaboration had not been present.

Code

This may seem obvious to many people these days. These sorts of concepts have come a long way in recent years, even outside of the once fairly limited open source development circles. So why am I bringing this up now, and writing about all of this nearly 7 years after the inception of OFBiz?

The answer is that the principles and efforts of community driven open source projects have as much impact today as ever, and are a key to distinguishing efforts in the so called "open source" world.

There are some in the real open source world that don't focus on community and collaboration, and suffer because of it. One big potential problem for open source projects is a forked code base, or more importantly: a forked community. Sometimes a community degenerates or there never really was a strong community at all and a fork is appropriate.

In many cases though people fail to recognize the importance and value of the community and collaboration within it. For whatever reason they decide that they can do better on their own (often along with select others). They decide that the code is more important than the community.

In the OFBiz world there are various examples this failure to collaborate resulting in projects largely based on OFBiz but that have chosen to go in different directions. Many of these are open source projects, but organized and licensed in a way that fails to enable the collaboration necessary for success.

Glass Cathedrals

That's the main point of this blog entry, but I have a little more on my mind related to this and commercial dual licensing and the GPL license, and of course the dozens of variations on the license.

In general I agree with the ideals behind the GPL and the philosophy of Richard Stallman and others he works with on this. The idea of making software free and keeping it free is great, especially for certain types of software like infrastructure software that is used en-masse but not frequently customized (ie the improvements are nearly always generic enough to be shared). The reason that I originally pushed for the MIT license, and later the Apache License 2.0, is that these are more commercial and proprietary derivative work friendly licenses. When creating software that is meant to be customized it wouldn't be wise to legally or technically encumber those efforts.

What I really wonder is what Richard Stallman thinks about the practice of dual-licensing using the GPL and a commercial license. For these sorts of so called "open source" projects the only reason they want to use the GPL is its terms are the most onerous and are most likely to lead people to pay for a commercial license. In my opinion this is a deceitful corruption of valuable open source principles.

The development on these products (not really open source projects...) is generally done by a small group of paid designers and developers and there is little community interaction. Many choose to collaborate only financially instead of bringing their unique requirements and ideas to the table to enhance the core project. There isn't a lot of incentive to try to contribute back or collaborate when it is made clear from the beginning that there is one player who wants to own everything and that you don't really have a chance of being that player or competing with them in their own game.

The code becomes more important than the community. It's a bit like putting the cart before the horse in that there is a failure to realize the cause and effect and an attempt to get the affect (the code) with the cause (the collaboration in the community).

This is a major case where the use of the GPL breaks down collaboration instead of enabling it. This does happen in purely open source projects as well though, with GPL and other licenses too. Eric Raymond wrote a lot about this with his parables of cathedrals and bazaars. With cathedrals collaboration is limited and that is the biggest problem, whereas the collaboration possible in the bazaar is the real power in the model.

I would argue that this happens even with publicly developed open source projects if there is no incentive for or focus on enablement of collaboration, ie no real community that one can become a part of and influence and improve by just being positively involved. Some purely open source projects are this way, but most open/commercial dual-licensed products are this way. Even the "open source" parts are developed in a sort of "glass cathedral". People can see what is going on, and if they really want to they can walk in and participate, but most choose to stand outside and watch and in fact pay to not get too involved.

So, in closing, here's to Glass Cathedrals and the opportunity they give to community driven open source projects to differentiate ourselves. It also brings to mind that old saying... something about stones and those who live in Glass Cathedrals....

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...