Open Source Business and Open For Busines (Apache OFBiz)

2009-06-23T13:48:00.000-07:00

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

2009-06-10T02:08:00.000-07:00

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

2009-05-12T01:18:00.000-07:00

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

2009-04-13T10:38:00.000-07:00

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

2008-01-31T17:34:00.000-08:00

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

2008-01-30T21:51:00.000-08:00

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

2007-06-14T22:37:00.000-07:00

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

Moving the Blog

2007-05-27T20:13:00.000-07:00

Just a quick note for now. This blog, which I obviously haven't updated in a while (since around the time the ASF effort ramped up), used to be hosted on the Undersun Consulting content site but that site will be going down soon because of the merger of Hotwax Media and Undersun Consulting that started in Dec 2006 and was official 1 Jan 2007.

Even when this was on the undersunconsulting.com site I was thinking of moving it to a site like this to make it easier to link to other blogs and manage it in general. I'll be adding to this over time, largely a commentary on what I see happening in OFBiz and mostly my point of view on where I'd like to see things go, or how I understand they might work best.

OFBiz Community Involvement and Jira (repost from 2005-04-15)

2007-05-27T20:09:00.000-07:00

OFBiz is getting big. The code and features are getting big. The community is getting big. Because of this the way we have been managing things is becoming a bottleneck. The proposed solution, as presented here, is to organize and facilitate community involvement. This will happen primarily through Jira, and the process is described here.

Pretty much everyone involved in OFBiz does things on their own time and decides what they want to work on, or does things on an employer's or client's time, and prioritizes the needs and requests of those "what pay for da time."

I certainly try to handle incoming requests and issues, but at times it is simply more than I as an individual can handle. I really appreciate the help of Jacopo, and sometimes various others on these things, but more is needed...

With a tool like Jira we really can have more community involvement, and it would help a lot! There are dozens of outstanding issues in Jira, and various other bugs, issues, priorities, etc that are not in Jira. For things that aren't in Jira, we should push submissions there more, and I plan to start entering the things that I would like to work on there.

=========== THE KEY:

To help with my decisions on priorities for these and other things, I would REALLY appreciate community feedback. This helps the project serve the needs of those who are using it better, and it allows me to step out of the position of being that bad guy that tells people who have invested effort into something: sorry, I won't review it and put it in because in my opinion it is a lower priority than other outstanding issues.

How to help?

vote for tasks/issues in Jira that you think are important!
review submissions and improvements in Jira and comment on them
if you have a pet-peeve or other issue, submit it as a Jira issue with good detail, and then vote for it

This will help those that do the final review and commit to feel more comfortable that there are no major issues with the changes and additions, and if there are issues to get them resolved before the final review and commit effort begins.

If you have an issue that you think is important and no one is looking at it, don't ask me or the other commiters to take care of it, send a message to the users or dev mailing list and ask people to review it and vote for it.

There have been various discussions about this over time, and I think the project is to the point where not doing things this way is preventing growth and progress...

I'm very interested in hearing feedback on this, and even MORE interested in seeing feedback and voting going on in Jira.

Thanks to everyone for all of your help. I know you have put a lot of effort into contribution to the project, and it is these efforts that makes OFBiz what it is.

Collaboration: The Key to Success (repost from 2005-04-15)

2007-05-27T20:08:00.000-07:00

Sometimes it is difficult to know how to go about leveraging an open source application like OFBiz in your company. This is especially difficult when people involved are not used to working on projects with larger teams and overlapping objectives. There are some misunderstandings and very tempting ways of doing things that everyone should be careful of, and it really comes down to effective collaboration....

One misunderstanding I see frequently is concern over occasional bugs that are discovered or changes being made to things you are basing something on, or in general not trusting the code or not liking the fact that additional work is required in some cases to make your own stuff continue to work based on changes, or be delayed because of a bug in something you need. Based on my experiences digging into these concerns, they are phantom concerns and is not the real issue. The real issue is the thought that there is a need for some sort of a stable set of code to work from, or that a strict isolation from the open source project is desired.

