Till's blog

Last week the usual round of PEAR-bashing on Twitter took place, then this morning Marco Tabini asked if PHP (core) was running out of scratches to itch. He also suggests he got this idea from Cal Evan's blog post about Drupal forking PHP.

• http://blog.tabini.ca/2011/04/is-php-running-out-of-itches-to-scratch/
• http://blog.calevans.com/2011/04/07/four-reasons-why-drupal-should-fork-php/

[Not submitting to your linkbait.]

Pecl and PHP

So first off — moving libraries from the core to an external repository was done for various reasons. One of them is to not have to maintain more and more in the core — keep it small and lean. Though small is pretty relative in this respect.

Of course doing so, means that people who do not have root on a server cannot install the module in most cases. But I'm inclined to suggest that when a pecl extension is (really) required, there should be nothing holding you back.

And if there is no way, thanks to PHP's extentability there's almost always a PHP-equivalent to any c-extension available.

Drupal and PHP

I know a couple Drupal people myself and most of them consider themselves to be Drupal developers before PHP. Why is that? It's because Drupal found a great way to abstract whatever people annoys about PHP from its developers, thus enabling them to build websites.

Is this a good or bad thing?

Of course it's a good thing because it makes people productive.

It's also a bad thing, because it seems that some (Drupal) people are rather disconnected from upstream [PHP].

Enabling people

Whatever people think about Drupal or any other framework, keep in mind that apparently it's PHP (and not Ruby, Python or pure C) which is more than a good enough enabler because PHP allows people to build a sophisticated content-management-framework like Drupal on top of it.

Drupal is of course no exception here. Despite e.g. the standstill in Ruby-land, in PHP other tools developer over the years who are a defacto standard: take a look at Wordpress or phpBB.

If you'd like to take it down to the framework-level there are projects like Symfony, CodeIgniter, Zend Framework, ezComponents/Zeta and also PEAR.

Fork vs. wat?

I think that forking PHP is a joke and I believe that Cal doesn't know the difference between a fork and a custom package (or a distribution).

A fork usually adds or removes features from the actual code base, but reading Cal's blog post he suggests a custom package. [Woo! Technical details! They get lost along the way!]

The thing is that a lot of people do this already. The people maintain a PHP package for a certain Linux or Unix distribution — Debian/Ubuntu, Gentoo or FreeBSD — there are doing it already. Using these as an example, whatever OS is used, it already runs a customized version PHP; some distributions customize more than others.

No one objects to the Drupal community suggesting ./configure flags or maintaining packages for the various flavours of Linux and Unix, or even Windows.

I would even go as far and say that in order to optimize the stack completely, it wouldn't hurt Drupal if its community recommended flags and extensions for people who run Drupal sites.

I doubt though that anyone will maintain packages for a couple distributions in their spare time and that the majority will not benefit from this effort because they don't run Drupal on their own server. But generally this optimization is enterprisey enough and indeed what I call a business opportunity.

Moving Drupal to ...

So what's "..."? Moving it to Python or Ruby, or maybe Scala? Good luck with that.

While the majority of Drupal developers don't consider themselves to be PHP developers, they still live and benefit off the PHP ecosystem. Think libraries used in modules or used for other areas like testing. Good luck porting those.

Then add PHP's vast adoption among webhosts.

Last but not least

Which brings me to the in my opinion biggest selling point: Doing PHP has another slight advantage over Ruby, Python and the other languages — it's installed on over 90% of the shared webhosts out there.

I invite everyone to google php hosting. It's trivial to find a host for as low as a Dollar per month — you just can't beat that.

Dear Cal, if you call this a business opportunity, I wonder why there's no Dollar Ruby hosting yet. Or Java hosting for a Dollar. But maybe someone is just not seeing this great business opportunity? [Note, Sarcasm.]

PEAR and PHP

What really bothers me about flaming PEAR is that the most vocal people in these flamewars never contributed any code. Open source is different from the Monday morning meetings some people are used to and where they talk people against the wall.

In open source land actual code contributions take the lead.

And while a lot of people complain about PEAR in general, here's something else:

• thriving download stats of packages
• PEAR package usage in other projects
• adoption of the PEAR coding standards and conventions
• PEAR channels thriving
• overall installer adoption

Despite being called a mess, PEAR is an enabler for many.

Point taken

PEAR being so many things is confusing!

PEAR packages are not as easy to use as some code you copy-pasted off the Zend devzone or phpclasses. While I agree, that we should try to make it just as easy, it's just not one PEAR's goals right now.

Scratching my own itch

Scratching your own itch, is what code contributions to PEAR are currently all about. Maybe always have been.

Active package maintainers most often contribute to packages they use themselves and they contribute to PEAR's environment to move development forward in areas where its beneficial to them. Call that selfish, but the reality is that most of us contributors actually work in this web industry and we know what we want and therefor we do it.

At the same time PEAR has coding standards and convention which are in place to ensure code is written so its to the benefit of most people.

Maintainership burden

The offiside to this situation is of course that components none of the maintainers have a use for get neglected — but calling this a PEAR-only problem really one-side.

