Also not that it has had to major revision since 1996 and it took 4yrs between revisions.
BJ Freeman sent the following on 2/17/2010 12:03 AM: > http://www.postgresql.org/about/history > you will notice is did not start as open source. > 1996 is when i started with it. > > here is an excerpt that ofbiz has yet to achieve. > > In 1996, Postgres95 departed from academia and started a new life in the > open source world when a group of dedicated developers outside of > Berkeley saw the promise of the system, and devoted themselves to its > continued development. Contributing enormous amounts of time, skill, > labor, and technical expertise, this global development group radically > transformed Postgres. Over the next eight years, they brought > consistency and uniformity to the code base, created detailed regression > tests for quality assurance, set up mailing lists for bug reports, fixed > innumerable bugs, added incredible new features, and rounded out the > system by filling various gaps such as documentation for developers and > users. > > ofbiz is just about 8+ yrs old. so by the time it is as old as > Postgresql from its inception I exspect it will be like Postgresql. > > > Ruth Hoffman sent the following on 2/16/2010 3:05 PM: >> 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" >> ruth.hoff...@myofbiz.com >> >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > >
