Re: [Phpgroupware-developers] Communication ... again (was PHPDoc s for head)

[Alfonso Guerra]

Greetings,

Foreword: Before anyone replies to me let me tell you in advance I'm  
going to delete your response, so don't even bother. I don't care what  
rationale or excuse you give for your behavior, it isn't justifiable.  
So before you hit that reply button know how I will respond to you:  
Delete. Delete. Delete.

Just a quick introduction before I start throwing my two cents in so  
you can understand where I'm coming from.

Back in December 2004 I reviewed over 14 Open Source CMS packages.  
Based on my needs I selected eGroupWare. At that time I wasn't aware of  
phpGW, but as you'll see later it wouldn't have made a difference. My  
objective was to pick the CMS closest to my needs and then port/develop  
apps to it as needed.

In the course of learning eGW's internals I learned about phpGW, the  
probiz contributed docs, the political squabbles, eGW forking from  
phpGW, etc.

This is the primary reason I hate the Open Source movement: rather than  
being motivated to cooperatively build a community, its proponents are  
seeking to gain control over how others work and the work they produce.  
"I want my source code, and I want your source code and you better give  
it to me or you're evil."

It's all about control. It's all about how you treat others when you  
have that control.

When maddog (John Hall) gave a presention to our local user group last  
year, he said the primary factor behind what he believes to be Open  
Source's inevitable success is the scalability inherent in its  
development. That as a result of having so many developers able to work  
on source code tailored to their own and customers' needs, the Open  
Source movement will overwhelm any proprietary competitor solely on the  
basis of sheer numbers.

It ain't likely, and this whole phpGW/eGW/etc situation is a perfect  
example why. Some guys were unhappy with the way the project was  
progressing so they forked the project and started eGW. I came across  
eGW and, finding its claims the closest to my site objectives, set up  
my site using it. As I began learning its internals and the way it  
worked I discovered phpGW and the whole forking business, and looked  
into using phpGW instead as I dislike political squabbling and the  
pettiness that is forking.

However, whereas the eGW installed and configured easily and looked  
professional, I wasn't even able to get a working phpGW installation  
and what I _did_ get was klunky and sloppy. I thought it might take a  
couple fixes to get the system working, but lowering the error  
reporting level to E_ALL displayed over 1100 notification errors in one  
module alone! That's simply unacceptable as I can't develop the code  
for my site, fix the phpGW code to bring it up to production quality,  
and factor out the eGW differences to send in my patches just to make  
your job easier in picking up my changes. I'm not gonna do it. That  
doesn't _scale_. Not positively, anyhow.

Multiple developers working independently on project changes which are  
not integrated back into a common repository does not scale well. Not  
for system developers. Not for application developers. Not for  
administrators. Not for users. Each fork produces an extra competitor  
and noise in the market and takes time away from the development time  
you have. Each fork reduces the size of the development team and the  
user base making your product less attractive to planners and  
implementers reviewing systems for a new site.

That's why Open Source will never achieve global dominance: frail egos  
and childish posturing to claim The Absolute Truth; hence, the moral  
right to deny any heretics from contaminating your Holy Work. It  
doesn't matter whether the issue is licensing, programming language,  
source code conventions, toolchain or committing changes to a module  
without waiting for someone else's okay. As long as your agenda is  
protecting your dogma, those whose vested interest is profit will  
figure out a way to deal with one another's quirks and produce a  
solution that beats yours and they'll get it done faster.

I reiterate: _Do_ _Not_ _Reply_ _To_ _Me_. I already know what the  
responses are and I will be ignoring and deleting emails without regard  
to content. You think you're justified in insisting things should be  
done your way. (Delete. Delete. Delete.) I don't. You think you deserve  
to be heard. (Delete. Delete. Delete.) I don't. You think once you've  
completed your masterpiece and revealed it to the uneducated masses  
that all will marvel at the majesty and wonder that is you and shower  
you with praise and honor and glory for you to bask in for the rest of  
your life. (Delete. Delete. Delete.) Truth is, hotshot, that the rest  
of us think of you the same way you view the rest of us:  as a pompous  
ass. The only reason I've given any thought to you at all in the past  
was for the _potential_ that you might be able to further _my_ goals,  
NOT (Yes, I used all caps. Deal with it. Delete. Delete. Delete.) to  
get a glimpse of your Enlightenment.

I'm smarter than you are anyway. I'm no longer referring to the  
individual phpGW developer either. I mean all you phpGW developers put  
together. I am smarter, way smarter. I'm even smarter than you and the  
eGW guys and the phpNuke guys and the TWiki guys and the developers of  
every other CMS out there put together. The primary reason is simple:  
you guys are unwilling to work together. I don't slow down my project's  
forward progress. You do. And if your output is inferior to mine, you  
might as well be inferior.

The phpGW is now in its third generation, from you guys to eGW to me.  
Three separate projects. That's three isolated design, documenting,  
coding and testing efforts being undertaken. That's a lot of redundant  
work. Picking up the eGW tarball saved me time to get a site up. But  
it's going to end up taking more time to redo the phpGW core and the  
existing apps to suit my needs than if I coded the whole thing from  
scratch. I'm going to have to delicately make changes in a production  
system just to get it right. That won't bring scalability to my project  
and without a means of pushing the changes back upstream it certainly  
won't bring any to yours.

By the way, I'm not going to release the source as yet another forked  
project on the net. (Delete. Delete. Delete.)

