Conflict PHP - Does this make good business sense?
(Page 3 of 5 )
Is there anything wrong with Zend guiding PHP in order for their venture capital-backed company to profit as opposed to creating a product that is tailored toward their community of users and supporters? It’s not illegal to exploit volunteers. It may not even be unethical or even immoral, but is it even good business for the owners of Zend to move away from the simplicity PHP users are fond of?
Zend has maneuvered PHP so that other companies who are in the enterprise software business consider it a legitimate language: Sun, Borland, Macromedia, etc. This is great for Zend so they can sell their accelerators and encryption packages, but again, this is moving PHP away from its user-base and toward Frankensteining PHP into whatever it needs to be that year in order for Zend to turn a profit. This may work for a few years, but in the long run, a successful software company needs its own identity.
PHP is a hypertext preprocessor. A hypertext preprocessor doesn’t require an object model as complex as Java, especially when hardly any members of the community use Java and the vast majority use the product because it’s simple. Instead of focusing on integrating with Java and rewriting the object-model, other actions could have been taken that would have strengthened PHP’s character instead of turning it into somewhat of a "wannabe."
First, the object model effort could have stopped for now at passing objects by reference. That would have been a fine improvement in the object model realm. If a complete re-haul of the object model was going to take place, more time should have been taken to develop a simple, innovative object model that fits with the branding of PHP as an easy language to develop with. Instead of rushing to get PHP tight with enterprise applications in a short amount of time, PHP could have introduced an innovative object model that is much simpler and more in line with PHP’s essence.
All of the work spent making PHP a Java object model clone could have been put into creating consistent naming conventions throughout the package and creating a more consistent syntax for the entire package. This would have given the community what it wanted: simplification, not more complexity. Or what about devoting all that energy to creating complete and simple Unicode support instead of having to go through all the hoops that are necessary still with the introduction of PHP5 to maintain a multilingual website?
Surely as a hypertext preprocessor, PHP needs robust Unicode support far more than it needs a complex object model that already exists in other packages more suited for those tasks. However, it seems that PHP isn’t happy with what it is, and rather than building upon what has given PHP so much character, it’s trying to be something that it’s not or at least something contradictory to the qualities that the PHP community has clearly stated as their reason for implementing the package.
Next: What would Linus do? >>
More PHP Articles
More By Ian Felton
|
| · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | · | | | | |
|
