[Vtigercrm-developers] An Impassioned Plea from a VTiger Integrator

[Dennis Grant]

> v4.x would not be abandoned while there is people interested in
> maintaining it, that's all needed in open source, interested and
> executive people...
> it can be mantained forever while this condition is met...

Yeah, but is it worth it?

The 4.x codebase is really - sorry guys, I don't mean to take shots at
you - but let's face it; it's really very nasty.

Some of it is a good deal better than others... but there are three or
four different coding paradigms all mixed together just on database
queries alone, never mind display models and modularity and whatnot.

It *works* great, but it's a serious bitch to maintain.

As I mentioned earlier, I haven't looked at the 5.0 codebase, but it is
my hope and expectation that it is a lot better.
 
> and I agree with you that there was (is ?) an utterly lack of
> receptive response to community developers from the core team, 

No kidding....

> and the
> project was crying for a fork, but all those people creating private
> forks also lacked the balls to create a serious *public* fork...

> I mean, if you are going to fork, then fork in all it's glory...

Dude, I *NEVER* wanted to fork. I'd be *MUCH, MUCH* happier if I could
run a vanilla install of VTiger with zero custom code in it.

I was forced into forking by a lack of response from the core dev team,
yes - but more so by the fact that I had users who wanted features and I
needed to get them done NOW.

> those people that never submitted a patch, never figthed for more open
> development, created their own private branch, and then came up here
> whining, are ... well, whiners IMO

Ahem. 

I tried to get patches into the core. I tried to get the dev team to do
stuff by reporting bugs and providing detailed debug info. But there are
limits as to how much time in a day I can burn trying to get an
unresponsive dev team to fix my bug. 

"Why is this still broken?"

"Well, I reported it to VTiger last month, and they haven't fixed it
yet....."

That just doesn't cut it. 

> My point was that we should find
> a way to welcome these wayward forks back to the fold.  How?  I
dunno..

Well, the way I'm going to do it is to roll all my features into 5.0
(which is a huge job, but so it goes) and then cut a patch set for
merging into the main core. My expectation is that VTiger's version of
Linus (or Alan Cox, or whoever) will then go through the patch set, and
then either merge or reject patches based on merit - just like in the
kernel.

I will then work on trying to address concerns with my rejected patches,
so as to get them accepted, except in cases where the patch is clearly
local in scope - and those I will maintain myself.

BTW, who is the local Linus?

> So after the wind clears.. my point really comes down to getting all
> these folks who are working on private forks to come back to the
> community project, regardless of their justification (or lack of) for
> the fork. In an OSS project your most valuable resource is your
> developers and if we can find a way to get them back it will be well
> worth it IMHO.

I agree - and the best way to do that is to be RESPONSIVE.

I understand that *my* problem may not be the top priority.

I understand that core dev team members are NOT going to just drop
everything and look after me.

But I *do* expect a response, and to get into the pipeline, and to be
given reasonably regular status updates on the status of my problem.

And if I submit a patch, I expect it to be reviewed and either accepted
or rejected in a reasonable timeframe.

I don't know how many of you were/are involved in Linux kernel
development, but I used to get help from people like Alan Cox and Linus
on a regular basis. If a particular bit of hardware wasn't working, and
it looked like a bug in Linux kernel code, we'd trade emails on a daily
basis to debug the problem. That's the level of service we're talking
about.

And this is a good start:

> Your comments are well taken. These will be in place at the earliest. 
> I know that this will be a quick fix but instructions have been sent 
> across to have the code properly commented from now on for any future 
> development/bug fixes.

Thanks!

DG