Thanks for your comments Shi. This is great stuff, and looking forward to working with you more and seeing the results of these efforts.

On the requirements versus implementation thing (with design in the middle), I agree that is a huge deal. It is almost impossible to expect a single person (a superman as you call it!) that can really do both the business and the technical sides of any enterprise system really well.

I've spent most of that last few months working on improving and better defining these things at Hotwax Media (especially now that we have around 50 people in the company in different roles and with different expertise).

I'm not sure if there is anything that can be done through OFBiz itself to help service providers do a better job with these sorts of things, but if anyone has ideas for anything we can do together to help service providers grow, let's get it on the table. I have been considering a book of some sort since I have put together enough material in the last few months to easily fill a book on the topic...

-David


On Apr 30, 2008, at 12:37 AM, Shi Yusen wrote:
+1.

David mentioned a main puzzle for OFBiz: how to lower down the
requirements on a OFBiz programmer. Currently, a qualified OFBiz
programmer must be a superman. I think split the requirements to
consultant part and programmer part may help. As we know, in large
service providers, consultants contact customers and sometimes even have
the power to change customers' decissions on IT platforms.

For consultants, a standard OFBiz consulting proceedure is required.
From our limited pratices, perhaps fish-born diagram is an effective way
to help consultants setup a bridge between OFBiz customers and OFBiz
programmers. The main born is the core business process of a customer
and every small born is a component in OFBiz such as order, catalog and
etc.

Making a room for consultants, having a room for OFBiz.

BTW, here are our contribution plan of this year on OFBiz (for
programmers ^_^, you can get the plan's Chinese version here:
http://www.langhua.cn/jianjie/dev-plan-2008.html):
1. Digital Signature component (based on OpenOCES, coming soon)
2. Single Sign On component based on CAS
3. Continue the Simplified Chinese translation
4. Portlets based on rmiservice component
5. OFBiz + jBPM (coming soon)

Regards,

Shi Yusen/Beijing Langhua Ltd.


在 2008-04-29二的 22:06 -0600,David E Jones写道:
On Apr 29, 2008, at 2:54 PM, Ean Schuessler wrote:
David E Jones wrote:
This is a great tool. The problem with the tool and the approach in
general to this sort of release management is that it assumes top-
down management of a project.

In the Release Plan document it starts out by explaining the nature
of OFBiz and the community that drives it. Most ASF projects, and
many other open source projects, are community driven but are also
more limited in scope and have either an existing specification to
work toward, or have a sufficiently limited scope that the
definition of targets for a release is not overly burdensome.

With OFBiz it's not just the size of the scope, but the fact that
the scope depends on what different contributors to OFBiz need over
time, for themselves or their clients/customers. If we had a budget
for driving OFBiz top-down that could result in the same volume of
progress it would have to be around $5-10M per year (my own
estimate of course, no Gartner or the like has deigned to look into
this).

In short there is a reason why OFBiz is the only real community
driven open source enterprise automation project out there. The
closest alternative is probably Adempiere, but that is more of a
community driven effort to replace a bad vendor that has mostly
stepped out of the picture.

So, until someone comes along with a sufficient budget to drive
things in a more "traditional" way, we have to stick with what
works according to what people are willing and able to contribute.
I think if we really believe in the community oriented model that we
shouldn't view ourselves as "just waiting for a budget to go back to
a top-down model". We know that the top-down model always leads to
lock in and all the other negatives of a single monolithic vendor.
The Linux kernel has already shown that you can get distributed
scale with multiple large vendor players giving the power assist. I
think that's the future we want to be living in.

I can't speak for everyone here, but my opinion of the driving force
behind OFBiz is definitely the community. My comments were not meant
to imply that certain things can't happen without corporate or other
sponsorship from a big enough single entity, but that such is not the
nature of the OFBiz community or any community driven projects, so we
have to rely on what people are willing to contribute, a la the
community driven open source model.

That said, one of the big objectives as I see it now for OFBiz is to
develop the community, a sort of business development for open source
projects. Our focus in the past for community develop has been mostly
around fostering and encouraging contributors. Now that we have a
strong framework and generic business artifacts base in order for
adoption of OFBiz to grow we need stronger service providers and a
wider community of users, whether or not they also participate as
contributors.

My reasoning behind that is that most enterprise (and other) products
are created and driven by a central company and to a large extent it
is the reputation and name of that company that drives people to
accept and desire the software offered.

While OFBiz itself can be a brand that we as a community promote,
OFBiz itself has no funds for marketing or evangelism, leaving the
burden of those efforts to the community, to whoever wants to
contribute such things. In order for large companies to use OFBiz on a wider basis they need a reputation and name to sell to stakeholders in their organization. Eventually I hope that OFBiz will have such a name
on its own, but for now that's sadly not the case.

In short if we can work together to attract larger services
organizations to the OFBiz community and to grow services
organizations working based on OFBiz it will open things up for the
next stage of growth and progress for the project.

Right now there are large services organizations using OFBiz, but not
advertising such or proposing it to their clients so much, partly
because of limited internal skilled people available (from what I can
tell...). Most of their projects are because their clients are
requesting OFBiz, but the services organizations are not recommending
it. Some examples I'm aware of include Euro/Amer companies like
Accenture and Indian companies like TCS, Satyam, etc.

I'm not sure if these companies are used to recommending solutions and
doing marketing, but they are the largest organizations involved with
OFBiz (aside from end-users) and because OFBiz doesn't have it's own
marketing budget and coordinated efforts, the service providers are
the only ones with a sufficient commercial interest to invest in this.

Now, if we could get press attention even though we don't have money
to push it we might make some great progress. However, and this might
be based on my jaded view of the world, but most press organizations
talk about what is making money, even in the open source world. Apache
gets in the news sometimes because of games played with Sun and
others, and because of large user bases for lower level tools in many
cases.

Anyway, this is a big effort going forward that I've been thinking
about lately, ie the business development around OFBiz... not so much
of OFBiz itself as that only applies so much, but around OFBiz.

That said one of our big tools for that is to do GA binary releases
and make a big stink about them. That's probably the strongest tool
any open source project has.

To start that off I'd like to focus on the framework and do a release
branch and a GA binary release of it. After that we'd move on to the
base applications along with the framework. For the framework itself
the things that we need help with and to consider are:

1. is there anything in the framework that we should or want to clean
up before we do a release and "set things in stone" more than they are
now?

2. are there new features that we've been talking about for while that
we should just develop and include? (the entity field automatic
auditing feature is one I decided to spend a couple of hours adding
yesterday; LDAP auth OOTB would be another nice one to add, and I'm
sure there are more)

3. are there critical bugs or security holes we should fix? (one thing
that comes to mind is tools and default behavior where applicable to
protect against XSS/cross-site-scripting)

4. who can help with this? who can help test and write unit tests for
the framework? who can help implement new features and fix bugs and
such?

What we really need here from contributors is pro-active effort. If
you'd like to help but you're not sure what to work on you can ask,
but please be sensitive about requesting assistance or mentoring from
core developers or other contributors as that may keep them from doing
things that can be directly contributed. In other words, we need
people who can help get this done and while we're at it if there are
others who want to get involved please do in a pro-active, self-
motivated way.

BTW, sorry for hijacking your comment Ean... I've been thinking about
this a lot lately and responding to your comment seemed to flow into
this.

-David




Reply via email to