Tuesday, November 17. 2009
How to put the FAIL in open source
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I disagree. Most PHP projects are not really a flat structure. Most of some sort of structure at least clear leaders. Now if you want to create a standard on file naming/autoloaders than at most 50% is technical, the rest is by its very definition a bike shed color discussion. Its very easy to have an opinion or worse yet repeat the same opinion in circles. As such having a reduced number of "representatives" makes absolute sense to me. Furthermore .. these are not just any people, these are people that have shown their continued dedication to the PHP community. Finally its not like there is no way to influence the discussion. Any of these people are easily approachable via IRC, email or any of the conferences most of these people are attending around the world. Also these people are active participants in the community, so they read planet php and pick up the vibes from the community.
To conclude, having an open list to discuss coding standards is a recipe for a perpetual discussion machine, but trust me .. no decision will ever be made .. on the flip side no mistake will ever be made either .. aside from wasting everyones time.
On the other hand this is a non randomly selected grouped picked based on their established leadership in the PHP community, who are not aiming to create an island and therefore are keen to get additional feedback outside of the list if only because finding a proper solution is in their best interest.
Disclaimer: I am on the list, though I am not sure if I belong on the list because I do not actually represent any project atm. As such I have decided to mostly just serve as an advisor on what is probably currently the accepted standard (aka the PEAR standard). Speaking of which .. the CS and naming conventions were done either way back (by Horde) among a very small group of people as well as later on in the also small PEAR group.
To conclude, having an open list to discuss coding standards is a recipe for a perpetual discussion machine, but trust me .. no decision will ever be made .. on the flip side no mistake will ever be made either .. aside from wasting everyones time.
On the other hand this is a non randomly selected grouped picked based on their established leadership in the PHP community, who are not aiming to create an island and therefore are keen to get additional feedback outside of the list if only because finding a proper solution is in their best interest.
Disclaimer: I am on the list, though I am not sure if I belong on the list because I do not actually represent any project atm. As such I have decided to mostly just serve as an advisor on what is probably currently the accepted standard (aka the PEAR standard). Speaking of which .. the CS and naming conventions were done either way back (by Horde) among a very small group of people as well as later on in the also small PEAR group.
Hi Lukas,
Actually, your point about PEAR/Horde standards being decided by a small group kind of proves my point.
There are several issues with the standards, not the least of which was the use of require_once. A big problem not thought of by the small group was top-level packages (think Date class, which forced PHP's Date class to be renamed to DateTime). These kinds of problems are far more likely to be caught if you include people you don't think should be included, and suffer the occasional communication problem in exchange for the vast benefits.
The CS wars you refer to almost exclusively centered around whether to use tabs vs. spaces, which is not in debate.
If those standards had been universally accepted, it would greatly simplify updating them for PHP 5.3 and namespaces. On the contrary, a standard decided by a small group of people just doesn't get traction unless it is forcibly a part of the language (i.e. PHP itself enforces the standard)
The fact is that some things do require a tremendous amount of debate to get the best possible solution when there is only a choice between several least-best solutions (think namespace separator) but unlike the standards group, I don't believe the *potential* for an endless debate justifies *pre-emptive* closing of the list. You close a list when it becomes unmanageable.
Instead, from the beginning, the story I heard was first "but these are the standards, we're just voting on them, not accepting feedback" and then "we're moving to a closed list, but are open to any suggestions" and when I made suggestions off-list to those who had on-list access, they were of course ignored because there was no archive of them, and the other elite never actually saw them.
The fallacy in your assumption is that what fixes arguments is the restricting of a list. What actually fixes arguments is deciding a clear decision-making hierarchy, and then opening up the RFC stage to as many ideas as possible. It's called "Request For Comments" for a reason...
Actually, your point about PEAR/Horde standards being decided by a small group kind of proves my point.
There are several issues with the standards, not the least of which was the use of require_once. A big problem not thought of by the small group was top-level packages (think Date class, which forced PHP's Date class to be renamed to DateTime). These kinds of problems are far more likely to be caught if you include people you don't think should be included, and suffer the occasional communication problem in exchange for the vast benefits.
The CS wars you refer to almost exclusively centered around whether to use tabs vs. spaces, which is not in debate.
If those standards had been universally accepted, it would greatly simplify updating them for PHP 5.3 and namespaces. On the contrary, a standard decided by a small group of people just doesn't get traction unless it is forcibly a part of the language (i.e. PHP itself enforces the standard)
The fact is that some things do require a tremendous amount of debate to get the best possible solution when there is only a choice between several least-best solutions (think namespace separator) but unlike the standards group, I don't believe the *potential* for an endless debate justifies *pre-emptive* closing of the list. You close a list when it becomes unmanageable.
Instead, from the beginning, the story I heard was first "but these are the standards, we're just voting on them, not accepting feedback" and then "we're moving to a closed list, but are open to any suggestions" and when I made suggestions off-list to those who had on-list access, they were of course ignored because there was no archive of them, and the other elite never actually saw them.
The fallacy in your assumption is that what fixes arguments is the restricting of a list. What actually fixes arguments is deciding a clear decision-making hierarchy, and then opening up the RFC stage to as many ideas as possible. It's called "Request For Comments" for a reason...
I think you have an idea how hard it is to find enough people with substantial involvement with PHP community.
That's the first attempt to have at least some standards around PHP and of course things may not be so democratic. That's pretty understandable.
What you forgot is exactly that if we make the list opened to everyone, everyone will think he/she has rights to vote. And that's not true. This moderated list is actually the "elected" people who lots of people follow, because any sort of way they are references in the community in general.
So if Fabien changes A to B in Symfony, lots of people will follow it because the project is following some path.
Who will care if 40 people vote on something and it gets lost because none adopts it?
That was the point and that was exactly why these people were selected. They represent a mass of people behind them. Of course anyone is able to read the discussions and propose changes. IRC is opened for anyone interested! Just join freenode at #php-standards
If you wanna join the standards group, make a group request and let's the committee vote if you should join or not. Election normally... 50% + 1.
If you think we're doing wrong, please give a better valid suggestion and not only some open to everyone thing that would lead the list turn into a complete mess in less than a few days.
PS: JFYI, I'm a member of the group, but not a voting member. =)
Cheers,
Guilherme Blanco
That's the first attempt to have at least some standards around PHP and of course things may not be so democratic. That's pretty understandable.
What you forgot is exactly that if we make the list opened to everyone, everyone will think he/she has rights to vote. And that's not true. This moderated list is actually the "elected" people who lots of people follow, because any sort of way they are references in the community in general.
So if Fabien changes A to B in Symfony, lots of people will follow it because the project is following some path.
Who will care if 40 people vote on something and it gets lost because none adopts it?
That was the point and that was exactly why these people were selected. They represent a mass of people behind them. Of course anyone is able to read the discussions and propose changes. IRC is opened for anyone interested! Just join freenode at #php-standards
If you wanna join the standards group, make a group request and let's the committee vote if you should join or not. Election normally... 50% + 1.
If you think we're doing wrong, please give a better valid suggestion and not only some open to everyone thing that would lead the list turn into a complete mess in less than a few days.
PS: JFYI, I'm a member of the group, but not a voting member. =)
Cheers,
Guilherme Blanco
What you forgot is that everyone SHOULD have a right to vote. You call this list php.standards, obviously implying that it's a standard for all PHP code and not a standard for your PHP frameworks to follow
The nature of a standard is that everyone should use it, if a large part of code does not use it then it's a useless standard.
So how can you expect people to write code to a standard they have no input on? You sit there on your high and mighty throne and decide who is good enough to have a vote and who isn't, yet you expect everyone to follow your standard. Do you really not see how arrogant that is?
If you ever do manage to come up with a standard I'll review it and if it happens to be how I like my code then I'll say "Well I could have told you guys that!" and if not then I'll be giving you the one finger salute; and I'd wager a lot of people will do the same. So congratulations on wasting a lot of time and making PHP the laughingstock of the programming world once again.
The nature of a standard is that everyone should use it, if a large part of code does not use it then it's a useless standard.
So how can you expect people to write code to a standard they have no input on? You sit there on your high and mighty throne and decide who is good enough to have a vote and who isn't, yet you expect everyone to follow your standard. Do you really not see how arrogant that is?
If you ever do manage to come up with a standard I'll review it and if it happens to be how I like my code then I'll say "Well I could have told you guys that!" and if not then I'll be giving you the one finger salute; and I'd wager a lot of people will do the same. So congratulations on wasting a lot of time and making PHP the laughingstock of the programming world once again.
So you dont think that representatives from a couple dozen very popular projects are able to figure out when they have a wording for a standard on namespace/class naming in their hands that makes sense technically? At least one that is reasonable enough so that if these popular projects adopt them that even I there are minor concerns on your part that it wouldnt make sense for you to adopt this standard in order to ensure interoperability?
Again, this is at least half a bikeshed discussion. This is the very nature of such naming standards. Having everybody pitch in will just let us discover that there are not just a million but actually a billion ways to say the same thing.
If you have technical concerns, the state of discussion is open, planet-php is open too, so your voice will be heard if you care.
Anyways I should add that I understand that you deep down feel weird about a "closed" list, I did too at the beginning. But after that I thought about how the previous standard were established and how awfully unproductive things got every time someone on pear-dev started talking about the PEAR CS. And this time the idea is to get even more projects involved from day one!
This is not a ruling class trying to order the little people around. This is a bunch of people that put in countless hours every week in their spare time to creating some of the most used PHP applications and frameworks around. And I think if you put a dozen or more of these people together and they come up with a compromise the chances are very very good that it will result in something useful for the general PHP community. And I think these people deserve the benefit of the doubt that they are not doing it because they are on a power trip but because they actual care .. which again means that if you have technical concerns let them be heard .. these people WILL care.
Other languages have established complex and lengthy processes for this which we do not have in PHP. Maybe we should also have a JCP or a PEP system. Feel free to try and create one (I am addressing the general readership of this blog here). But I think its quite likely that by the time that is setup and working that we better already worked out how to use namespaces before or PHP would surely suffer.
Again, this is at least half a bikeshed discussion. This is the very nature of such naming standards. Having everybody pitch in will just let us discover that there are not just a million but actually a billion ways to say the same thing.
If you have technical concerns, the state of discussion is open, planet-php is open too, so your voice will be heard if you care.
Anyways I should add that I understand that you deep down feel weird about a "closed" list, I did too at the beginning. But after that I thought about how the previous standard were established and how awfully unproductive things got every time someone on pear-dev started talking about the PEAR CS. And this time the idea is to get even more projects involved from day one!
This is not a ruling class trying to order the little people around. This is a bunch of people that put in countless hours every week in their spare time to creating some of the most used PHP applications and frameworks around. And I think if you put a dozen or more of these people together and they come up with a compromise the chances are very very good that it will result in something useful for the general PHP community. And I think these people deserve the benefit of the doubt that they are not doing it because they are on a power trip but because they actual care .. which again means that if you have technical concerns let them be heard .. these people WILL care.
Other languages have established complex and lengthy processes for this which we do not have in PHP. Maybe we should also have a JCP or a PEP system. Feel free to try and create one (I am addressing the general readership of this blog here). But I think its quite likely that by the time that is setup and working that we better already worked out how to use namespaces before or PHP would surely suffer.
just curious.. why not try to follow the process of the IETF and make an RFC, we don't have to go slow like the W3C though...
Martin, as much as I do agree with some of the nay-sayers (the linked post by Rasmus summed it up best imho), just look at about every RFC around. I've not heard of much bickering who gets to decide about it. Some people gathered (or even single persons) and put up the RFC, then it became a standard.
I think while what Guilherme said is true, I'd bet it won't have the same impact. Especially by *not* being on the list stuff by people outside of this is being ignored. Just compare it to php-internals. Stuff by "people without certain karma" is being ignored often. Stuff NOT on the list by "people without karma" is ignored 95% of the time.
You can bet if someone approaches one member of the group, that not all will hear about this suggestion/feedback anytime soon or at all.
All in all I think the "everyone can post, but not everyone can vote" is the most appropriate model. But then I couldn't care less about the decisions being made there. If I like them, I will adopt them. If I don't, I'll try to avoid em, no harm done.
I think while what Guilherme said is true, I'd bet it won't have the same impact. Especially by *not* being on the list stuff by people outside of this is being ignored. Just compare it to php-internals. Stuff by "people without certain karma" is being ignored often. Stuff NOT on the list by "people without karma" is ignored 95% of the time.
You can bet if someone approaches one member of the group, that not all will hear about this suggestion/feedback anytime soon or at all.
All in all I think the "everyone can post, but not everyone can vote" is the most appropriate model. But then I couldn't care less about the decisions being made there. If I like them, I will adopt them. If I don't, I'll try to avoid em, no harm done.
Florian, one point I disagree with is "If I like them, I will adopt them. If I don't, I'll try to avoid em, no harm done."
A standard that is only partially adopted does do real harm to PHP. The PEAR coding standard is a great example. Very few projects adhere to them, and the "cowboy coder" mentality in PHP comes in no small part from the fact that the semi-official standard at pear.php.net is ignored by a large number of popular projects, including several who are now involved in the standards talks for namespaces (which is a great thing, I love the intentions, but the devil is in the details of how the standard is created and then vetted).
A standard that is only partially adopted does do real harm to PHP. The PEAR coding standard is a great example. Very few projects adhere to them, and the "cowboy coder" mentality in PHP comes in no small part from the fact that the semi-official standard at pear.php.net is ignored by a large number of popular projects, including several who are now involved in the standards talks for namespaces (which is a great thing, I love the intentions, but the devil is in the details of how the standard is created and then vetted).
Pardon me, but who are you to 'demand' anything?
I'll agree that the naming of the group was unfortunate and caused a bit of confusion, but we convened as independent developers representing our respective projects.
We came together of our own volition for the benefit of our users (and others in the PHP community, should they decide that they like what they see and want to use it as well) to solve a common problem.
For you to come in and attempt to impose your own idea of 'openness', you demonstrate the same arrogance of which you accuse us.
Let's not kid ourselves.
I'll agree that the naming of the group was unfortunate and caused a bit of confusion, but we convened as independent developers representing our respective projects.
We came together of our own volition for the benefit of our users (and others in the PHP community, should they decide that they like what they see and want to use it as well) to solve a common problem.
For you to come in and attempt to impose your own idea of 'openness', you demonstrate the same arrogance of which you accuse us.
Let's not kid ourselves.
Who am I? I am a nobody. That's the whole point of my post. Nobodys have plenty to offer to an open source project, ideas or code (both are integral parts of designing PHP source, as I'm sure you would agree).
I find it laughable that you think I am imposing anything on anyone when it is you who is imposing moderation and a closed list on the rest of the world. All I am doing is asking other like-minded people to help jolt some sense into the standards group. You may note that I spent months attempting to do this both on standards@lists.php.net and also off-list.
As I said early on, if this is not a PHP-project wide standards initiative, then you are misleading at best and dishonest at worst to call it "PHP Standards." This was raised within the first week when it was apparent that you sought to limit input rather than respond to it.
Perhaps I am arrogant, perhaps not. I have absolutely no problem with that label in this case because it is irrelevant to the issue. The problem here is not that you or I are arrogant, but that you are alienating a large segment of the people who will be expected to follow a standard.
Let's not kid ourselves: the point of a standard is for people to follow it. If that isn't your goal, then you aren't drafting a standard.
Let me put this another way: if the people who so kindly got together from their own volition to tell us how we should write our code had the humility to imagine that their original proposal could be flawed, that would help. Then, having the vision to imagine that others might have better solutions for the problem and open up the process to avoid losing that great idea outside the mainstream, well then we'd be getting somewhere.
I find it laughable that you think I am imposing anything on anyone when it is you who is imposing moderation and a closed list on the rest of the world. All I am doing is asking other like-minded people to help jolt some sense into the standards group. You may note that I spent months attempting to do this both on standards@lists.php.net and also off-list.
As I said early on, if this is not a PHP-project wide standards initiative, then you are misleading at best and dishonest at worst to call it "PHP Standards." This was raised within the first week when it was apparent that you sought to limit input rather than respond to it.
Perhaps I am arrogant, perhaps not. I have absolutely no problem with that label in this case because it is irrelevant to the issue. The problem here is not that you or I are arrogant, but that you are alienating a large segment of the people who will be expected to follow a standard.
Let's not kid ourselves: the point of a standard is for people to follow it. If that isn't your goal, then you aren't drafting a standard.
Let me put this another way: if the people who so kindly got together from their own volition to tell us how we should write our code had the humility to imagine that their original proposal could be flawed, that would help. Then, having the vision to imagine that others might have better solutions for the problem and open up the process to avoid losing that great idea outside the mainstream, well then we'd be getting somewhere.
I thought the whole reason this standards group was even formed was to make it easier for the community to use frameworks. Whether someone wants to use two or more frameworks in conjunction or switch from one framework to another, having the same standard obviously makes this easier. So if this is being done for the community, then why is the community being left out?
Greg, I think you are over reacting a bit.
I am not on the list, nor do I have a vote, but I fully support the effort that this group is trying to accomplish. This is not an attempt to enforce standards on the community, but an effort to help increase interoperability between the projects involved.
It is very common for projects/teams to accept different coding standards based on what best supports the need of the project - look at PEAR and Zend Framework - their coding standards are similar, but not exactly the same. You are free to adopt any coding standard you choose for your projects, these developers are choosing to draft something that will help the community integrate multiple tools in a easier/more standard manner.
If you are an active member/user of any of the involved projects, you can certainly contact the lead developers to make requests or offer suggestions.
I am not on the list, nor do I have a vote, but I fully support the effort that this group is trying to accomplish. This is not an attempt to enforce standards on the community, but an effort to help increase interoperability between the projects involved.
It is very common for projects/teams to accept different coding standards based on what best supports the need of the project - look at PEAR and Zend Framework - their coding standards are similar, but not exactly the same. You are free to adopt any coding standard you choose for your projects, these developers are choosing to draft something that will help the community integrate multiple tools in a easier/more standard manner.
If you are an active member/user of any of the involved projects, you can certainly contact the lead developers to make requests or offer suggestions.
James,
I also support what is being done (which should be very clear from the first paragraph of the blog post), but you are naive to think that the standards won't be enforced. I write code for pear.php.net and pear2.php.net. Whatever is decided will be enforced there. If you write code for ZF, Cake, Doctrine, or any other project, it will be enforced on your code.
The flaw in your reasoning is that I *have* been in contact with the representatives from PEAR, and the real issue is that PEAR's representatives are not representing the actual wishes of the PEAR community, simply because they don't know what they are. The debate is an external thing, and most developers simply don't know what it is.
Want proof? Travis Swicegood, who started the standards process as a representative of PEAR on the PEAR group supposedly with a standard originating in PEAR, was actually voted out of the PEAR group after PEAR's developers got a look at what was actually being proposed and how far it was from the existing PEAR standard (and in fact the existing official PEAR2 standard). See http://pear.php.net/election/info.php?election=12&results=1
I fully support the effort to create a PHP standard, and was very active on the php.standards list, but a standard must have community input even if a small group votes on it, especially in a project with a community as strong as PHP at large.
I also support what is being done (which should be very clear from the first paragraph of the blog post), but you are naive to think that the standards won't be enforced. I write code for pear.php.net and pear2.php.net. Whatever is decided will be enforced there. If you write code for ZF, Cake, Doctrine, or any other project, it will be enforced on your code.
The flaw in your reasoning is that I *have* been in contact with the representatives from PEAR, and the real issue is that PEAR's representatives are not representing the actual wishes of the PEAR community, simply because they don't know what they are. The debate is an external thing, and most developers simply don't know what it is.
Want proof? Travis Swicegood, who started the standards process as a representative of PEAR on the PEAR group supposedly with a standard originating in PEAR, was actually voted out of the PEAR group after PEAR's developers got a look at what was actually being proposed and how far it was from the existing PEAR standard (and in fact the existing official PEAR2 standard). See http://pear.php.net/election/info.php?election=12&results=1
I fully support the effort to create a PHP standard, and was very active on the php.standards list, but a standard must have community input even if a small group votes on it, especially in a project with a community as strong as PHP at large.
I deslike elitism. It hurts people feelings needlessly. It only makes people boycott the elites every time they can behind the scenes, start competing projects, in sum avoiding cooperation.
PHP does not need more elitist efforts. I agree with Lukas, elitist efforts will die of natural causes soon or later.
I thought this php.standards effort was for creating high level specifications, for instance for a message queueing API, just like JCP (Java Community Process).
From the specification, different teams could implement compatible implementations, just like you have different but (more or less) compatible implementations of Java application servers from different vendors: Sun, JBoss, IBM, Oracle, etc...
The actual code standards that are used by each implementation do not matter as long as the API is compatible with the standard specification.
In the end the users win because they have different offers to implement compatible API. They can pick the best implementation but still have the freedom to switch to another at later point if they want.
That is what I wrote here:
http://www.phpclasses.org/blog/post/96-PHP-standards-discussion-group-opens-to-the-world.html
http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
Unfortunately I was wrong. It seems that this php.standards effort is not going that direction.
If anybody is willing to start a JCP-like initiative for PHP, count me in. Just let me know if you like to move ahead.
mlemos at acm.org
PHP does not need more elitist efforts. I agree with Lukas, elitist efforts will die of natural causes soon or later.
I thought this php.standards effort was for creating high level specifications, for instance for a message queueing API, just like JCP (Java Community Process).
From the specification, different teams could implement compatible implementations, just like you have different but (more or less) compatible implementations of Java application servers from different vendors: Sun, JBoss, IBM, Oracle, etc...
The actual code standards that are used by each implementation do not matter as long as the API is compatible with the standard specification.
In the end the users win because they have different offers to implement compatible API. They can pick the best implementation but still have the freedom to switch to another at later point if they want.
That is what I wrote here:
http://www.phpclasses.org/blog/post/96-PHP-standards-discussion-group-opens-to-the-world.html
http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
Unfortunately I was wrong. It seems that this php.standards effort is not going that direction.
If anybody is willing to start a JCP-like initiative for PHP, count me in. Just let me know if you like to move ahead.
mlemos at acm.org
Manuel, it *could* move in that direction but it is in a much earlier state. Really all that has been discussed so far is a fundamental agreement on how to handle class loading in a uniform manner.
Without such fundamental technical things theres not much of a point in starting to create specifications.
As such I can't understand all the uproar around this at all. What is being discussed is a very simple agreement between many projects on how to structure class files for uniform class loading. Thats far from being a coding standard. Noone cares about tabs vs spaces, lower vs uppercase, opening curly brace on the same line or next line or what not.
I dont care about the open vs closed debate personally. It's just obvious that given the "anti-standard" or "I do it my way" or "Cowboy" mentality, as Greg put it, that is so prevalent in the php world it is very unlikely that anything productive would come out of a discussion where everyone can have their say (and vote). Elitism or not, democracy (as in "everyone gets a vote and is heard no matter who they are") doesnt work well in software development. You need to have a) a common/unified vision and b) some people who have the last word on things. With too many people you have too many different visions and even if you get a concensus out of it, it wont be any good any more because the vision is lost. Its just a huge compromise, a patch work.
And the development of PHP itself is not different. Being subscribed to the internals list for at least some years now, however democratic and "open" it is supposed to be, at the end there is "elitism" and a certain set of people have the final word. And if you ask me there is not enough elitism in the development of php which results in there being no clear vision of where the language is supposed to be heading. It is more of a patchwork, too.
It's much more important that a project has a clear vision and goals than that everyone likes it and has a vote. Consistency matters.
The JCP doesnt work that way either. Anyone can propose a standard but only the formed "expert group" (elitism?) really decides where things are going in the end.
And no, I'm not (any more) on the (closed) list.
Without such fundamental technical things theres not much of a point in starting to create specifications.
As such I can't understand all the uproar around this at all. What is being discussed is a very simple agreement between many projects on how to structure class files for uniform class loading. Thats far from being a coding standard. Noone cares about tabs vs spaces, lower vs uppercase, opening curly brace on the same line or next line or what not.
I dont care about the open vs closed debate personally. It's just obvious that given the "anti-standard" or "I do it my way" or "Cowboy" mentality, as Greg put it, that is so prevalent in the php world it is very unlikely that anything productive would come out of a discussion where everyone can have their say (and vote). Elitism or not, democracy (as in "everyone gets a vote and is heard no matter who they are") doesnt work well in software development. You need to have a) a common/unified vision and b) some people who have the last word on things. With too many people you have too many different visions and even if you get a concensus out of it, it wont be any good any more because the vision is lost. Its just a huge compromise, a patch work.
And the development of PHP itself is not different. Being subscribed to the internals list for at least some years now, however democratic and "open" it is supposed to be, at the end there is "elitism" and a certain set of people have the final word. And if you ask me there is not enough elitism in the development of php which results in there being no clear vision of where the language is supposed to be heading. It is more of a patchwork, too.
It's much more important that a project has a clear vision and goals than that everyone likes it and has a vote. Consistency matters.
The JCP doesnt work that way either. Anyone can propose a standard but only the formed "expert group" (elitism?) really decides where things are going in the end.
And no, I'm not (any more) on the (closed) list.
Hi Roman,
You yourself gave 2 examples of the kind of process that actually works, even if you disagree on the degree of effectiveness:
Everyone can comment, a few people can vote.
The php standards group has decided pre-emptively that only people who can vote can comment or suggest anything, and have expressed annoyance at people who try to comment who aren't voters.
If you re-read my post, you'll see I am simply asking for all input to be heard in an official way, not that everyone have a chance to vote. This is a VERY important distinction. All successful open source projects have a few "elite" who make the final decisions, but at the same time, all successful open source projects allow anyone, no matter how experienced (or smart, for that matter) to comment. Good leaders are willing to tolerate a little noise to find the gems that no one else would have thought of. Fearful leaders censor and quench any possible dissent before there is a problem to be solved.
As an example of the problems inherent in this model, I have pointed out several potential problems in the standard in an off-list exchange which have never been even responded to. On the other hand, everything I posted publicly has been addressed, and at the very least debated. Without openness in the input process (voting matter much less), you lose actual value, not just some vague principles (otherwise it wouldn't really matter at all).
You yourself gave 2 examples of the kind of process that actually works, even if you disagree on the degree of effectiveness:
Everyone can comment, a few people can vote.
The php standards group has decided pre-emptively that only people who can vote can comment or suggest anything, and have expressed annoyance at people who try to comment who aren't voters.
If you re-read my post, you'll see I am simply asking for all input to be heard in an official way, not that everyone have a chance to vote. This is a VERY important distinction. All successful open source projects have a few "elite" who make the final decisions, but at the same time, all successful open source projects allow anyone, no matter how experienced (or smart, for that matter) to comment. Good leaders are willing to tolerate a little noise to find the gems that no one else would have thought of. Fearful leaders censor and quench any possible dissent before there is a problem to be solved.
As an example of the problems inherent in this model, I have pointed out several potential problems in the standard in an off-list exchange which have never been even responded to. On the other hand, everything I posted publicly has been addressed, and at the very least debated. Without openness in the input process (voting matter much less), you lose actual value, not just some vague principles (otherwise it wouldn't really matter at all).
Roman, it does not seem you know very well how JCP works. If you read the participation overview you can clearly read that:
1. propose new or revised Java API specification projects by filing a JSR,
2. nominate themselves to serve on the Expert Groups that create or revise Java specifications (when the JSR is initiated, or during JSR Review),
3. review and comment on all specifications developed using the JCP before Public review (Community Review).
http://www.jcp.org/en/participation/overview
It seems to me that this self-called PHP standards group is afraid to be overruled by a majority of interested PHP developers that they want to prevent them from joining.
In my dictionary that is called a cartel and so cannot be compared with JCP.
http://en.wikipedia.org/wiki/Cartel
I am afraid that this cartel will end alone because they excluded themselves from being fair and democratic. I don't think that is a good thing for anybody.
1. propose new or revised Java API specification projects by filing a JSR,
2. nominate themselves to serve on the Expert Groups that create or revise Java specifications (when the JSR is initiated, or during JSR Review),
3. review and comment on all specifications developed using the JCP before Public review (Community Review).
http://www.jcp.org/en/participation/overview
It seems to me that this self-called PHP standards group is afraid to be overruled by a majority of interested PHP developers that they want to prevent them from joining.
In my dictionary that is called a cartel and so cannot be compared with JCP.
http://en.wikipedia.org/wiki/Cartel
I am afraid that this cartel will end alone because they excluded themselves from being fair and democratic. I don't think that is a good thing for anybody.
Manuel,
I'm not sure I understand what you're trying to tell me. Have you ever participated in the JCP? If so, let me know how it turned out, whether your voice was heard. I'm a Java developer (among other things) but have never participated in the JCP but from what I've heard and read from others, its not as democratic as you think. You dont just get into an expert group easily, and for good reason.
Also, despite of what I wrote, you still did not seem to understand what this "php standards group" is currently doing and you apparently dont even know that the name "php standards group" is a legacy. Its about php project interoperability and, again, all that is discussed so far is class loader interoperability between some projects. Its extremely irritating how you can apparently get so upset about something that trivial. Cartel? Please... come down.
If you want to see a process similar to the JCP in PHP then go start it and dont wait for others to do it. I dont care that much as php is not really my living.
I'm not sure I understand what you're trying to tell me. Have you ever participated in the JCP? If so, let me know how it turned out, whether your voice was heard. I'm a Java developer (among other things) but have never participated in the JCP but from what I've heard and read from others, its not as democratic as you think. You dont just get into an expert group easily, and for good reason.
Also, despite of what I wrote, you still did not seem to understand what this "php standards group" is currently doing and you apparently dont even know that the name "php standards group" is a legacy. Its about php project interoperability and, again, all that is discussed so far is class loader interoperability between some projects. Its extremely irritating how you can apparently get so upset about something that trivial. Cartel? Please... come down.
If you want to see a process similar to the JCP in PHP then go start it and dont wait for others to do it. I dont care that much as php is not really my living.
Roman, if you do not care about PHP, what are you doing here? Making fun of all of us that care about PHP?
As for JCP, as you may read in the overview page, everybody can nominate themselves to serve on the Expert Groups, propose, review, and comment JSR, as long as you are a member. You can apply to be member as an individual.
The point is that everybody has an equal chance to participate.
Whether it works exactly like this in practice in JCP, I do not care because I do not want to participate in JCP, as I do not work with Java.
What matters is that the model of equal opportunity and transparence is the way to go for PHP.
When the criteria to participate in a standards group is not clear, discussions take place in private lists, people are accepted and rejected without transparence that prevent us to verify whether everybody had equal opportunity, all this leads to resent and complaints from renown members of the PHP community Greg, that wrote the post that starts this discussion.
This is not a good thing. It is just a sign that things are ill fated from the beginning.
The solution is to start over, make everything open and transparent, give everybody a chance to nominate themselves to participate without the usual silly excuses that elitists make to keep people out of their way.
This is just my opinion. Anyway, I am not interested in participating in this so called PHP standards group, but others want to but have been excluded.
As for JCP, as you may read in the overview page, everybody can nominate themselves to serve on the Expert Groups, propose, review, and comment JSR, as long as you are a member. You can apply to be member as an individual.
The point is that everybody has an equal chance to participate.
Whether it works exactly like this in practice in JCP, I do not care because I do not want to participate in JCP, as I do not work with Java.
What matters is that the model of equal opportunity and transparence is the way to go for PHP.
When the criteria to participate in a standards group is not clear, discussions take place in private lists, people are accepted and rejected without transparence that prevent us to verify whether everybody had equal opportunity, all this leads to resent and complaints from renown members of the PHP community Greg, that wrote the post that starts this discussion.
This is not a good thing. It is just a sign that things are ill fated from the beginning.
The solution is to start over, make everything open and transparent, give everybody a chance to nominate themselves to participate without the usual silly excuses that elitists make to keep people out of their way.
This is just my opinion. Anyway, I am not interested in participating in this so called PHP standards group, but others want to but have been excluded.
Manuel,
I am one of those strange guys who do not need to drop one language in order to use another. As such I always use several languages in parallel. I did not say "I don't care about PHP", I said that "I dont care that much". That means I dont care enough in order to spend a lot of time in forming and pushing some standards group and specifications. I only use PHP for pet projects. You should really read more carefully (or slowly).
As such I'm surely not making fun of anybody. If I understand you right, you would like to see something similar to the JCP in PHP but apparently you dont want to do or start it yourself. OK, so you just want to jump on board when someone else is doing it.
At the same time you are upset about a group that you still call "php standards group" even though I told you its a "php project interoperability group". Its not even trying to be like the JCP and it certainly dont forces standards on anybody. Just some people from different projects who agree on some conventions between their projects.
I say, stop looking at this group you're so upset about and instead start a JCP-like initiative yourself with all the things you would like to see. If people like it they will surely jump on board.
I will let this discussion end here in order not to abuse Greg's blog as a discussion forum / mailing list
I am one of those strange guys who do not need to drop one language in order to use another. As such I always use several languages in parallel. I did not say "I don't care about PHP", I said that "I dont care that much". That means I dont care enough in order to spend a lot of time in forming and pushing some standards group and specifications. I only use PHP for pet projects. You should really read more carefully (or slowly).
As such I'm surely not making fun of anybody. If I understand you right, you would like to see something similar to the JCP in PHP but apparently you dont want to do or start it yourself. OK, so you just want to jump on board when someone else is doing it.
At the same time you are upset about a group that you still call "php standards group" even though I told you its a "php project interoperability group". Its not even trying to be like the JCP and it certainly dont forces standards on anybody. Just some people from different projects who agree on some conventions between their projects.
I say, stop looking at this group you're so upset about and instead start a JCP-like initiative yourself with all the things you would like to see. If people like it they will surely jump on board.
I will let this discussion end here in order not to abuse Greg's blog as a discussion forum / mailing list
Roman, don't be silly, nobody alone can start a JCP like effort if there is not enough people that join in so it gains traction. What you are suggestion is such a non-sense like "getting married with myself and form a family with nobody else".
I am not calling the framework people group "php standards group". It was them that gave that name. While you say that it is just a php project interoperability, it seems that when they call themselves "php standards group" they have their greater ambitions to set their definitions as the "de facto" php standards.
I did not come here to jump on anybody else initiative. I just came here to express that I agree with the concerns of Greg, and that the way to go for a standardization initiative have success is to follow the good example of JCP.
It is not a new idea that I am having. I already written about it more than 3 years ago:
http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
I think it would be useful for PHP to have a JCP process but as I explained above, it cannot be done with just myself, nor just gathering an elite that does not allow the process to be transparent and democratic.
I am not calling the framework people group "php standards group". It was them that gave that name. While you say that it is just a php project interoperability, it seems that when they call themselves "php standards group" they have their greater ambitions to set their definitions as the "de facto" php standards.
I did not come here to jump on anybody else initiative. I just came here to express that I agree with the concerns of Greg, and that the way to go for a standardization initiative have success is to follow the good example of JCP.
It is not a new idea that I am having. I already written about it more than 3 years ago:
http://www.phpclasses.org/blog/post/52-Recommended-PHP-frameworks.html
I think it would be useful for PHP to have a JCP process but as I explained above, it cannot be done with just myself, nor just gathering an elite that does not allow the process to be transparent and democratic.
Manuel,
At this point, pretty much everyone is ready move away from the original name, since people have interpreted it to mean much more than we had originally intended. See here:
http://groups.google.com/group/php-standards/browse_thread/thread/166de4c66846d4a8
and here:
http://groups.google.com/group/php-standards/browse_thread/thread/9c02083319dc12b3
Our group is only interested in coming together on a few common ideas that each of our projects can implement to ease the burden of interoperating with each other. If any other projects would like to join and benefit as well, so much the better.
None of us is interested in the backlash that would ensue if anyone tried to suggest any *actual* standards for PHP (i.e. JCP-style standards).
Taken as a whole (and I mean everybody, including the crazy-bug-report-submitters), the PHP community is far too anarchistic for promoters of such ideas to escape with their lives, let alone have any chance of success.
At this point, pretty much everyone is ready move away from the original name, since people have interpreted it to mean much more than we had originally intended. See here:
http://groups.google.com/group/php-standards/browse_thread/thread/166de4c66846d4a8
and here:
http://groups.google.com/group/php-standards/browse_thread/thread/9c02083319dc12b3
Our group is only interested in coming together on a few common ideas that each of our projects can implement to ease the burden of interoperating with each other. If any other projects would like to join and benefit as well, so much the better.
None of us is interested in the backlash that would ensue if anyone tried to suggest any *actual* standards for PHP (i.e. JCP-style standards).
Taken as a whole (and I mean everybody, including the crazy-bug-report-submitters), the PHP community is far too anarchistic for promoters of such ideas to escape with their lives, let alone have any chance of success.
Calendar
|
March '10 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
Categories
Popular Entries
Setting up your own PEAR channel with Chiara_PEAR_Server - the official way
(36)
Do you develop a website? It is infinitely better to synchronize live and development sites using the PEAR Installer(25)
How to put the FAIL in open source(22)
doing the PEAR thing(19)
Using PEAR 1.4.0 to install PEAR packages on a remote host(19)
phpDocumentor and __get/__set/__call - give us your ideas (RFC)(17)
PEAR now fits in a bottle: meet go-pear.phar(17)
Mac OS X ships with security hole-laden PEAR - how to upgrade immediately(16)
Introducing pecl extension phar(13)
go-pear.phar works! In related news, PHP_Archive is now PHP 5.1.0+(12)