>> Perhaps a good 99% of the population don't want to hear the 3 letters "SVN"
>> when they attempt to download and test OFBiz.

> There is certainly a target audience in that. But consider the nature of
> OFBiz: it is most commonly used by developers or analysts that full-on
> customize or at least significantly configure OFBiz to make it possible
> to use in their businesses. It just isn't designed and hasn't been
> implemented for OOTB (out-of-the-box) use.

But isn't there value in mass market? The classic "funnel" structure?

If 100 people knew about OFBiz, maybe 90 could get interested due to the easy download and install process. With SVN, maybe only 10!

If 90 download OFBiz, maybe 9 will customize it themselves. The others might be interested enough to find help customizing it, if they see a polished or shrink-wrapped product (no half-implemented features that send them flying off cliff when they click on one). If OFBiz has many "red screens of death" (who coined this quote?) with most button clicks, maybe none of those non-techies will buy it.

It's a numbers game. I don't think you need to pay much attention to the non-techie testers. Well, unless they submit bug reports, tons of it. But then, isn't that good for stabilizing the release branches of OFBiz?

I was from sales and marketing before, so the funnel phenomenon is deeply entrenched. 9 rejections out of 10 is great result to me. That's why I'm still thinking that hitting 100 folks with binary release is still better than hitting 10 folks with SVN release. The top of the funnel has to be large.

> Also consider that what we really need for a strong community is for
> users to offer feedback and contributions to move the project forward.

Then wouldn't we want more non-techie testers? The common complaint I hear is that there just isn't enough testers and bug reports for the release branch.

> In fact that is the ONLY way that OFBiz moves forward as there is no
> company that owns or sponsors OFBiz.

Some want to own forks. I can't help that. As I had always said, this aspect of strategic planning for open source project like OFBiz is beyond me. I can't comment on this.

> the thought of having thousands of users who don't want to customize and
> don't contribute is REALLY scary. Imagine all of the complaints and problems
> that the current community isn't big or experienced enough to support for
> free in a good old community fashion...

On other hand, what about the thought of having OFBiz 4.0 largely untested, and hardly a candidate for binary release even after a long year? Maybe a balance somewhere is good?

I don't think the community is inadequate to handle every and any bug reports that can come in for OFBiz. If you're worried about making a bad first impression because we rolled out a largely clunky release, you gotta know that first impression was already formed even now. The fact that there's no binary release already gave many folks a first impression. It's always work-in-progress, and pain (in form of insulting bug reports if need be) is a good way to improve.

I'll be upfront with you about my own struggles in this locale. To me, OFBiz is fighting against QuickBooks, NetBooks, NetSuite, even SAP. Time after time, my propositions with OFBiz loses against those polished products. The first impression was already formed. (So I'm forced to package OFBiz into a stable fork for them, unfortunately.)

You got yourself, Al Byers, Andy, many others. And now even Adrian Crumm is becoming an expert in the Widget Engine. Sure, there is room for improvement everywhere. But I really don't think the community is inadequate in technical skill sets.

> To put it in more concrete terms: if I have to spend 20 hours a week
> researching stuff so people don't commit things that are inconsistent or
> difficult to manage or contradict or break things that exist, where do I get
> time to actually do administrative tasks like creating a binary release?

I see. Is that why you think the community isn't ready for big-bang exposure?

Fine. I'll learn whatever necessary to create correct and streamlined patches (I did). I'll read whatever I'm told to. Be strict about the coding conventions. If it will shave that time down from 20 hours to 2, be strict about it.

Problem: bad contributions that require administrative overhead to screen and 
process

Possible solution: certify contributors

Sigh. Are we really that bad?

> Your comments are always welcome. Feel free to re-hash too, things certainly
> change over time.

Ok. I know, things will always change.

> Just don't be too surprised if I pull out every gun I can think of to argue
> against something that I think will be bad for the project, especially if I
> am re-writing the thoughts.

If you didn't, I'd think the project is dead.

For what it's worth, seeing you manage the contributions going into OFBiz is a needed sign for many of us that things are moving along.

Jonathon

David E Jones wrote:

On Nov 26, 2007, at 10:32 AM, Jonathon -- Improov wrote:

The way we are doing it now, it's anal-retentive. It's like saying "wait, boss, one more bugfix, just one more", and saying that for a whole long year! I usually publish "release candidates" for my boss, let him test it, let him scream the bug reports to me, then release the next "release candidate" when he's gotten upset enough.

Maybe the way you are doing it now... "we" is going a little far...

Ok, next question. So why not just let the whole world test the moving OFBiz 4.0 branch? Why bother with publishing tarballs and release candidates? Here's a simple analogy. Try telling our bosses "boss, can you learn some SVN and test my bugfixes, so I don't have to prepare tarballs for you?". Perhaps a good 99% of the population don't want to hear the 3 letters "SVN" when they attempt to download and test OFBiz.

There is certainly a target audience in that. But consider the nature of OFBiz: it is most commonly used by developers or analysts that full-on customize or at least significantly configure OFBiz to make it possible to use in their businesses. It just isn't designed and hasn't been implemented for OOTB (out-of-the-box) use.

Also consider that what we really need for a strong community is for users to offer feedback and contributions to move the project forward. In fact that is the ONLY way that OFBiz moves forward as there is no company that owns or sponsors OFBiz.

So, we WANT people to use OFBiz from SVN. I don't know about the others who are involved more actively in managing and moderating OFBiz (ie the PMC members and committers), but for me the thought of having thousands of users who don't want to customize and don't contribute is REALLY scary. Imagine all of the complaints and problems that the current community isn't big or experienced enough to support for free in a good old community fashion...

Don't get me wrong, I ONLY wrote what and I wrote and don't read other stuff into it. This (a binary release) IS something that is necessary to help grow the project, but with limited resources and most of those going into trying to stabilize development and contributions because most contributors write WAY more than they read and research... we are where we are, and it is what it is. To put it in more concrete terms: if I have to spend 20 hours a week researching stuff so people don't commit things that are inconsistent or difficult to manage or contradict or break things that exist, where do I get time to actually do administrative tasks like creating a binary release?

Also, given that the 3rd-party binaries (more than 50% of OFBiz download size is *not* OFBiz codes!) is in the SVN, it is in the OFBiz PMC's interest to lessen the load on the SVN server wherever possible.

Nice try. Machines are machines and are cheap and easy to manage. People are people and are expensive and difficult to manage. It's that simple. If it makes things more difficult for developers it will hamper or kill the project.

Not gonna happen, especially if we want it to be possible to have enough resources to put together a binary release anytime soon...

Just my 2 cents. I'm feeling very embarrassed for beating this topic so much to death by now.

Your comments are always welcome. Feel free to re-hash too, things certainly change over time. Just don't be too surprised if I pull out every gun I can think of to argue against something that I think will be bad for the project, especially if I am re-writing the thoughts.

-David


Reply via email to