My Notes From OFBiz Symposium at ApacheCon US 2008 - Main Theme: Organizing Ourselves

[Adrian Crum-2]

--- On Sat, 11/15/08, David E Jones <[hidden email]> wrote:
> Personally I know I've left a wake of unfinished
> projects where I tried to recruit others and identify a goal
> to work towards, like the framework improvements and
> framework-only release (a starting point for higher level
> releases, something easier). As soon as I got involved in
> increased workload, moving, and organizing and preparing for
> ApacheCon and such I stopped working on it... and so did
> everyone else!

I still want to help out with that, btw. Like you, I got busy with other things. I have some framework release related Jira issues out there that I still intend to work on.

-Adrian



     

[Shi Yusen]

I guess no War of Independence would happen. I can't remember Mel
Gibson reported to anybody in Patriot.

I can trust anyone in PMC. OFBiz itself is a brand like a commercial
software.

Why do we need a release version? What we really need is a predictable
vision if OFBiz is our core platform of our business. For example, we
also use OpenCms as our core platform. We developed an OpenCms-LDAP
module and we don't want it to be a part of OpenCms as it's not perfect.
But it's useful,


在 2008-11-15六的 16:36 -0500，David E Jones写道：

> On Nov 15, 2008, at 4:27 PM, David E Jones wrote:
> > OFBiz is not commercial software with paid developers. JBoss may be  
> > available under an open source license, but it is developed under a  
> > commercial model, not a community-driven model like OFBiz.
> >
> > In the case of a community-driven software project, what would a  
> > project manager do? Who would he/she boss around? Who would be  
> > accountable for delivery and how would that accountability be  
> > enforced?
>

I guess no War of Independence would happen. I can't remember Mel
Gibson reported to anybody in Patriot.

I can trust anyone in PMC. OFBiz itself is a brand like a commercial
software and clients should be able to trust.

People do trust open source now.
(ad, you can skip this)
We are offering technical support to T-Systems China on BMW Web Hosting,
the website of BMW China and worldwide is built on Linux, OpenCms,
Tomcat and Mysql, all are open source, except some functions developed
by Interone.

Open source is not a problem any more. Is community-driven model a
problem? If yes, I would suggest CHANGE.

> I hope I'm not getting into revisionist history, but my experience  
> with community-driven software so far is that if someone does propose  
> something and try to recruit others to work on it then it usually  
> fails. Generally the champion of the effort has to work on it  
> themselves, and keep working on it until others start _using_ it, and  
> then they will get involved with improving and extending it. It's just  
> that simple.
>
> Personally I know I've left a wake of unfinished projects where I  
> tried to recruit others and identify a goal to work towards, like the  
> framework improvements and framework-only release (a starting point  
> for higher level releases, something easier). As soon as I got  
> involved in increased workload, moving, and organizing and preparing  
> for ApacheCon and such I stopped working on it... and so did everyone  
> else!
>
> With new things I'm trying to push, like adoption of open standards  
> and building some requirements and designs that we can base future  
> enhancements and extensions of OFBiz on, my plan is to work on them  
> personally as much as I can and do so until others join in.
>
> That's how things get done in community-driven projects: by  
> leadership. That's how everything in OFBiz has been done. Someone lead  
> the way, and others joined in... hundreds of times in the last 7.5  
> years on hundreds of parts of OFBiz. There is a big difference between  
> leaders and manager, and what self-organizing communities need is  
> leadership, not management. That's the meritocracy way.
>
> -David
>

Nobody would say OFBiz is not good. And it's not necessary to proof
OFBiz is good. On the contrary, I think people (at least myself) need
OFBiz promising. If you feel the project is hard to control (I know you
don't like control, I believe you may not like out of control, then
control it), it's a good idea to do the work as you said, narrow your
efforts to framework-only, then the framework would play the role of
tomcat project, OFBiz as the Jakarta, applications and specailpurposes
as the subprojects (including the ex-subprojects) in Jakarta.

In other words, if even you don't know what the next version of OFBiz
would be, how could the others know?

Versioning means promising, means roadmap, means you know, and then we
know, everyone knows where we are going. Then the community can unit
around you, and costomers will put resources into the real projects
based on OFBiz (this is the key reason why I say too much here:)).

Though my tone is not that kind. below are what we will open to the
community for 2009 as a promising (all we promised for 2008 come to
true):
1. Update OFBiz-jBPM component to jBPM 3.3.2 or later and OFBiz trunk.
2. Update OFBiz-LDAP-CAS to support LDAP membership and alias setting.
3. Develop OFBiz-SAML to support SAML(may not the latest SAML 2.0).
4. Develop OFBiz-OpenID
5. Update OFBiz-OpenOCES
6. Develop OFBiz-Lucene-SearchPipeline
7. Continue the OFBiz Chinese localization

Regards,

Shi Yusen/Beijing Langhua Ltd.

[Bruno Busco]

Having a roadmap could simply mean having something like this:

https://issues.apache.org/jira/secure/BrowseProject.jspa?id=12310110&subset=-1
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600&subset=-1
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220&subset=3
or
https://issues.apache.org/jira/secure/BrowseProject.jspa?id=10560&subset=-1

If it is for sure true that OFBiz grows up thanks to contribution that
developers do because they need them with their customers, it is also true
that many efforts have been done, and will be, to have OFBiz more generic,
with a more reusability factor, with a better UI etc.

Those generally are not things requested by a developer's customer but are
things that OFBiz still needs to have something to base a marketing campain
on.

A clear and solid release number is something really needed.
How could we ever write on the site news "Released OFBiz x.y (see release
notes)" otherwise?
The release numbering, IMO, is at the top of the list in the marketing aware
factors.

-Bruno

2008/11/16 Shi Yusen <[hidden email]>

> I guess no War of Independence would happen. I can't remember Mel
> Gibson reported to anybody in Patriot.
>
> I can trust anyone in PMC. OFBiz itself is a brand like a commercial
> software.
>
> Why do we need a release version? What we really need is a predictable
> vision if OFBiz is our core platform of our business. For example, we
> also use OpenCms as our core platform. We developed an OpenCms-LDAP
> module and we don't want it to be a part of OpenCms as it's not perfect.
> But it's useful,
>
>
> 在 2008-11-15六的 16:36 -0500，David E Jones写道：
> > On Nov 15, 2008, at 4:27 PM, David E Jones wrote:
> > > OFBiz is not commercial software with paid developers. JBoss may be
> > > available under an open source license, but it is developed under a
> > > commercial model, not a community-driven model like OFBiz.
> > >
> > > In the case of a community-driven software project, what would a
> > > project manager do? Who would he/she boss around? Who would be
> > > accountable for delivery and how would that accountability be
> > > enforced?
> >
> I guess no War of Independence would happen. I can't remember Mel
> Gibson reported to anybody in Patriot.
> 
> I can trust anyone in PMC. OFBiz itself is a brand like a commercial
> software and clients should be able to trust.
>
> People do trust open source now.
> (ad, you can skip this)
> We are offering technical support to T-Systems China on BMW Web Hosting,
> the website of BMW China and worldwide is built on Linux, OpenCms,
> Tomcat and Mysql, all are open source, except some functions developed
> by Interone.
>
> Open source is not a problem any more. Is community-driven model a
> problem? If yes, I would suggest CHANGE.
>
> > I hope I'm not getting into revisionist history, but my experience
> > with community-driven software so far is that if someone does propose
> > something and try to recruit others to work on it then it usually
> > fails. Generally the champion of the effort has to work on it
> > themselves, and keep working on it until others start _using_ it, and
> > then they will get involved with improving and extending it. It's just
> > that simple.
> >
> > Personally I know I've left a wake of unfinished projects where I
> > tried to recruit others and identify a goal to work towards, like the
> > framework improvements and framework-only release (a starting point
> > for higher level releases, something easier). As soon as I got
> > involved in increased workload, moving, and organizing and preparing
> > for ApacheCon and such I stopped working on it... and so did everyone
> > else!
> >
> > With new things I'm trying to push, like adoption of open standards
> > and building some requirements and designs that we can base future
> > enhancements and extensions of OFBiz on, my plan is to work on them
> > personally as much as I can and do so until others join in.
> >
> > That's how things get done in community-driven projects: by
> > leadership. That's how everything in OFBiz has been done. Someone lead
> > the way, and others joined in... hundreds of times in the last 7.5
> > years on hundreds of parts of OFBiz. There is a big difference between
> > leaders and manager, and what self-organizing communities need is
> > leadership, not management. That's the meritocracy way.
> >
> > -David
> >
>
> Nobody would say OFBiz is not good. And it's not necessary to proof
> OFBiz is good. On the contrary, I think people (at least myself) need
> OFBiz promising. If you feel the project is hard to control (I know you
> don't like control, I believe you may not like out of control, then
> control it), it's a good idea to do the work as you said, narrow your
> efforts to framework-only, then the framework would play the role of
> tomcat project, OFBiz as the Jakarta, applications and specailpurposes
> as the subprojects (including the ex-subprojects) in Jakarta.
>
> In other words, if even you don't know what the next version of OFBiz
> would be, how could the others know?
>
> Versioning means promising, means roadmap, means you know, and then we
> know, everyone knows where we are going. Then the community can unit
> around you, and costomers will put resources into the real projects
> based on OFBiz (this is the key reason why I say too much here:)).
>
> Though my tone is not that kind. below are what we will open to the
> community for 2009 as a promising (all we promised for 2008 come to
> true):
> 1. Update OFBiz-jBPM component to jBPM 3.3.2 or later and OFBiz trunk.
> 2. Update OFBiz-LDAP-CAS to support LDAP membership and alias setting.
> 3. Develop OFBiz-SAML to support SAML(may not the latest SAML 2.0).
> 4. Develop OFBiz-OpenID
> 5. Update OFBiz-OpenOCES
> 6. Develop OFBiz-Lucene-SearchPipeline
> 7. Continue the OFBiz Chinese localization
>
> Regards,
>
> Shi Yusen/Beijing Langhua Ltd.
>
>

[Markus Studer-2]

>> David E Jones wrote:
>>> - Framework release
>>>  - gather ideas from people in a confluence page (TODO: add my own)
>>>  - complex UIs, GWT, DOJO, etc renderers for widgets
>>
>> I've been thinking about the framework release and our current Release
>> 4. Release 4 will be two years old in a few months. A lot has been
>> done to the project since the R4 branch. How about making a Release 5
>> branch (whole project) sometime around Spring?
>
> I think that's fine. Hopefully by then we'll have more framework things
> done.
>
> What I'd really like to hear for releases is what people plan to do with
> the release branch. In general in order to facilitate collaboration and
> such it is best to use the trunk. Unless we have a lot of people using
> OFBiz OOTB then it may not make sense to do releases at all, even "lite"
> releases like these release branches.

Release Handling is tricky and I'd like to give you some infos on the
kind of problems we're facing with dealing with release 4.0, trunk,
patches etc.

We've successfully used OFBiz in multiple projects based on a pre 4.0
release (~6 months before release 4.0). We minor changes to
framework parts, bigger changes to applications and release 4.0 was
helpfull for troubleshooting as it is a more stable reference than the
trunk that moves fast.

There were parts that we wanted to give back to the community and that's
were problems start.

E.g. we translated some applications to german and wanted to give that
back. Unfortunately, instead of .properties in Release 4.0 there are
.xml files in trunk and no easy way to merge that somehow into the
trunk. Currently, I'm redoing some of the translations that we already
did to get that back into the trunk!

Next problem we face: Which version of OFBiz to use for future
customer projects:
- our internal adapted pre 4.0 version (more than 2 years old with our
own internal bugfixes)
- 4.0 release (2 years old with the bugfixes from the community)
- trunk


Option 1 -> our pre 4.0 code

not really a nice option as were loosing all the optimizations and work
the community did in the last years. Backporting new functionality will
get more and more difficult


Option 2 -> Release 4.0

would give us a stable, proven base for development. Unfortunately, this
release is 2 years old and newer functionality is missing. No idea, how
to cope with release 4.0 in a few years. (we also thought about a
migration of our code to release 4.0 but we're not sure if that is worth
the effort)


Option 3 -> trunk

would give us all the new stuff. Difficult to estimate how risky that
is, i.e. how stable the trunk is and what effort is needed to fix
those little bugs in trunk. Once we start with trunk, we won't integrate
newer code from trunk as those changes contain both bugfixes and new
functionality (bugfixes are great, new functionality not as one needs a
stable base to start custom development -> that way we're back with
option 1 in a few years :) ).



One thing you also need to consider is that not having releases has some
  subtle consequences. Everyone who checks out from trunk has his
personal "release". Once you find bugs, you fix them locally but to give
back such fixes becomes more and more difficult -> you need to check out
the trunk, recreate the problem, apply the fix, submit a patch. As every
user has his own "release" (snapshot of time x), working together
becomes difficult (e.g. there is no usergroup using SVN 718108 that has
similar problems that can help or other users that we can help).


Suggestion:

- Framework: Periodical Release (e.g. every 2 years), as the framework
part is stable and mature and it should be possible to get the
functionality defined

- Applications: Is more a strategic decision as it defines more how
OFBiz is used, i.e. more out-of-the Box or as a base for other products.
There is lot of work involved to get releases done, i.e. release
management, define functionality for a release, get concensus on new
features, upgrade paths, documentation. But it would clearly help to
promote OFBiz. Difficult question that remains is how often to release:
release often to get new features in vs. release sparsely as OFBiz
drives your business.

Markus

[Adrian Crum]

Markus Studer wrote:
> E.g. we translated some applications to german and wanted to give that
> back. Unfortunately, instead of .properties in Release 4.0 there are
> .xml files in trunk and no easy way to merge that somehow into the
> trunk. Currently, I'm redoing some of the translations that we already
> did to get that back into the trunk!

There is a Jira issue open on this very subject -
https://issues.apache.org/jira/browse/OFBIZ-2008. Perhaps you could help
contribute to it.

-Adrian

[Joe Eckard]

On Nov 15, 2008, at 4:37 PM, David E Jones wrote:

>> (disclaimer: one guy's opinion, grain of salt, etc.)
>>
>> Speaking primarily as an end user, the "never release" approach  
>> that the project is currently taking encourages me to isolate my  
>> code as much as possible, and discourages frequent upgrades. It  
>> also encourages me to cherry-pick bug fixes, which can make it  
>> tedious to construct patches to send back when I find new bugs.
>>
>> Sometimes I like to imagine a world where OFBiz has major, minor  
>> and point releases (with release notes) similar to what is  
>> described at http://commons.apache.org/releases/versioning.html 
>> (with the compatibility types redefined in OFBiz terms). For  
>> example, any change that modifies a service's signature, or the  
>> data model might require a new point release to include any  
>> outstanding bug fixes, then a new minor release with a simple  
>> upgrade instruction for that change added to the release notes. (in  
>> other words, incompatibility would be the determining factor for  
>> minor & major revision number upgrades)
>>
>> With something like that in place, I could feel confident upgrading  
>> from a theoretical version 4.0.19 to 4.0.23, knowing that nothing  
>> should break, and I don't need to install new seed data or worry  
>> about data model changes. If I wanted some new features in 4.1.x, I  
>> would need to check the release notes to see what incompatible  
>> change prompted the version increase and make adjustments and an  
>> upgrade plan.
>>
>> Maybe this approach just isn't feasible for any number of reasons,  
>> but I have always wondered why there doesn't seem to be any  
>> discussion of something similar whenever the topic of releases are  
>> brought up.
>
> Again just testing the idea, and not saying we should adopt it...
>
> How would you behave if you knew there was NEVER going to be a  
> release, just ongoing community responsibility?
>
> What would your involvement with the project look like? How would  
> you run your efforts that are separate from  the project?
>
> -David

For me personally, nothing would really change... i.e. when a custom  
application is considered feature-complete and relatively stable and  
bug-free, then all OFBiz updates stop, and my involvement with the  
current trunk comes to an end (for that project). There are exceptions  
- when I encounter a bug I'll check the trunk first to see if it has  
been fixed, or when I am catching up on messages to the commits list I  
may notice an important bug fix that needs to be back-ported right away.

This is unfortunate, because it can put me in the same position as  
Markus - improvements and fixes may need to be completely rewritten  
and re-tested before I can create patches for the current trunk. (This  
is the case for me right now - my main codebase is pre-4.0 and I have  
a few changes that I haven't had the time to rewrite and re-test.)

Even if there were more testing in place, the main drawback to staying  
current is that with each update I may be taking on new features or  
applications that my business will never use, but I am now responsible  
for learning about and possibly debugging, just to maintain the  
(previously stable) features I have always used.

Speaking to Shi Yusen's comment about a project / release manager, I  
don't think it would be fair to push this onto any one person when the  
individual committers have all of the information available when they  
make a commit. (Will the change break existing code, does the change  
add a new feature that requires new seed data or a data model change,  
etc.)

-Joe

[Shi Yusen]

在 2008-11-17一的 12:06 -0500，Joe Eckard写道：

> Speaking to Shi Yusen's comment about a project / release manager, I  
> don't think it would be fair to push this onto any one person when the  
> individual committers have all of the information available when they  
> make a commit. (Will the change break existing code, does the change  
> add a new feature that requires new seed data or a data model change,  
> etc.)

I complained to David because he's the V.P. of Apache. He has to listen,
has he? :)

Everybody has the responsibility, nobody really has.

Everybody maintains his own OFBiz, nobody cares about the common one.
This makes me uneasy.

Admire David mentioned the framework-only release plan, hope this come
true soon. Personally, OFBiz = the framework, I don't have to care about
the qualities of the add-ons if I won't use.

Regards,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones-3]