BE CAREFUL, THIS IS DANGEROUS! I say that in all caps because I really mean it. The fact of the matter is that the company is engaging in a development project, or more a customization project. You have a high level of collaboration happening within any company or group doing an OFBiz-based project, with sometimes one or two or sometimes dozens of people who will be making and committing changes to the company source repository. The aspect of this that I am talking about that is dangerous is the idea the you want to take a "snapshot" or somehow theoretical perfect set of code to use as a basis for your efforts. Unfortunately this theoretical perfect starting point doesn't exist, not in OFBiz, and not in any other piece of software open source or commercial.

A better way to look at this is that each person is working in collaboration with a number of other people, all of whom are working on projects that in one way or another move the software in the desired direction. The key thing to realize when working with an open source project like OFBiz is that there are many more resources than just those inside the company that are helping with a larger effort. Some of that larger effort (ie the set of all efforts going into OFBiz) is of interest to the company, and some of it is not. From an enlightened point of view, a LOT of things that might at first seem unimportant to the company and its specific project really are important and will over time save the company a lot of money, and the people involved with the project a lot of effort.

In other words, the fact is that OFBiz is a very large piece of software with many features and it is only because of those features that this specific project for this specific company can be a success for the effort being put into it. Software like OFBiz requires a LOT of work for maintenance and even though the company is putting a lot of resources into the effort, it is almost universally not near enough to maintain the entire set of software, fix bugs, create new solutions to problems that come up, modernize old code to make customization more efficient, and so on. Various groups have taken the "snapshot" approach and eventually they lose out on the thousands of hours of effort that result in improvements in OFBiz every single month.

The downside to this is that other people will work on new features that go into the open source project but that the company doesn't care about (not at that moment anyway), and in some cases those can conflict with what the company is doing. In most cases evaluation of the conflict results in a significant improvement in what the company ends up doing. But still, yes, there is some flexibility and reaction and conflict resolution that is required in the company to handle the side effects of what others in the community are doing. Still this cost is usually not even in the same order of magnitude (and often 2 orders of magnitude, in other words 100 times) separated from the effort that would be required to reproduce in the company everything that is going into the open source project that is of value to the company.

Some strategies to consider... Unless there is a specific reason for it, like getting a specific bug fixed or getting a new feature in place, it is best to only "sync up" with the open source project once every week, or every other week even. This is a very common tactic used in large development teams that are segmented into different teams with different purposes. In order for each team to move fluidly, they don't necessarily stay in sync continuously, but instead work in their smaller groups and continuously stay in sync there, and then frequently (but not continuously) combine all efforts into a single code base. Once the "feature freeze" happens (before the testing phase in preparation for a deployment) this process changes and typically only bug fixes are introduced, and everything is continuous.

There is a good book that I found recently on this topic that explains how to facilitate these sorts of things using Subversion. It is called: "Pragmatic Version Control, Using Subversion" by Mike Mason. There is also a CVS version of this book, but note that because things in CVS are less flexible (like not being able to move files and directories, for example), the approaches for CVS are much more difficult.

In general the key to success for any large project is: collaboration. When working with open source software effective collaboration is even more important, and at the same time the open source way of creating and maintaining software is a major facilitator of collaboration.

The trick is for people to recognize some of these key concepts and then embrace collaboration, and not fight it or fear it.

Some "Rules" for Collaboration that might be good to present and discuss and frequently remind people of in an large project:

understand that the effort is much larger than any one person can accomplish
recognize the value of what other people are doing in the larger scope of the project
recognize that other efforts may at times require modification of the same files that you are modifying, and therefore sometimes introduce conflicts that will require your effort to resolve, and all for the better good and overall progress
accept that you and everyone else WILL make mistakes along the way, and give people a chance to correct their own mistakes by letting them know about the problem you found; note that sometimes the problem is caused by multiple people, and multiple people will have to work together to solve them

I hope that I am speaking to the real issue, and the real fears and anxieties that people are facing. From feedback I hear every day this is a VERY common fear and misunderstanding.

OFBiz User Interfaces General Thoughts (repost from 2005-04-06)

2007-05-27T20:07:00.000-07:00

There are 2 main themes that seem important for the progression and general design of OFBiz:

1. Easier administration of customer/public facing content, preferably through the browser or some other real-time remote server interaction (like webdav)
2. Design goals of the administrative user interfaces, ie generic and "complete" versus task/goal oriented (a good point brought up in this last message)

Thanks to Ean Scheussler for bringing up these issues on the OFBiz dev mailing list.

Some thoughts/comments on these, including why some things are the way they currently are in OFBiz or rather the intentions during the creation of these things:

1. This has come up a few times in the history of OFBiz, and in my opinion being able to modify certain parts of public and customer facing sites it's a great idea and one that a lot of people ask for. At one point we were in discussions with eInnovation in Cincinnati to integrate WSPublisher (now OpenEdit) into OFBiz, but they eventually pulled back and were flaky over the licensing so it never worked out...

The Content Management stuff was brought up in this context, and some effort has been put into moving it in this direction, but it is most certainly not finished and the tools that were meant to facilitate this application of the infrastructure was never really cleaned up for real use. What I'm referring to is the Layout editor in the Content Manager, and certainly not the raw Content and DataResource pages (which have a couple of design issues, and a couple of things are broken, but they generally work...).

This approach is very easy for small companies, or sites that are administered by a small group of people. For larger groups and more constraints things get hairy... Permissions for editing and viewing, revision management, trial and production deployments, etc, etc.

This is great for managing some content on a site, but in my opinion quite a bit of a pain for certain other things, especially things that are very dynamic. In general some things make very good sense to put in the database, but I hate having code in the database for the most part because it is so difficult to keep synchronized with other things, to edit and do global searches, etc. Of course, all of this can be done but now you don't have any of the common tools to use, you have develop your own for every single little thing...

2. There's no question that in general the administrative applications in OFBiz are VERY generic and are not helpful for guiding the user through specific tasks. Some things will guide you through small sets of steps, but for the most part people do seem to have a hard time getting used to where to find things or where to get started with specific tasks they need to do.

The problem with the approach of trying to define simple and limited user interfaces that are oriented to specific tasks is that (like Ean started hinting at)

1. they become highly redundant (ie lots of screens that deal with a specific entity like ProductFeatureAppl or WorkEffortRole, or even worse for the "top level" entities like Product, Party, and Content)
2. you end up with TONS of them in a project that is trying to be fairly universally applicable like OFBiz which means lots of work to develop and maintain, more confusion when trying to figure out not only how but WHAT to customize...

My thoughts on this right now are that we should keep the UI's fairly generic in OFBiz and to facilitate their use by writing role and task oriented documentation that in essence describes where to go and what to do when you want to accomplish certain tasks or goals.

That is the intention behind the design and organization of the "Application Overview for Users" document in the Undersun on-line documentation. And yes, we do charge for that because it is NOT necessary to use OFBiz but it does make it easier for various types of users to use, and we have a technical writer that is more or less dedicated to this. Actually, so far there has been so little money and so many complaints about a company that is not affiliated with OFBiz doing such a thing that I'm tempted to drop charging for it and just open it up. I don't for 2 reasons: 1. spite over the complaints, 2. there would be so much load on the server that we couldn't live with what we have now and would need another server (or 2).

Another thing related to this, and going right back in some cases to the commercial side of the world... is the idea of creating derivative works of OFBiz that basically amount to applications that ARE designed to be role and task oriented with user interfaces very customized to a certain way of doing things and for managing certain types of data. Creating these things basically amounts to creating forms with a lot of "ignored" fields, and stringing them together in wizard type things, plus creating special ways to view or visualize the data, which usually have links that represent starting points for tasks related to specific data.

This is a nice approach that makes things much easier for users. The "specialized" folder in OFBiz has some applications going in this direction that are really pretty good. This also opens up a huge world of commercial opportunity to create full-featured applications for specific types of businesses, or really full-featured solutions that can include support and other things that most companies need but can't do for themselves, and often can't afford in face of the large licensing fees required to acquire the access to the functionality they need.

Okay, now I'm blabbing on....

The Process (or undertaking) of Getting Started with OFBiz (repost from 2005-03-15)

2007-05-27T20:05:00.000-07:00

One thing that I find interesting though is that about 30 OFBiz based ecommerce sites went live (that we are aware of) without any interaction from Andy or me, and without the conveniences that are now available such as the Basic Production Setup document, the training videos, the Undersun online documentation, etc.

I imagine that some of the people working on these learned things from the mailing lists, but my guess is they took the approach of considering the code base to be a rich resource of examples, and used those examples to figure out how to do things... That is mostly a guess though...

In fact, my opinion on this topic is that there is a LOT of functionality in OFBiz, and while you can learn the basics of the framework and tools and a week (not easy, but possible; and only a general understanding for sure, not all details available), it can take many months to learn about all of the data model and the logic and the user interfaces, basically all of the business level stuff. So, no matter what materials exist it will take time for your brain to soak everything up, and the examples are by far the richest and most dense resource for doing so.

All of the other documentation and videos and such are really only meant to make it easier for you to get started. They won't finish the process, and no materials ever will, because your needs may be pretty unique and it is impossible to predict what they will be and write a document that gives step by step instructions on how to do everything that anyone might want to do. At some point, some live human effort is necessary.

So, the documentation offerings from Undersun are NOT necessary to get going with OFBiz. Dozens of people are doing great things without ever looking at those. However, they can help you to get started and that is their intent.

Docs and Books for OFBiz (repost from 2005-03-07)

2007-05-27T20:04:00.000-07:00

There are lots of books that could be written about OFBiz to address different needs and audiences. And these really are very different audiences... We have talked with a potential publisher about doing a book about getting an ecommerce or general retail business going with OFBiz, though from this discussion it sounds like what is desired is something about development using the OFBiz framework.

One of the problems is that OFBiz is not corporate backed or sponsored by any company that press and publishing people like to toss out to make them look better, and when we talk about volume in terms of the current community the conversation seems to move towards self publishing or doing a PDF or other online book, or considering it as an investment and hoping that if done with a concrete enough real world benefit people might pick it up just for that, in spite of there being so little demand for it in advance.

I guess the main issue is that even though OFBiz can be used effectively in pretty small businesses, and as it is more complete that is improving weekly, but a fair amount of knowledge and skill is still needed to really do something with the software. So, we might be able to sell 100 or if we were lucky 200 copies of a book over the first few months to a year if it were available now. The only way to increase that would be for a publisher to decide they like OFBiz and spend some money on marketing the book, part of which would be the printing and distribution costs and trying to get buyers from major book retailers to buy it.

So, you're probably thinking: come on! It's not that hard! Look at all of these little open source projects that are doing it! That may be true, but consider how many technical journal articles and such those "little" projects have published before they can even consider doing a book... Even though users and potential users of something like OFBiz love the idea of open source enterprise software, it still isn't very popular in the incumbent technical and enterprise software business worlds. In fact, there is a little bit of hostility to the whole notion and it's hard to be taken seriously since so many people doubt that what we are doing can be done.... As the project progresses and more live sites and case studies are available as proof this is changing, but it is being totally driven from the edge, or in other words the end-user companies. There isn't much interest yet from the current big software providers.

In that sense a more limited scope architectural tool that doesn't require potential users to give up so much of what they love and are personally invested in is a LOT easier to sell to the world, and to the likes of Sun and Apache and various other groups that are heavily into the theory of enterprise software and building out of the infrastructure. For most developers they don't want a complete solution, because even if they did they couldn't sell it internally or to the management of their company, unless they are in very particular and somewhat desperate circumstances.

So, the fact of the matter is that OFBiz is being driven from the business side of things. This is one reason we'd like to create a somewhat separate framework project that can grow on it's own merits without the implication that using the entire data model and applications is necessary...

In the mean time, OFBiz is growing and progressing fairly nicely being driven by business needs, and this is being served well by face to face training, assistance with custom development, and now for the lower end training videos and reference documents and end-user oriented documentation.

So, no, it isn't nearly as simple as a small scoped project like Spring or Struts or Hibernate. Though in a way the framework is simpler that those combined once you get a full multi-tiered web-capable stack in place... You can't compare learning the OFBiz framework to learning Spring or Struts or Hibernate or the Servlet API, it is really more comparable to using all of them together, or whatever tools of the day that you like the idea of using in your master plan.

That's the problem with OFBiz. We HAVE to have a master plan for the architecture because we have hundreds of thousands of lines of business artifacts that depend on it, and it has to be efficient. So in order to use OFBiz you kind of have to be willing to go with the tools in use, either that or throw out the existing business and application artifacts and start over on your own, perhaps with just the data model or parts of it or something...

So, will there ever be a book published about OFBiz from a major publisher that sells thousands or tens of thousands of copies? Yes, I really think there will be, but the project and the current community just aren't ready for it yet.

Power, Wealth, and Open Source (repost from 2005-01-29)

2007-05-27T20:03:00.000-07:00

I want to make sure it is clear that these are my own thoughts and opinions and observations. While based on fact and experience, there is naturally a lot of speculation in here...

One of the big principles that feeds my desire to see open source software succeed is that centralization of power is a dangerous thing. With it one man, often influenced by others, but still one despot can cause pain and suffering in the lives of thousands or millions of people. History both ancient and modern is full of examples of this, on small scales and on large. In this age there are despots both political and economic. Consider that large companies these days control sufficient wealth and in some cases power to have an effect for good or bad on hundreds of thousands or even many many millions of people.

Earlier today Al Byers sent me an article in the Salt Lake Tribune that I found interesting and thought provoking because of personal experiences I have had with this. Here is the link:

http://www.sltrib.com/ci_2543579

I live in Utah, or more specifically in Utah Valley, where much of this is taking place. I know a lot of people who work for or have worked for Novell, WordPerfect, and various smaller technology companies here, some of the most notable these days being Canopy Group companies.

For a long time in Utah Valley the economic basis was fueled by software companies such as WordPerfect and Novell. There are other major economic influences here, like over 20% of the population are students, many of whom are from out of town. There have also been other forces here such as a large steel plant and such, but the software industry has been a big deal here in the past and it's decline is having a significant effect here.

Having met Ray Noorda a few times I was really surprised by the actions and direction of the Canopy group, especially by the use of their resources to try to go after more honest and hardworking corporations and individuals with legal attacks, so this explains a lot. It reminds me of a few meetings various years ago when I was working at Lineo that both Ralph Yarro and Ray Noorda attended. Ray was always very quiet and didn't seem to overly involved, almost there as an observer. Ralph has a pretty forward and overbearing personality.

Their dress is also very different. Ray's idea of dressing up seems to wearing old church clothes and black sneakers to at least be the right color. I've seen him at church and in business meetings this way. He lives in a fairly modest house, about like the one my parents live in, and doesn't drive fancy cars or anything. He regularly attends church (the same congregation where my mother-in-law and others in my wife's family attend). His family has only seen enough of them wealth to make sure they are comfortable, but he does not go after the comforts and luxuries of the world nor has he spoiled his children with such.

Ralph Yarro seems to be somewhat the opposite. I don't know him as well and haven't seen him as much but he seems to like to dress expensive, not just nice, but clearly showing money spent in both clothing and accessories.

