On Apr 3, 2010, at 6:59 PM, Ean Schuessler wrote: > I have a friend who's favorite business saying is "start out where you want > to end up". It is sort of a nonsense phrase but it says something similar to > "a stitch in time saves none". If we are clear about what we are trying to > build it will be much easier to put those fixes in now than to try to change > course down the road. > > In my mind, we are trying to do something revolutionary which is to bring the > power of ERP down to the small to medium size business player. Its > revolutionary because, if successful, it has the potential to change the > dynamics of business and the structure of the world economy. If we are going > to succeed in that task we are really forced to confront the reality of what > those business owners need. That means providing business continuity even in > the face of small budgets and a minimal IT staff.
Agreed. But the main point that is often ignored is that we are doing this revolution with *minimal* resources: a limited group of active committers and a small group of service providers. The only way we can win is to understand our limits and be clever and study new (unconventional) ways of achieving our goals. This was done in the past of OFBiz, mostly thanks to David's vision (developer friendly community, push to use the trunk to maximize feedback and contributions etc...). > If we can make the "myth" of easy upgrades a reality then our software it > going to be much more widely adopted. > > I'm not trying to brush the complexity of this under the rug. I agree with > you whole-heartedly that seamless upgrade-in-place is probably a real pain > for us to achieve. At the same time, it also has the possibility to reduce > our overall workload. > Adam and I personally have to oversee upgrading customer installations on a > regular basis and those upgrades are typically time consuming and a little > bit scary. If this problem was reduced to literally pushing a button it would > free up time that could be spent on more productive tasks that actually > improve the customer's business. I understand your pain, but this is not a good enough motivation for moving the burden of backward compatibility on the community shoulders; I know that this is not what you meant but the true reality is that the issues you have faced with upgrades were not even strong enough to induce you or Adam (that are in the restricted group of the most generous contributors) to contribute back upgrade scripts etc... so I don't expect they will be a strong motivation for others. Enforcing a rule is not enough. We have to find better ways of inducing the community to help with backward compatibility. And one way is the one I have suggested: invite companies or service providers that are in the process of upgrading an OFBiz instance to discuss the process in the list and to cotribute back their experiences, scripts etc... others will benefit from this and may also help. This is very different from expecting the "upgrade button" to ba made available by committers. This is more in line with the effort of building a community of people interested in upgrades and willing to help, contribute and participate. Jacopo > > My $0.02. > > ----- "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 > -- > Ean Schuessler, CTO Brainfood.com > e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