This document has been around for a while, but pretty clearly  
describes options available and which to take when:

http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started

This is a problem that goes back to the beginning of OFBiz, and is  
fairly unique to community-driven enterprise software. You won't see  
the same issue with "commercial open source" like SugarCRM or Compiere  
or OpenBravo or the like, because they develop using a commercial  
model, and not an open source model.

-David


On Nov 17, 2008, at 9:25 AM, Markus Studer wrote:

>>> David E Jones wrote:
>>>> - Framework release
>>>> - gather ideas from people in a confluence page (TODO: add my own)
>>>> - complex UIs, GWT, DOJO, etc renderers for widgets
>>>
>>> I've been thinking about the framework release and our current  
>>> Release 4. Release 4 will be two years old in a few months. A lot  
>>> has been done to the project since the R4 branch. How about making  
>>> a Release 5 branch (whole project) sometime around Spring?
>> I think that's fine. Hopefully by then we'll have more framework  
>> things done.
>> What I'd really like to hear for releases is what people plan to do  
>> with the release branch. In general in order to facilitate  
>> collaboration and such it is best to use the trunk. Unless we have  
>> a lot of people using OFBiz OOTB then it may not make sense to do  
>> releases at all, even "lite" releases like these release branches.
>
> Release Handling is tricky and I'd like to give you some infos on the
> kind of problems we're facing with dealing with release 4.0, trunk,  
> patches etc.
>
> We've successfully used OFBiz in multiple projects based on a pre 4.0
> release (~6 months before release 4.0). We minor changes to
> framework parts, bigger changes to applications and release 4.0 was  
> helpfull for troubleshooting as it is a more stable reference than  
> the trunk that moves fast.
>
> There were parts that we wanted to give back to the community and  
> that's
> were problems start.
>
> E.g. we translated some applications to german and wanted to give that
> back. Unfortunately, instead of .properties in Release 4.0 there are
> .xml files in trunk and no easy way to merge that somehow into the
> trunk. Currently, I'm redoing some of the translations that we already
> did to get that back into the trunk!
>
> Next problem we face: Which version of OFBiz to use for future
> customer projects:
> - our internal adapted pre 4.0 version (more than 2 years old with our
> own internal bugfixes)
> - 4.0 release (2 years old with the bugfixes from the community)
> - trunk
>
>
> Option 1 -> our pre 4.0 code
>
> not really a nice option as were loosing all the optimizations and  
> work the community did in the last years. Backporting new  
> functionality will get more and more difficult
>
>
> Option 2 -> Release 4.0
>
> would give us a stable, proven base for development. Unfortunately,  
> this
> release is 2 years old and newer functionality is missing. No idea,  
> how
> to cope with release 4.0 in a few years. (we also thought about a  
> migration of our code to release 4.0 but we're not sure if that is  
> worth the effort)
>
>
> Option 3 -> trunk
>
> would give us all the new stuff. Difficult to estimate how risky that
> is, i.e. how stable the trunk is and what effort is needed to fix
> those little bugs in trunk. Once we start with trunk, we won't  
> integrate newer code from trunk as those changes contain both  
> bugfixes and new functionality (bugfixes are great, new  
> functionality not as one needs a stable base to start custom  
> development -> that way we're back with option 1 in a few years :) ).
>
>
>
> One thing you also need to consider is that not having releases has  
> some  subtle consequences. Everyone who checks out from trunk has  
> his personal "release". Once you find bugs, you fix them locally but  
> to give back such fixes becomes more and more difficult -> you need  
> to check out the trunk, recreate the problem, apply the fix, submit  
> a patch. As every user has his own "release" (snapshot of time x),  
> working together becomes difficult (e.g. there is no usergroup using  
> SVN 718108 that has similar problems that can help or other users  
> that we can help).
>
>
> Suggestion:
>
> - Framework: Periodical Release (e.g. every 2 years), as the  
> framework part is stable and mature and it should be possible to get  
> the functionality defined
>
> - Applications: Is more a strategic decision as it defines more how  
> OFBiz is used, i.e. more out-of-the Box or as a base for other  
> products. There is lot of work involved to get releases done, i.e.  
> release management, define functionality for a release, get  
> concensus on new features, upgrade paths, documentation. But it  
> would clearly help to promote OFBiz. Difficult question that remains  
> is how often to release: release often to get new features in vs.  
> release sparsely as OFBiz drives your business.
>
> Markus
>

[David E Jones-3]

On Nov 17, 2008, at 12:06 PM, Joe Eckard wrote:

>
> On Nov 15, 2008, at 4:37 PM, David E Jones wrote:
>
>>> (disclaimer: one guy's opinion, grain of salt, etc.)
>>>
>>> Speaking primarily as an end user, the "never release" approach  
>>> that the project is currently taking encourages me to isolate my  
>>> code as much as possible, and discourages frequent upgrades. It  
>>> also encourages me to cherry-pick bug fixes, which can make it  
>>> tedious to construct patches to send back when I find new bugs.
>>>
>>> Sometimes I like to imagine a world where OFBiz has major, minor  
>>> and point releases (with release notes) similar to what is  
>>> described at http://commons.apache.org/releases/versioning.html 
>>> (with the compatibility types redefined in OFBiz terms). For  
>>> example, any change that modifies a service's signature, or the  
>>> data model might require a new point release to include any  
>>> outstanding bug fixes, then a new minor release with a simple  
>>> upgrade instruction for that change added to the release notes.  
>>> (in other words, incompatibility would be the determining factor  
>>> for minor & major revision number upgrades)
>>>
>>> With something like that in place, I could feel confident  
>>> upgrading from a theoretical version 4.0.19 to 4.0.23, knowing  
>>> that nothing should break, and I don't need to install new seed  
>>> data or worry about data model changes. If I wanted some new  
>>> features in 4.1.x, I would need to check the release notes to see  
>>> what incompatible change prompted the version increase and make  
>>> adjustments and an upgrade plan.
>>>
>>> Maybe this approach just isn't feasible for any number of reasons,  
>>> but I have always wondered why there doesn't seem to be any  
>>> discussion of something similar whenever the topic of releases are  
>>> brought up.
>>
>> Again just testing the idea, and not saying we should adopt it...
>>
>> How would you behave if you knew there was NEVER going to be a  
>> release, just ongoing community responsibility?
>>
>> What would your involvement with the project look like? How would  
>> you run your efforts that are separate from  the project?
>>
>> -David
>
> For me personally, nothing would really change... i.e. when a custom  
> application is considered feature-complete and relatively stable and  
> bug-free, then all OFBiz updates stop, and my involvement with the  
> current trunk comes to an end (for that project). There are  
> exceptions - when I encounter a bug I'll check the trunk first to  
> see if it has been fixed, or when I am catching up on messages to  
> the commits list I may notice an important bug fix that needs to be  
> back-ported right away.
>
> This is unfortunate, because it can put me in the same position as  
> Markus - improvements and fixes may need to be completely rewritten  
> and re-tested before I can create patches for the current trunk.  
> (This is the case for me right now - my main codebase is pre-4.0 and  
> I have a few changes that I haven't had the time to rewrite and re-
> test.)
>
> Even if there were more testing in place, the main drawback to  
> staying current is that with each update I may be taking on new  
> features or applications that my business will never use, but I am  
> now responsible for learning about and possibly debugging, just to  
> maintain the (previously stable) features I have always used.

I may be biased on this, but isn't this the main argument for  
contributing as much as possible back to the open source project and  
staying in-sync with the community?

Really... I don't think I could have expressed this more directly  
myself... you wrote very well the reasoning I use with clients to  
convince them that working with the community is better than going it  
alone.

-David

[David E Jones-3]

On Nov 17, 2008, at 2:14 PM, Shi Yusen wrote:

>
> 在 2008-11-17一的 12:06 -0500，Joe Eckard写道：
>
>> Speaking to Shi Yusen's comment about a project / release manager, I
>> don't think it would be fair to push this onto any one person when  
>> the
>> individual committers have all of the information available when they
>> make a commit. (Will the change break existing code, does the change
>> add a new feature that requires new seed data or a data model change,
>> etc.)
>
> I complained to David because he's the V.P. of Apache. He has to  
> listen,
> has he? :)
>
> Everybody has the responsibility, nobody really has.
>
> Everybody maintains his own OFBiz, nobody cares about the common one.
> This makes me uneasy.
>
> Admire David mentioned the framework-only release plan, hope this come
> true soon. Personally, OFBiz = the framework, I don't have to care  
> about
> the qualities of the add-ons if I won't use.

Would it be correct for me to say that you're really looking for  
commercially developed software that you can get for free, and not for  
community-driven software that you can participate in?

-David

[Markus Studer-2]

> This document has been around for a while, but pretty clearly
> describes options available and which to take when:
>
> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started

yes, that document was the base for our decisions.

>
> This is a problem that goes back to the beginning of OFBiz, and is
> fairly unique to community-driven enterprise software. You won't see
> the same issue with "commercial open source" like SugarCRM or
> Compiere or OpenBravo or the like, because they develop using a
> commercial model, and not an open source model.
>

yes, and I clearly prefer the community-driven approach. Just wanted to
give you an idea why it is difficult (with limited ressources) for us to
contribute back when all the work we do is based on older code (and
giving things back is what community driven software is all about).

--
nowhow solutions AG, Laupenstrasse 1, 3008 Bern
Phone [phone], http://www.nowhow.ch

[Jacques Le Roux]

Be sure that we all appreciate your help Markus (I mean nowhow in general) !

Jacques

From: "Markus Studer" <[hidden email]>

>> This document has been around for a while, but pretty clearly
>> describes options available and which to take when:
>>
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
> yes, that document was the base for our decisions.
>
>>
>> This is a problem that goes back to the beginning of OFBiz, and is
>> fairly unique to community-driven enterprise software. You won't see
>> the same issue with "commercial open source" like SugarCRM or
>> Compiere or OpenBravo or the like, because they develop using a
>> commercial model, and not an open source model.
>>
>
> yes, and I clearly prefer the community-driven approach. Just wanted to
> give you an idea why it is difficult (with limited ressources) for us to
> contribute back when all the work we do is based on older code (and
> giving things back is what community driven software is all about).
>
> --
> nowhow solutions AG, Laupenstrasse 1, 3008 Bern
> Phone [phone], http://www.nowhow.ch
>

[David E Jones-3]

On Nov 18, 2008, at 3:34 AM, Markus Studer wrote:

>> This document has been around for a while, but pretty clearly
>> describes options available and which to take when:
>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
>
> yes, that document was the base for our decisions.
>
>> This is a problem that goes back to the beginning of OFBiz, and is  
>> fairly unique to community-driven enterprise software. You won't see
>> the same issue with "commercial open source" like SugarCRM or
>> Compiere or OpenBravo or the like, because they develop using a
>> commercial model, and not an open source model.
>
> yes, and I clearly prefer the community-driven approach. Just wanted  
> to
> give you an idea why it is difficult (with limited ressources) for  
> us to
> contribute back when all the work we do is based on older code (and
> giving things back is what community driven software is all about).

Yeah, understood. That's the reason for the recommendation to use the  
trunk and stick with the community. Otherwise, you're going it alone.  
With small resources it's difficult, and while larger numbers of  
resources help in a way, they seem to just result in more distance  
from the trunk which makes it more expensive (and less likely) to get  
back in-sync with the community.

Regardless of the number of resources, it just has to become a way of  
working, and it works well for teams small and large. Based on  
experiences with dozens of clients over the last seven years the  
pattern could not be more clear. Those that update frequently and  
stick with the community have a much better experience and far fewer  
issues than those that "go it alone". It's really that simple.

The same is true for release branches too, you're just dealing with a  
smaller community and less changes. For customization efforts this  
isn't so great though because new features can't go into a release  
branch, so for those you're stuck and on your own since the main body  
of the community has moved on.

It's a tough situation any way you look at it. If you want new  
features, and you want to collaborate with others, then the only real  
option is to use the trunk and stay up to date (at least during  
development cycles, and during pre-production testing periods you  
would stop updating temporarily).

That's the only solution I've seen that works, and with a little  
explanation I've found that clients really go for it and at Hotwax  
we've actually won many contracts over other service providers because  
we do that as a general practice and are so involved with the  
community (ie we don't "go it alone").

-David