It's amazing how the greed of one man can cause so much damage. Ray Noorda is probably the biggest proponent of business development and investment and probably the direct cause of much of the employment in Utah Valley. I think is because instead of hoarding his significant earnings from Novell he has reinvested them and helped other people get dozens of businesses off the ground. This is especially true in the software sector but also in other areas since this is largely imported cash and exported services.

Without Ralph Yarro I wonder how much better the economy would be here, and in many other places around the country and to some extend the world... I wonder how many valuable resources that have gone other places would still be here and still be more involved as a proponent of open source... Like Ransom Love the ex-CEO of Caldera Systems, that purchased SCO and changed their name and direction soon after he left. In hindsight it makes me wonder if part of his reason for leaving was that he was opposed to such open and blatant attacks on Linux and open source software in general and didn't want to be a part of it.

Even more significantly, how much impact have the SCO Group's (what used to be Caldera Systems, a Linux and open source oriented company) actions had on other potential users of and contributors to open source software? Would such significant changes have come internally without investor influence? My guess is no.

The good news is that the SCO legal threat is diminishing. I must admit I don't trust our legal system to do what is best for people in general, that really isn't their job. They are their to judge and be involved in the enforcement of the law. This leads to some really really strange things happing in the legal world sometimes, that would seem totally illogical by normal logic, but in their application of laws to the current circumstances and in the name of merciless justice somehow to make sense and even seem obligatory.

Anyway, hopefully in this case the abuse of our legal system will not succeed. And who knows, now that hopefully the corruption at the top has been removed other powers that be will let go of the tantalizing taste of the temptation of power, wealth and comfort and just let the lawsuit go. Perhaps they will even re-join the ranks of those who are putting work into moving Linux forward for their own profit and for the progress of business and society in general. And perhaps they will get into pushing forward open source softare in other domains...

And what would be the benefit of this? Software is a unique resource that hasn't really been dealt with in history. It is cheap and easy to duplicate once initially developed and can result in significant savings and improvements in efficiency for those who use it. Not that it is free or easy to use in many applications where it is most valuable, but the tool alone enables increased efficiency that would otherwise be impossible.

The result of this in our modern economy is that massive corporations and monopolies have caused serious economic confusion and unprecedented shifts in control and distribution of wealth. That wealth in this world seems to be easier and easier to leverage almost directly into power. The danger of that should be pretty clear...

The furthering of open source software can help re-balance this and put control back into the hands of those who use the software rather than them being at the mercy of monopolies that enforce their position by taking advantage of their market share to make it hard for existing users to play well with users of other software.

Open standards are good, but the industry incumbents have to adopt them as well in order for them to succeed, which often isn't in the best interest of the incumbent.

I guess that's all for now. Will be an interesting show to watch as things progress...

-David

The Nature of OFBiz: Community, Resources, Scheduling, etc (reposted from 2005-01-29)

2007-05-27T19:54:00.000-07:00

I know The Open For Business Project has many shortcomings, I get dozens of email messages every week that tell me about them! Of course, other people may not be having the same problems as those people I hear from, there are a wide variety of needs and solutions to those needs. But that's okay because this isn't a company, it's a community!

If I could choose how to structure an open source project it would be this: spend the tens of thousands of dollars required to setup a tax-exempt not for profit company, and have millions of dollars of corporate and individual contributions to make a beautiful piece of software that everyone loves and can effortlessly use for free.

Oh, and all major contributors would be moved to a single beautiful place and have huge houses and drive Audi A8s or something similar. And of course there would be a staff of hundreds to keep up with documentation, support, business development, and so on so that the developers could sit around all day and pontificate and create wonderful things. And after major releases they would have time off since that would bring in serious financial contributions automatically by the generosity of corporations around the world so they would take a couple of months off and hang out with family and friends and lose some of the weight gained during development.

