[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpgroupware-developers] Communication ... again (was PHPDoc s for
From: |
Alfonso Guerra |
Subject: |
Re: [Phpgroupware-developers] Communication ... again (was PHPDoc s for head) |
Date: |
Wed, 27 Apr 2005 23:19:44 -0400 |
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)