To scale, each person has to tackle a different issue and integrate his  
solution into the project. That means there's going to have to be some  
delegation of duties and a willingness to give up some control and  
trust others to do what you don't have time to do.

Source code should make, at the least, a linear progression to any  
state. The changes from your code to mine to the next site's should be  
moving continually upwards over time as the codebase migrates. Ideally,  
it would progress exponentially as the efforts of several cooperative  
developers are integrated into a single codebase. Unfortunately, the  
typical progress is more akin to that of a drunken sailor as each  
developer focuses solely on his own comfort and not on learning how to  
work with others.

So, keeping that in mind, here's my input on the situation. After  
reading it you can do what I do. Delete. Delete. Delete.

On Apr 20, 2005, at 6:44 AM, Dave Hall wrote:

> On Wed, 2005-04-20 at 11:12 +0200, Mailings - Christian Boettger wrote:
> >  G'day!
> >
> > > From: Dave Hall [mailto:address@hidden
> >
> >
> > > That's probably because I don't trust Kai.  Kai has a habit
> >
> > And he seems not to trust you in turn. How do we get out of this  
> > circle?
> >
> >
> > > Kai (and atm others at probiz) have a habit of running their
> > > own races.
> >
> > Just like you perhaps? Or like anybody else from time to time?
> >
> > In the end, Kai's fixes do help the project.
> >
> > Calm down, both of you.

Posturing. I've already covered this above.

> > > If the project was pbGroupWare that would be fine, we would
> > > have to live with it.  It isn't pbGroupWare, the project will
> > > never be pbGroupWare, so you need to work as part of the
> > > team, not run your own race.
> >
> > OK; if you want probusines to fork out: just say so. Perhaps they  
> > consider
> > it. I would hate it. But:
> > I'm not setting any probusiness policies with regards to phpGW any  
> > more.
>
> I am not saying fork, I am saying the project is bigger than probiz and
> address@hidden need to not act like this is a probiz project.  Probiz is
> just one group of devs within the project, there are many others both
> individual and companies.

Posturing.

This _is_ a probiz project. They have a lot invested in it and can  
rightly claim ownership. This is _your_ project. You have a lot  
invested in it and can rightly claim ownership. Being Open Source,  
_everyone_ can claim ownership in it and _noone_ can deny ownership to  
anyone else. It doesn't matter if the probiz guys declare themselves to  
be emperors of the project and wear crowns, so relax. As long as  
they're contributing to the forward progress of phpGW, don't get hung  
up on titles.

You're going to have to live with the way they do things anyway as  
they're teammembers as well. And they're going to have to live with the  
way you do things as you're a teammember.

> > It would bring phpGW up into the top list of projects bringing devs to
> > fork...
>
> No phpNuke (and derivatives) still top that list by a long way :P
>
> Shall we add the recent egw fork to that list too ;)
>
> > > I think a public discussion about the setup changes fips is
> > > proposing should also be on this list, not via phone calls
> > > and private email.
> >
> > You are mixing two things here. Obviously fips should have
> > announced/discussed his changes before committing.
>
> No I am not.  It is more than before committing.  If it is just before
> committing then we end up with problems like Kai's MaxDB patch.
>
> The object factory change should have been discussed before being
> committed.  btw I would suggest that no one relies on the feature until
> it is resolved.
>
> If there is no discussion then something may not be appropriate and the
> time is wasted.

Foot dragging.

Oftentimes, more time is wasted in bottlenecks such as  
consensus-building and waiting for approval for others. To make the  
whole development progress faster, why not let anyone make the  
modifications they want to make to the code and if the mods make a  
drastic change to the way components interact, they should post the  
changes to the list first and let the group vote on whether to accept  
the changes or not.

It would also be great to adopt unit tests and test-driven development  
practices to reduce the likelihood the mods  break something else in  
the codebase. Then you don't need to review every single commit.

> > > It has been less than a week since I posted about the need
> > > for communication on this list.
> >
> > ... and Kai is the scapegoat now?
>
> No, but Kai's actions are good example of what not to do.  I am happy  
> to
> admit that Kai's post about the phpdocs was a good approach, not
> perfect, but a good improvement.  His approach to php -l was poor imho.

Posturing. You can't compliment someone without also criticizing him?  
Don't answer. (Delete. Delete. Delete.)

> > > Either work (and communicate) as part of the team, not your
> > > own little faction that thinks they can do what ever they want.
> >
> > It is not *MY* "fraction". People still have their own will, even if  
> > working
> > for a company.
> > AFAIK both fips and powerstat have prepared and submittet their  
> > changes in
> > their spare time, independent of the copmpany (correct me if I'm  
> > wrong). If
> > that should be important.
>
> I am happy to accept that the actions appear to be similar, but the
> employer was the same.

Posturing. How is that relevant? Don't answer.

> > And now: let's get back to work, shall we?
>
> I haven't read /. for 24hrs+ so no time lost ;)

Whee. No one cares.

> Cheers
>
> Dave
> --  
> Dave Hall (aka skwashd)
> API Coordinator
> phpGroupWare
> ----------------------------------------------------------------------- 
> --
> Do you think if Bill Gates got laid in high school, do you think  
> there'd
> be a Microsoft?  Of course not.
> Underwear Goes Inside The Pants by Lazy Boy

Alfonso Guerra (aka mrzippy)