Re: [ELECTION] PEAR future now, for 2 weeks
| From: | Gregory Beaver | Date: | Fri, 23 Feb 2007 01:19:28 +0000 |
| Subject: | Re: [ELECTION] PEAR future now, for 2 weeks | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-45724@lists.php.net to get a copy of this message | ||
Hi Alan,
I don't intend to be derogatory, only to present the issues I have seen
with PEAR governance as fairly as I am capable. Of course, the members
of the PEAR Group are great people, and great coders. I happen to
believe that the structure of the group, like all real-world
appointed-for-life-no-matter-what governing structures, is doomed to the
failure of absenteeism and lack of direction.
None of this would matter if PEAR wasn't a major representative of what
PHP has to offer. When PEAR loses direction, it reflects badly on PHP
as a whole.
I know I can be a bit grating with my words, but I hope that no one will
take any criticisms I have as anything but an attempt to goad into
action towards a much better alternative :).
Alan Knowles wrote:
> This one's a bit inflamatory,
> PEAR Group makes all legislative decisions in private (secret ballot)
>
> The reality is that as things have evolved, the PEAR Group primarily
> is there to alter CVS karma, I dont think there has been any
> "legislative decisions" for years, especially now that there is a RFC
> system - which was the point of that one.. - so that everybody decides
> on things.
>
> The reason that the Group is set up that way I presume is more that
> the php-group who run the CVS servers are naturally concerned about
> who has access to that file. So the group who can modify it is
> limited. Note that the PEAR group only got access to this many years
> after PEAR started.... - so I'm not sure what will happen if there's a
> PEAR group with members that php-group dont know...
This is a major issue, I agree. In my proposal, I suggested that the
PEAR Group would control this, but I also expect that one of the first
tasks of the president would be to work out the details with the PHP
group on how to implement this.
>
> I'm not sure secret ballot's are a great benefit to PEAR - (living in
> a country that doesnt have real democracy, it sounds alot like one of
> the tricks that are used here to keep real democracy down) - why not
> an RFC - that was their purpose. - including collating the comments.
Secret ballot has worked quite effectively in the U.S. to avoid voter
intimidation. I've noticed on PEPr that in most cases, people simply
vote the same direction as the first few votes cast. As a member of a
faculty at a university, where voting always occurs publicly, I have
voted with the crowd (especially on things I don't really care all that
much about) but I would have voted differently if the vote was secret.
I find secret ballot quite liberating when voting for a democratic
president in a strongly republican state, for instance :).
A quick note about this - each vote *is* stored individually, and the
list of who voted is also stored. The ballot is not 100%
unreconstructable, as apache access logs and the mysql data could be
used to reconstruct who voted for what, but it would be an arduous,
unrewarding process. In addition, voter fraud is virtually impossible
unless Martin or I were to directly modify the results. If there is
enough concern about this issue, then I would be happy to ask some third
party to host the elections interface where no interested party would
have access to the database directly.
Honestly, even though I can't prove it, I have no interest in falsifying
the results of this election. I really do want to know what the PEAR
community at large thinks about this issue, and will respect the
decision absolutely.
> To be honest, though, there is a sense that while PEAR continues to
> grow, and new packages are added it is being overshadowed a little by
> Zend's private developer club. And you are probably driving more of
> the real activity in PEAR than anyone else..
I recently read about someone who proposed a port of HTTP_Request to PHP
5 for the Zend Framework, and he was told that the Zend Framework "only
accepts brand new code." Their purpose is very clearly defined as being
the buzzword of the day, and not really of interoperating with existing
software solutions out of a fear that some company will get sued if the
code isn't absolutely new. In other words, it's the king of "Not
invented here" philosophy, and has gone so far as to institutionalize it
and require all developers to sign an actual document certifying that
they are NIH-ites. PEAR is not a buzzword right now (try googling "PEAR
sucks" to see the most common buzzword associated with PEAR), but Zend
doesn't have a monopoly on good ideas, just a monopoly on marketing budget.
I am actively trying to push PEAR out of a rut, but the real activity is
shown in pear-cvs. All open source projects have a few driving forces
and lots of semi-active developers, that's nothing new in my book.
> While the wording in the Proposal is rather grand and a little
> derogatory, I think you may have something with the idea of an elected
> president/core team, - To me, it looks more like you could have
> structured your proposal more like the "Commons & the lords" (Pear
> Group+President / Pear-security) Commons is the elected one that does
> all the work/has the power, the Lords(sec team) just sit over and make
> sure the Commons's dont f**k up big time.... ;)
in the U.S. we use the Senate to do what the house of Lords does, but I
think simply having presidential veto power would be enough for PEAR to
keep the crazies in check. We, after all, don't have 300 million
citizens to deal with :).
>
> Eg. phasing out the pear-group into security based role (eg. the
> karma) - and perhaps absolute veto - that could be used at their
> peril, as that could justify their removal altogether...
>
> As the proposal stands at present, To me, while I agree with the
> general direction, I feel it's not been worked through fully, so
> unfortunately I'll abstain for the time being.
I asked for alternative structures back in December and early January,
would have been nice to hear about your idea then. I strongly respect
the decision to abstain - however please do vote and click "abstain" -
this is very important to get an accurate tally of disapproval of the
governments proposed, as we would simply have to come up with something
better rather than go with the least worst choice.
As an example of a "legislative decision" that was made in secret, let's
look at the decision to remove PHPUnit. Not only was this voted on in
secret, there was never any announcement anywhere of the decision. We
found out indirectly by it simply not being there any more. Perhaps
more troubling is the fact that most of the PEAR Group members have not
written more than 10 email messages to pear-dev over the past 3-4
years. This is not the fault of the people in the PEAR Group, it is the
fault of the government structure. Perhaps because I am an American, it
reminds me too much of the way England used to govern the colonies from
afar :).
Part of the problem with the PEAR Group is that there have *not* been
any legislative decisions recently. How many RFCs have been passed and
implemented recently?
On the other hand, look at the equivalent PHP group of core developers,
who are hashing out RFCs on how to implement unicode, error handling,
namespaces, array access and all kinds of things. PEAR, on the other
hand, has been just doing the same old thing while one of the PEAR group
members actually *removed* PEAR from PHP 6 and announced this as if it
was a group decision that PEAR is no longer relevant to PHP.
Here in PEAR, we argue endlessly about how to handle errors without
actually making any decisions. Someone has to put a foot down and risk
alienating a few developers, or nothing will ever happen.
PEAR's coding standards are a great example of positive "putting the
foot down." When I joined PEAR, I was a "tabs only" guy with a disdain
for one-true-brace, but because it was required, I (after grumbling),
got used to it, and now see that it is in fact no different from what I
was doing before. The reasoning for the decision was misrepresented as
"cross-OS compatibility" when the same issue does not plague other
projects, but arbitrary though it may be, the consistency is the most
important thing about the decision. In other words: there *was* a
decision made and everyone is happy now that we're used to it.
In any case, I hope that other developers will vote either for a
specific government or will abstain as Alan has.
Thanks,
Greg