I've felt this same frustration Jacopo. OFBiz is a large project with a long history and the community has been mostly focused on making it easy for developers to get involved (ie inviting all sorts of contributions and the people with them in order to hopefully get more contributions). This has worked pretty well to attract developers who are willing to contribute certain things, mostly new features.
What hasn't worked well is attracting contributions for documentation, testing/fixes/stability, backward compatibility, etc. IMO the key is that for a given change, like this data model change, there is no reason the same person has to take care of all of this stuff. The way a volunteer community like this is structured is that people need a motivation to contribute things, and that means that those who care about something should contribute to that. In other words, if you care about OFBiz supporting backward compatibility then you should contribute to backward compatibility efforts. If you care about stability, you should contribute to stability efforts. The problem is... not enough people care enough about these things, or at least not enough to do anything about it except complain and attack those who are contributing other things or other aspects of specific things. This is a break down in collaboration. On top of that we have a severe issue with collaboration on design. Part of this is that people have a hard time distinguishing between requirements and designs, so discussions about design go nowhere in a hurry. Maybe more important is that we just don't try to collaborate on requirements gathering and design very much, and if we did then we could get better at the problem above and after a while it wouldn't be an issue. The result is that the different parts of the project have very different design approaches and sometimes unresolved conflicted requirements. Sometimes this shows up as many ways of doing the same thing. Sometimes this shows up as hidden features that are not apparent when looking at the XML schemas or data model or the API (ie the external interface isn't designed well making the feature inaccessible to customizers and/or end-users). Most ASF project benefit from having a standardized spec to implement (ie the design has already been done outside the project), but OFBiz doesn't have that benefit and so whether we like it or not we are doing design, and unfortunately the design seems to be mostly by default (or accident, or implicit design) and arbitrary external requirements as opposed to explicit coordinated efforts and design before implementation. In short it seems like there are various people in the community who would like to see the focus of the project shift away from making things easy for developers and toward making things easy for end-users. I think that's a great approach, but the problem is how do we do it... what motivation can we leverage and how can we mobilize people with that motivation to make these happen? People can complain about how things "should be" all day long, but that's not going to change anything. If no one is motivated to do these things then the only result of complaints will be alienation and less complaints. The irony is that the community focus on attracting developers instead of attracting end-users has resulted in a social environment that discourages contributions and alienates developers. Is is just the people involved, or is there something fundamentally wrong with the whole approach? -David P.S. A good example of this dynamic (IMO) is the NUMMI car plant and the differences in corporate culture between Toyota and GM. GM focused on making workers happy and resulted in poor quality and unhappy workers. Toyota focused on making good cars and resulted in high quality and happier workers. This American Life did a great piece on this that is available here: http://www.thisamericanlife.org/radio-archives/episode/403/nummi I recommend this to everyone as there are some valuable lessons there that I believe are directly applicable to OFBiz and community-driven software, and even software development in general. On Apr 2, 2010, at 2:48 AM, Jacopo Cappellato wrote: > In rev. 930182 I have created also the upgrade script to migrate data from > old to new fields. > > By the way, are we sure it is a good idea for the project to enforce these > rules about backward compatibility? > It seems to me that the development in OFBiz is becoming more difficult every > day and this is self evident from this small improvement that has caused a > rather long thread. > > We are worried about causing harm to an hypothetical group of end users that, > we suppose, don't follow the dev lists, don't have any internal IT team that > can help them in the migration, don't have a budget for the upgrade, don't > understand about the risks of upgrading a production ERP instance and just > want to do this by blindly pressing a button. > We are sacrificing the very limited time of our brave committers against this > "myth". In my opinion we just went too far, the risk is that we go into the > mud and slow down because this plan is not compatible with the resources of > our community. There is also the risk that we are trying to fix a problem > that is not there: chances are that the silent end users have very good > budgets, very skilled IT teams that have greatly customized their OFBiz and > simple just want to take care of the critical system upgrade on their own. > > So I would like to propose a change in our 'policies' to switch from > "backward compatibility" to "backward awareness" based on the following > principles: > 1) committers are encouraged to improve existing code, clean it up, improve > data model etc... even if the changes could cause some problems during > upgrade; OFBiz has to grow efficiently in the best way possible considering > the limited group of contributors > 2) however, since we know that there are companies that are willing to stay > up to date with the OFBiz growth but don't want to invest resources in the > upgrade process or staying in synch with the community, then we will do our > best to simplify the upgrade path; this means that, if time permits, > committers are encouraged to apply the deprecation patterns (for bigger and > more critical changes), or at least write some notes to warn people about the > change occurred that could impact an upgrade etc... > 3) we should also send the message out (from our site, mailing lists etc) to > the silent end users that, if they are in the process of upgrading from an > older release they should at least mention this in the user list: in this way > the community will have a chance to provide suggestions, warn about potential > issues, etc and most of all this will help the community of end users to test > together and cooperate on upgrade scripts > > What do you think? > > Jacopo > > > On Apr 1, 2010, at 1:08 PM, Jacques Le Roux wrote: > >> Actually I did not read enough at >> http://cwiki.apache.org/confluence/display/OFBTECH/General+Entity+Overview#GeneralEntityOverview-DeprecatedEntities >> >> It's now done the right way (at least I hope so) at r929912 >> >> Jacques >> >> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>> Ha, I thought it would work in any DBMS, though the syntax may vary. >>> I did not find a clear answer about that through Google. And as I saw a >>> rename used in the migration tip for R767278, I thought it >>> was OK to use without dropping. >>> >>> So I will re-re-do it the traditionnal way :/ >>> >>> Jacques >>> >>> From: "David E Jones" <d...@me.com> >>>> If you rename the column you would have to do an alter to change the data >>>> type on that existing column with data in it, which may >>>> not work in all databases. >>>> >>>> -David >>>> >>>> >>>> On Mar 31, 2010, at 9:05 AM, Jacques Le Roux wrote: >>>> >>>>> Hi Jacopo, >>>>> >>>>> Did you try the migration tip? >>>>> I found >>>>> ALTER TABLE facility RENAME COLUMN square_footage TO facility_size; >>>>> to work on my postgres intances >>>>> >>>>> Jacques >>>>> >>>>> From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com> >>>>>> Hi Jacques, >>>>>> >>>>>> On Mar 31, 2010, at 2:39 PM, Jacques Le Roux wrote: >>>>>> >>>>>>> Done at r929503, see also >>>>>>> http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration >>>>>>> >>>>>> >>>>>> after the upgrade OFBiz will automatically add the two new fields and >>>>>> will leave the old one (containing data) in place. >>>>>> For this reason the data migration instructions should not suggest to >>>>>> manually alter that field but instead they should suggest >>>>>> to: >>>>>> 1) copy data ("update...") from square_footage to facility_size, setting >>>>>> the default value of "square feet" in the >>>>>> facilitySizeUomId field >>>>>> 2) drop the square_footage field >>>>>> >>>>>> Jacopo >>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>>>>>>> OK, I will revert now and introduces the 2 fields as suggested >>>>>>>> tomorrow (in case somebody has another idea) >>>>>>>> Jacques >>>>>>>> David E Jones wrote: >>>>>>>>> I just checked and I messed up... there isn't a UOM field that goes >>>>>>>>> with the squareFootage field. >>>>>>>>> That being the case, I propose we add a couple of generic fields >>>>>>>>> (facilitySize as a float, facilitySizeUomId) and deprecate >>>>>>>>> the >>>>>>>>> squareFootage field. BTW, however it's done with an explicit UOM it's >>>>>>>>> possible to specify a volume as well as an area should >>>>>>>>> one desire (though I >>>>>>>>> wouldn't recommend it). -David >>>>>>>>> On Mar 30, 2010, at 10:01 AM, Scott Gray wrote: >>>>>>>>>> As per David's email the uom field is already there, the migration >>>>>>>>>> service was just a suggestion and because the uom is >>>>>>>>>> already >>>>>>>>>> there it isn't useful anyway. Regards >>>>>>>>>> Scott >>>>>>>>>> On 30/03/2010, at 9:49 AM, Jacques Le Roux wrote: >>>>>>>>>>> Why not simply add a new field for the UomId ? Do we really need a >>>>>>>>>>> service to migrate data? >>>>>>>>>>> It seems to me that previous integers will be simply represented >>>>>>>>>>> with 0 decimals. At least I tested on Postgres without any >>>>>>>>>>> issues at all. I tried to keep things simple, to me and to persons >>>>>>>>>>> who will need to update: no deprecation, just a change. >>>>>>>>>>> Though I only tested on Postgres and there are maybe syntactic SQL >>>>>>>>>>> variations... >>>>>>>>>>> Jacques >>>>>>>>>>> Scott Gray wrote: >>>>>>>>>>>> If we want it to be a bit more generic we should probably add two >>>>>>>>>>>> new fields: floorArea and floorAreaUomId and then >>>>>>>>>>>> deprecate >>>>>>>>>>>> squareFootage, perhaps with a migration service to populate the >>>>>>>>>>>> new fields with the data from the old. >>>>>>>>>>>> Regards >>>>>>>>>>>> Scott >>>>>>>>>>>> HotWax Media >>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>> On 30/03/2010, at 7:22 AM, Jacques Le Roux wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> I'd like to allow Facility.squareFootage to support decimals. In >>>>>>>>>>>>> order to do that, I need to change the type of the >>>>>>>>>>>>> squareFootage field from numeric to fixed-point. I can't see any >>>>>>>>>>>>> issues doing that OOTB. But in case this would be a >>>>>>>>>>>>> problem >>>>>>>>>>>>> for someone I prefer to warn. >>>>>>>>>>>>> Jacques >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >
