There is a big difference between software that implements public specifications (like SQL, JDBC, etc) and that tend to stay mostly the same over time and software like OFBiz that implements business concepts that are not driven by a public specification. Also, with PostgreSQL in particular as an example, that software was driven by commercial interests for the majority of its life, and OFBiz never has been.
I did attempt to get an effort going to produce some sort of requirements and designs to drive what goes into OFBiz, but that "marketplace" that drives OFBiz doesn't seem to be oriented to that. IMO Anil is right on. In order to get these things done, and get them maintained over time, the people involved MUST have a motive to do so. So far that hasn't happened, and I guarantee that once a sufficient structure of motivation has been setup then people will get involved and these things will happen. In the project right now contributors and committers do have reasons to put things into the project, even if most users of the software clearly don't understand the reasons involved. Is it possible that a volunteer community will form and work on a documented, tested, high quality release? Yes it's possible, and I've been pushing to leave that door open with the approach we're using with the release branches (ie a place to start for those interested in such a thing). Has it happened? Yes, but only a little bit. There are people that fix bugs specifically in the release branches, just not very many. There is some documentation specifically for certain release branches, just not very much and not much collaboration in it. So yeah, it could happen as a community effort but in order to get people motivated to do a good job with it my guess is that a commercial effort has a better chance of being sustainable. That would basically be a commercial distribution of OFBiz that includes support (installation, development, and production support), documentation, migration from one version of the distribution to another, etc. One effort that started this way ended up being a fork of OFBiz. They didn't focus on being a distribution and instead focused on differentiation and user lock-in by creating add-ons and other things that competed with the open source community. So there is another important part: the people involved have to understand how to work with the open source community and provide the things that are really only viable with some funding, which is (for those interested) mostly stuff that people customizing the software will not typically do (there's a hint). -David On Feb 16, 2010, at 4:05 PM, Ruth Hoffman wrote: > Hi Anil: > No disrespect intended to anyone on this list, but how is it I wonder that > PostgreSQL is able to manage releases so well? Last I looked they are still > totally community driven and you will find PostgreSQL installed in some > pretty "high" places. > > Just wondering out loud. > > Regards, > Ruth > ---------------------------------------------------- > Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz" > [email protected] > > Anil Patel wrote: >> Chris, >> Thanks for listing important tasks for managing product release. In ofbiz >> community little less has been done on this front, I wish we could be better. >> >> Very fundamental difference between professional open source projects like >> you mentioned and Ofbiz is that, Ofbiz is community managed and developed >> project. If you search mailing list archive, you can find some good >> discussions on this topic. >> Some people may consider it (that we don't get these professionally managed >> releases) as drawback of Ofbiz, while others may see opportunity. Somebody >> can build business around delivering services like you mentioned. We still >> have huge untapped market. >> Thanks and Regards >> Anil Patel >> HotWax Media Inc >> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >> >> On Feb 16, 2010, at 1:28 PM, Christopher Snow wrote: >> >> >>> Hi Anil, >>> >>> Most of the stuff on this document appears to happen, so the question is do >>> we need to be doing more? For example, there appears to be just two roles >>> on this project, committers and contributors. Who is responsible for the >>> following areas for each release: >>> >>> - migration from old to new releases >>> - patch management >>> - dependency management >>> - quality management >>> - documentation >>> - etc.. >>> >>> I expect there would be many people who are not contributors who would be >>> willing to head up some of the above areas (including myself). >>> >>> The more I think about it, the above areas are where others products are >>> much better (adempiere, openerp, openbravo). They appear to have a much >>> stronger release management process. >>> >>> Cheers, >>> >>> Chris >>> >>> Anil Patel wrote: >>> >>>> I know we used to have a release management document on old confluence. >>>> Its matter of locating it. >>>> >>>> I request, Please don't draw conclusions so quickly. Thanks and Regards >>>> Anil Patel >>>> HotWax Media Inc >>>> Find us on the web at www.hotwaxmedia.com or Google Keyword "ofbiz" >>>> >>>> On Feb 16, 2010, at 8:40 AM, Ruth Hoffman wrote: >>>> >>>> >>>>> It is ironic. >>>>> Ruth >>>>> >>>>> Christopher Snow wrote: >>>>> >>>>>> It's kind of funny that ofbiz promotes the use of best practice in many >>>>>> areas >>>>>> (http://cwiki.apache.org/confluence/dosearchsite.action?queryString=ofbiz%20best%20practice) >>>>>> EXCEPT release management. >>>>>> >>>>>> Ruth Hoffman wrote: >>>>>> >>>>>>> Hi Jacopo: >>>>>>> Its nice to see this kind of thought going into a release strategy. >>>>>>> Thanks for the effort. Please see my comments inline. Note, this is >>>>>>> just my opinion based on years of working with big complex IT >>>>>>> organizations. These are the kind of "users" who ultimately would be >>>>>>> implementing OFBiz (I hope...): >>>>>>> >>>>>>> Jacopo Cappellato wrote: >>>>>>> >>>>>>>> I know this subject has been already discussed several times in the >>>>>>>> past, but I still would like to rethink our strategy for releases in >>>>>>>> OFBiz. >>>>>>>> I am under the impression that, considering the release branch 9.04, >>>>>>>> that is our latest release branch: >>>>>>>> * there are more users than maintainers >>>>>>>> >>>>>>> This is probably true. But to get a better understanding of who is >>>>>>> using what, maybe we could look into getting download statistics? I >>>>>>> have already put in a request to the infrastructure team for this, but >>>>>>> have not heard anything back from them. Maybe a project committer has >>>>>>> more clout and could get this implemented? Without that, we are just >>>>>>> speculating about who is doing what with the code. >>>>>>> >>>>>>>> * because of this, no real maintenance plan, test strategy etc.. has >>>>>>>> been created around it from the community of users and interested >>>>>>>> parties (in fact we were not really able to officially release it) >>>>>>>> * a lot of new users start eveluating OFBiz from that instead of the >>>>>>>> trunk >>>>>>>> * it is rather old, several new features are missing and also code >>>>>>>> improvements (that could fix bugs etc) >>>>>>>> >>>>>>> I thought all the bug fixes were retrofitted to the release? Is this >>>>>>> not true? >>>>>>> >>>>>>>> * because of this, it tends to be less stable than the trunk >>>>>>>> >>>>>>> How could the release be less stable than the trunk if bug fixes are >>>>>>> applied to the release and the trunk? >>>>>>> >>>>>>>> The main cons of this situations are the following: >>>>>>>> 1) not real interest in maintaining a release branch means that we >>>>>>>> will not be able to spend time on it and officially release it: the >>>>>>>> OFBiz community will miss the advantage of using the marketing channel >>>>>>>> represented by a new release >>>>>>>> 2) new users will get the wrong impression that the project is slowing >>>>>>>> improving if they just get the releases >>>>>>>> >>>>>>> Project committers should consider this behavior pattern: Most people >>>>>>> evaluating code will not want the latest release. They will patiently >>>>>>> wait until someone else has taken on the risk (and reward) of debugging >>>>>>> it. Do not think that just because the project releases a new release >>>>>>> of OFBiz, that everyone will stampede to get it. Far from it. Now if we >>>>>>> had download statistics we could verify my claim, but I'd be willing to >>>>>>> bet real money, that the only people who will jump to download this new >>>>>>> release will be project committers. >>>>>>> >>>>>>>> 3) it is much easier for a user to stay up to date with the trunk >>>>>>>> rather than with a release: I mean that there is no guarantee that one >>>>>>>> day someone will build an upgrade plan from the old release to the new >>>>>>>> one... users of the old release may be left behind forever >>>>>>>> >>>>>>>> >>>>>>> I think you mistake "user" with "committer". What "user" is actively >>>>>>> trying to stay current with the trunk? Just some food for thought. >>>>>>> >>>>>>>> What I suggest is based on the following assumptions: >>>>>>>> 1) community is not ready or interested in maintaining releases >>>>>>>> >>>>>>> Only the "committers" are not interested. Users out there may have a >>>>>>> different story to tell. Personally, I'd like to see releases >>>>>>> "maintained". >>>>>>> >>>>>>>> 2) new users prefer to start evaluating OFBiz with a release instead >>>>>>>> of the trunk >>>>>>>> 3) it is good for the project to announce new releases often >>>>>>>> >>>>>>> True. Very true. >>>>>>> >>>>>>>> 4) because our current policies (slowly increasing number of >>>>>>>> committers, peer reviews, etc...) our trunk is (and will be) more >>>>>>>> stable than older releases >>>>>>>> >>>>>>>> >>>>>>> Again, why? I thought bug fixes are committed back to a release if >>>>>>> appropriate. Is this not the case? >>>>>>> >>>>>>>> Here is what I suggest: >>>>>>>> A) define an official release plan that says that we officially issue >>>>>>>> a release every approx 6 months (just to give you an idea): since >>>>>>>> there is no way to define a set of features that will go in the next >>>>>>>> release, our releases will be based on dates instead of features; but >>>>>>>> of course we can discuss the exact time of a release based on what is >>>>>>>> going on 1-2 weeks before the release date >>>>>>>> >>>>>>> Don't release every 6 months. That's crazy. Once a year is sufficient. >>>>>>> Put in place a real release plan including features, fixes and upgrade >>>>>>> instructions in advance and then work towards making OFBiz something >>>>>>> more than just a developer's playground. Make it "stable" by setting >>>>>>> out in advance what "stable" means. And then work towards making each >>>>>>> release meet the "stability" requirements. Just releasing something >>>>>>> every 6 months or a year does not a "stable" release make. >>>>>>> >>>>>>>> B) there is no guarantee that patches will be backported to releases, >>>>>>>> that upgrade scripts will be created from release to release >>>>>>>> >>>>>>>> >>>>>>> If so, then what is the point of even having releases? Just have >>>>>>> nightly trunk builds and everyone is happy. >>>>>>> >>>>>>>> It is true that the ASF policies ask that a release, that represents >>>>>>>> the code that is distributed by the ASF to the larger audience of >>>>>>>> users, is a "stable" deliverable; but if we continue with the current >>>>>>>> approach, even if it is intended to get a stable and maintained >>>>>>>> release, what we are really doing is distributing the code in the >>>>>>>> trunk (this is what we suggest our users to use instead of the >>>>>>>> release), not the "stable" release. >>>>>>>> >>>>>>>> >>>>>>> IMHO, one of the true benefits of going with the ASF is the structure >>>>>>> and stability they enforce on umbrella projects. Why not use these >>>>>>> "restrictions" to the project's advantage instead of trying to >>>>>>> circumvent them. I think I'm agreeing with you in that maybe "we" >>>>>>> should start pointing users to releases instead of trunk code. Just a >>>>>>> thought. >>>>>>> >>>>>>> Ruth >>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> >> >>
