Carsten,
Thank you for a well thought out email, and for the specific
recommendations you included. Without those sorts of things discussion
isn't really possible.
That said, I think in general you confusing a centrally planned and
manage organization with an all volunteer community. I'll try to be
more specific inline...
Before getting into the details, please forgive me if what I write is
too terse. This misunderstand is extremely common and is frequently
enough discussed that I've written blog posts on the topics over the
years. Just keep in mind that there is no "boss" around here, and the
community is in charge. Because of that the only thing that matters is
strengthening the community because once there is a community then the
community can do things. If there is no community, then there is no
one to do things... and with no boss handing out paychecks or
something of the sort there is no way to get people involved.
If you think I'm wrong as you read through this, then by all means
propose other ways of getting people to do things!
On Nov 13, 2009, at 8:59 AM, Carsten Schinzer wrote:
Hi all,
in case you waited for my 0.02 EUR :
I tend to agree with Jacques: OFBiz is a ERP framework (with loads of
ecommerce capabilites, I agree, but think of all the queries 1-2
months ago
on this list about configuring for manufacturing workflow etc.)
I do miss more comments and advancement in the accounting area, but
i am
working on that myself.
That's great. What tends to happen is that as people start working on
an area they will find that others reciprocate and collaborate back
with them, leading to active development and use of a part of the
project. For more on this concept:
http://osofbiz.blogspot.com/2009/06/open-source-community-collaboration.html
I would be very much in favour of a bi-annual release schedule, say
a spring
and an autumn release. (I think that's not a surprise to anyone).
And I
think that's feasible, wouldn't it?
More frequent releases are certainly possible, but what would you like
to have happen as a result of this, and what do you think will
actually happen based on what has happened with the current release
branches?
I can't answer the first question, and would be interested in your
answer. I can take a stab at the second question:
What seems to be happening with the release branches is that there
simply aren't enough people interested in maintaining them to actually
get bug fixes contributed to the release branch. This has happened
more with 09.04 that with 4.0, but we're still in a situation where
the majority of the fixes that go into 09.04 are simply back-ports
from the trunk (that are sometimes wrongly assumed to be applicable to
the branch).
In order for a branch to be useful as a tool for stabilization it
needs a number of users who are also able to, and interested in,
fixing bugs in the branch and contributing them. In other words, a
community with healthy collaboration needs to form around the branch,
otherwise it won't really happen.
A community willing to collaborate, and some sort of motivation to
contribute, is the most important thing, and in fact is the main
priority to get things to happen because once that is in place the
actual bug fixes or whatever will naturally flow. If that doesn't
happen, then no bug fixes (or very few) will ever happen.
In addition to the blog posting above, this one about community versus
code might be helpful:
http://osofbiz.blogspot.com/2008/01/glass-cathedrals-and-community-versus.html
However, as stated a couple of times here, there are some
preparatory steps
/ functions not being fulfilled right now (at least not obviously)
which I
think any IT project - and similarly an open source project -- will
need to
fulfill if it takes it's responsibilities more seriously:
- Scope Management -- could be introduced by e.g. classifying bugs
and
feature requests from JIRA
- Release maintenance should focus on bugs, not features
- Major releases should focus on new functionality; if all feature
requests being handed in during a 6 months period are too heavy:
start
splitting into the component sets and only put e.g. framework and
applications under release management and let special-purpose
develop it's
own way. There could be a way to treat specialpurpose applications
as
sub-projects (as e.g. Ant does)
As Jacques mentioned some of these are very much already handled in
OFBiz. We have things setup so that people interested in #2 (a release
branch) can form a community around a release and make those bug fixes
happen, and so that people interested in #3 (the trunk) can contribute
and collaborate as they will there.
How do we get people to do these things? Well, there is no top-down
management... more on that below.
That is the reason why I asked for statistics on JIRA the other day.
In
order to see whether these splits would make sense. I think, though,
similar
to other ASF projects, it's mainly up to the committers, more
precisely the
PMC members, to manifest how they want to move forward.
This is the core of the confusion. The PMC does NOT drive the
direction of the project, we simply moderate what happens and
facilitate collaboration as people demonstrate their desire and
ability to do so. All the PMC does is vote on who to invite as
committers and who to invite to join the PMC, vote on releases and
other "official" actions, and on occasion vote on conflicts that can't
seem to be resolved any other way (I don't think this has ever
happened, BTW).
To take this one step further... what would it look like if the PMC
did drive the direction of the project? How would the PMC do so? All
the PMC could do is prevent people from doing things since there is no
incentive or force that the PMC can apply to get people to do things.
Would you want to participate in a project where you had to get
permission from the PMC in order to work on something, or where you
could only work on the things the PMC has designated? I'm not sure
what that would do to the project, but I can say that I wouldn't be
interested in being involved with such a project...
Anyway, thanks again for your comments and I'd be interested in
hearing about your thoughts as you read this, whether you agree or not.
-David
2009/11/13 Jacques Le Roux <jacques.le.r...@les7arts.com>
Here is the release plan so far
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
Jacques
From: "Christopher Snow" <sno...@snowconsulting.co.uk>
Hi Jacopo,
This is my understanding of the conflict in interest:
1) Ofbiz as an ecommerce focused application with ERP that is
developed on
top of unstable trunk and kept updated via svn and patches.
versus
2) Ofbiz as a stable shrink wrapped ERP application that has
professional
releases and smooth updates (e.g. for security). Also, the
separation of
Ofbiz as a standalone modular development platform with add on ERP
modules.
Cheers,
Chris
Jacopo Cappellato wrote:
On Nov 13, 2009, at 2:05 PM, Ruth Hoffman wrote:
Hi Chris:
IMHO: Having watched the project for a long time now, I think it
is time
for a fork in the road. There are too many competing interests
here.
Uh... I am missing your point now: what are the competing
interests that
you are mentioning? I don't see any competing interest in this
thread.
This sort of reminds me of Unix before AT& T let BSD birth. No?
And look
what that spawned :-)
Yes, it could become the Linux equivalent for the OFBiz world...
or it
could become one of the many thousands of forks (the 99%) in the
history of
software projects that just are ignored.
Jacopo
Ruth
Christopher Snow wrote:
Thanks BJ - that's the conclusion I'm starting to reach.
Perhaps it would be worth some of us like minded people to
getting
together?
BJ Freeman wrote:
I had the same complaint at one time.
I now keep my own version under a different brand name.
That is about all you can do.
Christopher Snow sent the following on 11/13/2009 2:40 AM:
Jacopo Cappellato wrote:
On Nov 13, 2009, at 11:26 AM, Christopher Snow wrote:
I was thinking about your comment of leaving the components in
place
even though they are not used. Does leaving unused
components in
place have a performance impact on ofbiz? Do those
components
consume memory? - they are certainly using disk space.
Some of the
components for example BIRT consume a fair amount of space.
Disk and memory are very cheap nowadays...
I think I have answered your other concerns in another email.
Jacopo
Disk and memory are cheap nowadays, but small businesses
don't see
it
like that, for example David Jones' ezBiz will be competing
with
lightweight applications like OpenERP.
Also, there's the security issues of having code running that
isn't
required.
Anyway, I get the picture. A modular ofbiz is not an option!
People
in
control like ofbiz just the way it is - it suits their business
model.
--
Best
Carsten Schinzer
Waisenhausstr. 53a
80637 München
Germany