Is that too much a dream? Yeah, I guess it is... So, as slow (but really truly elegant and beautiful) as it is, here is how OFBiz REALLY runs. And actually, there are really big reasons why I love and you could too...

As far as scheduling an planning goes: this is a community driven project! Andy and I have no idea what your needs are and what you are working on unless you tell us. For us, we do work on some things on our own time (probably 30% of the project is in this category, and mostly in the framework), but we don't often know how much time we'll have to spend on those things. Most of what we do comes from contracts, so only the people who pay us know what is coming up. In many cases we don't even know until a few days or a few weeks before we get started. We never know which analysis and bid efforts will result in a contract.

In other words: this is an unfunded community project! Even worse, it is an unfunded community driven project that is still maturing! So, right now if you aren't interested in being part of the community with all that entails, I don't want you to go away at all, but I also can't afford to help you very much.

Maybe this little parable would be helpful:

http://www.bres.boothbay.k12.me.us/wq/nnash/WebQuest/little_red_hen.htm

Consider OFBiz as the multi-part project it is and that some parts are still in the phase of the growing wheat, and other parts (such as ecommerce) are already bread that some of us are getting fat from. In other words, there are still many opportunities in OFBiz to be a "Little Red Hen" and get all of the benefits that entails. I have no problem with ducks, cats, and dogs, but I also don't have the resources to make a way for you.

That said, we are certainly working on this all the time and after significant development periods a lot of documentation update is needed.

We will be doing some getting started guides for SPECIFIC functionality areas, or uses of OFBiz. It is almost impossible, and probably not terribly useful for beginners, to have a getting started guide that covers the entire project. So, the first one will be VERY ecommerce setup oriented and go over the _basic_ things needed to get an OFBiz instance configured for production.

We have a few contracts coming (hopefully) right now to do these sorts of basic ecommerce setups, so the timing is good. And, BTW, yes: this will include both development to simplify the process and documentation of what is left over. One OFBiz community member, Integral Business Solutions, has even offered to pay for some of this and to allow it to be distributed freely as part of the project.

I just want to keep one central message in this email:

This is a community project! Those who want to get involved do, in some way or other. Those who consistently contribute and act like real members of the inner circle become that. This includes people like Al Byers, Jacopo Cappellato, and Si Chen. It also includes Andy and me. And there are MANY others who contribute on a smaller scale what they can. Sometimes these are bug fixes or just bug reports. Sometimes these are helping new people with _correct_ and well researched and experienced information.

We are just members of a community. Some of us have chosen to be _intimately_ involved in this project and dedicate thousands of unpaid hours to moving it forward. This does require significant sacrifice and I understand that many people aren't in a position to put up this sort of time and money. I understand that because at this point _I_ could not afford to get something like OFBiz started again. Now, this isn't because consulting has been bad, I still make more than I did as a senior engineer and analyst, but I invest a lot of cash in equipment, paying other people, marketing, and so on and I've had a couple of really significant personal losses recently, one on the order of ~$25,000 and another around ~$90,000.

I'm sure many people reading this have experienced such things and I understand that sometimes things just don't work out or have to wait. For some people, using OFBiz is in this category: it hasn't progressed enough for them to able to _afford_ to use it. There are many of us working on that progression, but there is a lot of work to do. So, if it's not moving fast enough for you or is not convenient enough for you, there is only one person/company that can guarantee to fix that: you. Or, you can wait. It will get there, I don't think there's any question about that.

I appreciate that some people are taking the time to put some detail into this and describe their needs, instead of just saying "it sucks" or "it's crap" or "it's non-existent". Please understand that different people and different companies have VERY different needs so details are required to achieve any reasonable level of communication.

Thanks again to everyone who is working on this and constructively making effort to move it forward and help to solve problems that exist, and not doubt they do exist! Especially those who bring up and issue and propose a possible solution! That makes it much easier to discuss and understand, even if the initial proposed solution doesn't turn out to be very good!

-David