Not even company-driven frameworks like the Zend Framework are prone to this; Zend_GData is/was rather unmaintained for a long time. Or frameworks where the proposal process and architecture are valued above all; I could point how broken ezcFeed is for me. Or general issues I see in projects where decisions are primarily driven by a single person — catch my drift?

This is not meant a pissing contest between frameworks, but I just can't hear it anymore.

Developer-friendly

Is PHP generally developer-friendly?

At the expense of watering the term developer, I'd say yes.

It is extremely easy to get started — embed the following into a .php file:

<?php
echo "Hello World";
?>

There's your PHP. It doesn't require a custom webserver process, root server or anything else. It really doesn't get any easier.

Are PHP frameworks easier than frameworks in [your other favorite language]?

Probably not! Or, hell no!

But that's the barrier of entry to any if not all frameworks on the planet. Some frameworks allow you to write your own blog in 10 steps, but you will soon discover that writing your own blog is not a great indicator for a quality framework.

Indiciators are:

• maintained code
• coding standards
• tests

And if I'm allowed a snarky remark — these are areas Drupal is literally just getting around to.

PHP vs PHP

Destruction breeds creation — but I get the impression that all these fights inside the PHP community don't really make it foster more.

Fighting and trolling may be an art for some and I agree they are entertaining at times, but when it becomes the only way people communicate contribute then let me be clear: it doesn't help.

The PHP community seems to be unaware how thriving PHP is and also its ecosystem. People often mistake stabilization for decline. There's nothing wrong if we don't crank out five new major versions every year.

• People in the real world are conservative anyway and adoption is slow. [Not a PHP-only problem either, just ask the Ruby folks.]
• People in the real world don't mind a more stable PHP environment, at the expense of buzzwords and all that crap.

Fin

In hindsight everyone always knew.

I feel like the more vocal people sharing their opinion, are pretty disconnected from the reality. That is dispite them running a magazine or a podcast about the community.

When people resort to flaming others in order to make themselves look smarter or their own project better, then that's just poor judgement on their part. Projects often die off as fast as they came about.

Yelling, sometimes also referred to as shouting, is an old school management technique. Yelling has been around for literally as long as mankind walked on planet earth. And despite a great history of success, yelling is still often unappreciated and a misunderstood art.

key points

Let me summarize the key points — what yelling is all about!

• Yelling emphasizes one's opinion.
• Yelling helps to bring across your point.
• Yelling helps to avoid mis-communication.
• (Last but not least:) Yelling encourages people on your team to not make mistakes.

Next time, I'll explain other people management methods: name-calling and maybe mobbing.

I read a blog entry this morning entitled "The unbearable lameness of web 2.0" (scroll down for the English version).

In his blog entry Kris Köhntopp states how he's not satisfied with the status quo, and of course that he said it all before — in a nutshell, he wants a social networking standard which is adhered to across all platforms, e.g. Twitter, Facebook and whatever else there is in between.

This standard includes things like:

• a better like/friend/subscribe model
• auto-classification of contacts into interest groups (basically diaspora's aspect feature in automatic)
• aggregating and analysis of shared items in your own stream and the stream of your friends/followers
• providing sources (e.g. to be able to find the origin of a shared item vs. seeing it shared 20 times in your stream)
• … and language detection (and possibly translation)

I hope I got it all right (in a nutshell, of course).

Fundamental problems

The blog entry itself and the comments on his blog entry suggest how trivial and easy these features are, so I'm wondering why exactly no one implemented those yet?

Well, let me try to answer that.

Trivial?

These problems are not trivial and actually require a little more thought ("Googledenk", as Kris put it). I know there are services already that implement some of these features, but who knows apparently it's not that easy after all — but feel free to prove me wrong.

The average user

These problems are also not average user problems.

Yeah, there might be 10,000 or maybe even a 100,000 people on Facebook who have these problems, but not 50,000,000. Facebook being slightly more business oriented than the average "go build it for me" social media blogger, will build a feature for 50,000,000 first before it caters to the problems of those maybe 100,000 power users.

Power users are not their target audience. Mom and dad type of people are.

Given that there are indeed services that implement these features (or at least some of them) and their general lack of traction, kind of supports my argument as well. Apparently, this is something not too many people need.

A Standard!

Does anyone remember how well OpenSocial worked out? Good luck with that.

Can someone, please?

To all those people are pissed at diaspora because it's not what they thought it would be like.

Get a grip and contribute for f's sake.

If you want something to happen, maybe you just have to go further than to your blog to bitch about it. It's really easy to rant on Twitter or your blog (see this post for example :-)), but GTD — that's the hard part.

Playground

Last but not least people forget that when they get into social networking they have no rights.

Of course in some countries you may have a right to your data, but that's basically it.

There is no given right to access a platform, no right to certain features or how they are designed and there sure as hell is no right to any kind of API. Facebook, Twitter and StudiVZ — they all allow users to come play. There's nothing for a user to demand.

Fin

My point of view. If you beg to differ, go build it.