However, I am more interested in legitimate users that download and try the code. This helps me test my code more intensively and iron any bugs or limitations much faster. I do not even wish or expect people to thank me. As long as they test the code and report any problems, or do not report anything because it is all right for them, that is fine for me.
I agree fully. Testing and giving back is a major reason for putting my software out there. This is why I use PEAR. There is a large group of both developers and users who actively work together to make the packages better. I also like the standardization and use of high level programming concepts, such as seperation of functionality and re-use of code.
As much as this thread was not about PEAR and PHP Classes, you seem to enjoy keep bringing that subject up. You sound like a snake oil salesman, always trying to push PEAR as the best place in the world to publish author classes, in typical attack to PHP Classes site as if it is a great threat to your existence.
The truth is that many authors will always refuse to publish their classes in PEAR for reasons that have nothing to with the PHP Classes site.
Many authors, including myself, have tried to contribute to PEAR but then there were a few individuals that were set to make it hard or even impossible to do it, usually for reasons of arguable logic. It seems that there is usually a small feud formed by a few individuals that are not interested to let other developers have a role that may put them in the shadow. With this protective attitude it is really very hard to even try to contribute.
For instance the admitance of only one coding style will always be an obstacle to motivate developers to contribute to PEAR. I even recall until today, when Andrei Zmievski said PEAR coding style was so ridiculous that made him cry. I guess that was the reason why Smarty was never contributed as a PEAR package. Curiously, I read some statistics that show that Smarty alone is a more popular PHP.net project than the whole PEAR project.
I even proposed to allow to preserve the coding style of the original contributor. The problem is that when people try to change coding styles, not only they waste a lot of time doing it right, but they may add bugs by accident where none existed. This proved to be true when Lukas Smith ported Metabase to PEAR style. Many bugs were added in code from Metabase that was working perfectly.
Forcing people to change styles is like making all right handed people start writing with the left hand to be accepted. PEAR was set to be what CPAN was to Perl but CPAN does not have such mandatory style requirements.
Until PEAR people become effectively more open minded, without any hipocrisy and protectionism, PEAR will always suffer from the absence of many very qualified PHP developers, making it a shadow of what PEAR hoped to be. The reality speaks for itself. PEAR rules are not consensual nor there seems to be great interest from PEAR people to change that. It is all in their hands to change.
The documentation is also very important. Nearly every bit of code in PEAR packages is documented. If no "Documentation" is on the site, you can still check the code itself to find instructions and even usage and examples.
We know that is not accurate. Many package lack of proper documentation. The truth is that writing proper documentation takes a lot of time to be viable. PEAR-Doc like documentation is as good a telegrams. Documentation is more than just a few vague words embeded in the source. It is better than nothing but unlike what you say, many PEAR packages do not come with sufficient documentation.
Obviously, the "knowledge s*ckers" will not provide any valuable feedback. Actually some of them even come in public just to b*tch that I require them to login to download my stuff. Some even threat to download similar packages from some other repository, as if I care. The world does not revolve around any individual alone, even less KS.
If that requirement of login detracts some KS from even accessing the site, that is just perfect for me. That is not the main reason to keep that requirement for my classes but it is one reason more.
I can justify spending time and effort to retribute the feedback that legitimate users provide. As for KS, sorry, they are not helping me at all, so I can't justify even to worry about the usual b*tching or threatning to use the TV of some other neighbour. ;-)
Instead of making harder for legitimate users to use your software, maybe you should think about why people are "knowledge sucking" instead of using your class.
When I say legitimate users, I am talking about those that do not have a problem to become subscribers of the site and download the package made available in the site by the authors.
In general I observed that some people show an hostile atitude towards the site because they do not want to trust that when they subscribe they will benefit from a whole set of services for free. Instead, some assume that their e-mail addresses will be sold to spammers and other conspiration theories that have no foundation in any facts.
Since I developed and manage this site, I can tell you that those objections are absurd. As you may imagine I cannot simpathize with people that on one side want my software but at the same time do not trust me.
Everybody is free to disagree with me but I do not consider potential legitimate users all those that do not consider my site trustworthy. I can certainly live well without those users. As I said, if all they wanted was to s*ck my knowlegde, and so would not provide any valuable feedback in any circunstances, I am sure I am not loosing nothing. I certainly do not develop free software for people with hostile atitudes.
On the other hand, the site is open to anybody. Any author has a chance and is free to contribute with any classes they may have. There is no feud raising opposition based on arguable requirements to the classes that may or not be published. This is democracy applied to software sharing. This is why about 700 authors have so far contributed with about 1250 classes.
Instead of boycotting the classes before they are published, the site adopts a natural selection method to outstand which are the most appreciated solutions for each topic. That works by letting users rate classes on important technical aspects.
The best rated classes will feature in the site top charts. The authors of the best rated classes may win prizes every month. The users that make the most accurate ratings may also win prizes every month. That is so you can see what the users that refuse to subscribe for whatever reasons are loosing.
Users that become subscribers benefit of useful services, unless they do not want them, like getting automatic notifications by e-mail about new classes or updates on classes that they previously downloaded. This not only makes it possible to provide a large immediate audience to the authors that publish in the PHP Classes site, but also keep the users quickly upto date about class updates that may include great new features or even important security fixes.
One final curious comment, while you try so hard to push PEAR and fight PHP Classes as if they are mutually exclusive, I think you do not know that several PEAR authors also come to the PHP Classes site and publish their classes their. I think they understand that exposure in two repositories is better than in just one.
--
Regards, Manuel Lemos
PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/
PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/
Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html
-- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
