Re: [ELECTION] PEAR future now, for 2 weeks

From: 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

« previous php.pear.dev (#45724) next »