Anyway, during the view building process, we may see the following in the couchdb.log (level = info, at least, in local.ini):

[...] [info] [...] checkpointing view update at seq 78163851 for citations _design/erlang
[...] [debug] [...] New task status for citations _design/erlang: Processed 17844590 of 107444308 changes (16%)
[...] [debug] [...] New task status for citations _design/erlang: Processed 17848060 of 107444308 changes (16%)
[...] [debug] [...] New task status for citations _design/erlang: Processed 17850878 of 107444308 changes (16%)
[...] [info] [...] checkpointing view update at seq 78170348 for citations _design/erlang
[...] [debug] [...] New task status for citations _design/erlang: Processed 17851087 of 107444308 changes (16%)

The above tells us, that CouchDB saved the current process during indexing and allows us to resume in case we decide to restart the CouchDB and interrupt the indexing process. I've tried it myself a couple times with CouchDB 0.10.0 — I also had not noticed this feature prior to it.

And why is this useful in particular? The biggest use for this is upgrading computing power (e.g. on AWS EC2) when we realize we need MOAR and then we are still able to resume when we boot into more resources.

Sidenote: Checkpointing will not help if indexing is stopped and the view is adjusted/changed. Or when the indexing stopped due to an error, such as a crash.

That's all, kids.

My idea is to introduce CouchDB to a world where database-driven development generally refers to MySQL. By no means, this is meant to be disrespectful to MySQL, or SQL-databases in general. However, I'm a firm believer in using the right tool for the job.

First things first!

First off, before using CouchDB and maybe eventually replacing MySQL with it, we need to ask ourself the "Why?"-question.

And in order to be capable of more than a well-educated guess we need to familiarize ourselves with the CouchDB basics.

Basics

• Document-oriented and schema-less storage.
• Erlang (for rock-solid-scaling-goodness).
• RESTful HTTP-API (we'll get to that).
• Everything is JSON - request data, storage, response!

Document-oriented

In a document-oriented as to opposed to a relational store, the data is not stored in table, where data is usually broken down into fields. In a document-oriented store each record is stored along side and can have its own characteristics — properties of any kind.

As an example, consider these two records:

Till Klampaeckel, Berlin
Till Klampaeckel, till@php.net, Berlin, Germany

In a relational store, we would attempt to break down, or normalize, the data. Which means that we would probably create a table with the columns name, email, city and country.

Consider adding another record:

Till Klampaeckel, +49110, till@some.jabber

(Just fyi — this is not my real phone number!)

Looking for an intersection in the records, the name is the only thing this record has in common with the previous two. With a relational database, we would either have to add a column for phone number and chat, or we would start splitting off the data into multiple tables (e.g. a table called phone and one called chat) in order to get grip.

With a document-oriented database — such as CouchDB — this is not an issue.

We can store any data, constraints do not apply.

Erlang

Erlang was invented a while ago, by Ericsson, when it was still sans Sony. In a nutshell, Erlang's true strength is reliability and stability. It also manages to really utilize all the resources modern hardware has to offer since it's a master of parallelization.

CouchDB is written in Erlang, and also accepts view code written in Erlang. More on views later.

RESTful HTTP-API

For starters, a lot of HTTP-APIs claim to be RESTful, most of them are not. HTTP has so called request verbs (DELETE, GET, HEAD, POST, PUT among them) and a lot of APIs don't use them to the fullest extend, or rather not all.

Instead, most APIs are limited GET and maybe use a little POST. An example of such an API is the Flickr API.

Most of us are familiar with GET and POST already. For example, when you opened the web page to this blog entry, the browser made a GET-request. If you decide to post a comment later on — you guessed it, that's a POST-request.

Aside from its basic yet powerful nature, HTTP is interesting in particular because it is the least common multiple in many programming language. Whatever you use — C#, PHP, Python, Ruby — these languages know how to talk HTTP. And even better — most of them ship pretty comfortable wrappers.

JSON

JSON — it's godsend for those of us who never liked XML.

It's very lightweight, yet we able to represent lists and objects, integers, strings — most data types you would want to use. A clear disadvantage of JSON is that it lacks validation (think DTD), and of course comments — ha, ha!

Why, oh why?

So along with "Why?", we should consider the following:

• Does it make sense?
• Is CouchDB (really) the better fit for my application?
• What is my #1 problem in MySQL, and how does CouchDB solve it?

And if we are still convinced to migrate all of our data, we'll need to decide on an access wrapper.

It's all HTTP, right?

By now, everyone has heard that CouchDB has a RESTful HTTP-API. But what does that imply?

It means, that we won't need to build a new extension in PHP to be able to use it. There's already either ext/socket or ext/curl — often both — in 99% of all PHP installs out there. Which means that PHP is more than ready to talk to CouchDB — right out of the box.

Since I mentioned JSON before — today ext/json is available in most PHP installs as well. If however we happen to be one of the few unfortunates who don't have and cannot get this extension, we should use Services_JSON instead.

Install it!

CouchDB installations are available in most Linux and Unix distributions. On MacOSX, get CouchDBX — the one-click CouchDB package, and there's a work in process for Windows as well. Especially interesting for those who run Ubuntu 9.10 (which has been released a few days ago), there's already a CouchDB install included.

Ubuntu/Debian:

apt-get install couchdb

FreeBSD:

cd /usr/ports/databases/couchdb && make install clean

Matt says (5:22):

So a common misconception about the GPL is that, like let's say, I'm hired to make a theme for a client. Does that theme fall under the GPL? And the answer is, no! Because it's not being distributed. Uhm, when something is distributed it's available for download to the public, you're selling it in a store, you know, it's sort of mass-distribution. When you do something for one site, or just for yourself, like for example, the theme on my blog, it's just for one site. It's not being distributed in any way. The GPL doesn't kick in.

But the GPL kicks in.

First off, whenever you base your work on GPL code it becomes GPL. Matt also agrees on that (if you watch the entire video).

The questionable part is:

• Is distribution really a requirement? Or is it GPL right from the start?
• How do you define distribution?

First off, I could not figure out the distribution requirement, but if in doubt, I think it is not a requirement for your code to become GPL. This is indeed what a lot of people describe as a loophole in the GPL and this is why the AGPL was invented.

Furthermore, what Matt thinks distribution is ("available for download to the public, you're selling it in a store"), is wrong. It does not matter if the code is distributed given to a friend, client, your grandmother or someone riding the subway with you. It's always GPL.

What I agree on is, that the GPL does not force anyone to distribute their code, or changes to GPL code.

In the end, the bottom line is: When the code is given away, it is GPL — the license applies!

AGPL vs GPL

I've previously blogged about the differences of the GPL to AGPL. The fundamental difference is that when GPL code allowed anyone to make changes and they could keep the changes to themselves, the AGPL requires them to contribute those changes to the project. In today's world, and with the nature of most of the software and its environment, it's virtually impossible (or illegal) to not contribute them back.

Conclusion

The GPL really means that whenever Matt decides to give his theme away (for money, or for free), he will have to provide the full sources of it, etc.. So for example, Matt couldn't use an encoder to hide his secret PHP code and then offer it for download.

And that is all.

I went to nosqlberlin last week and I got inspired. I listened to a lot of interesting talks — most notably about Redis, CouchDB, Riak and MongoDB (I'm omitting two talks, which of course were not less awesome than the rest!) Due to an unfortunate circumstance I had six hours to hack on stuff from Thursday to Friday.

And here it is — I'm proud to present my very own approach to key-value stores: TillStore!

What is a key-value store?

In a nutshell, a key-value store is a database for values (Doh!). There are no duplicates, it's always a key mapped to a value. No bells and whistles — most just want to be fast. Eventually consistent is another attribute which most of them like to claim for themselves. The value term (in key-value store) is very flexible. Some key-value stores only support certain types, TillStore supports them all through JSON. ;-)

Other examples for key-value stores include Riak, Redis, Cassandra and Tokyo Cabinet.

TillStore?

So vain, right? Well, in the beginning TillStore was an inside joke with a colleague. And to be honest, TillStore was nothing more but the following:

<?php
$tillStore = array();
?>

However, when I had time to hack away on Thursday night, I took it a slightly higher level. ;-)

Here's the environment:

• Amazon AWS L Instance (ami-eef61587)
• Ubuntu 9.04 (Jaunty)
• CouchDB 0.9.1 and 0.10.0
• database size: 199.8 GB
• documents: 157408793

On to the tips

These are some small pointers which I gathered by reading different sources (wiki, mailing list, IRC, blog posts, Jan ...). All those revolve around views and what not with a relatively large data set.

Do you want the speed?

Building a view on a database of this magnitude will take a while.

In the beginning I estimated about week and a half. And it really took that long.

Things to consider, always:

• upgrade to trunk ;-) (or e.g. to 0.10.x)
• view building is CPU-bound which leads us to MOAR hardware — a larger instance

The bottom line is, "Patience (really) is a virtue!". :-)

A side-note on upgrading: Double-check that upgrading doesn't require you to rebuild the views. That is, unless you got time.

View basics

When we initially tested if CouchDB was made for us we started off with a bunch off emit(doc.foo, doc)-like map functions in (sometimes) temporary views. On the production data, there are a few gotcha's.

First off — the obvious: temporary views are slow.

Back to JavaScript

Emitting the complete document will force CouchDB to duplicate data in the index which in return needs more space and also makes view building a little slower. Instead it's suggested to always emit(doc.foo, null) and then POST with multiple keys in the body to retrieve the documents.

Reads are cheap, and if not, get a cache.

doc._id

In case you wonder why I don't do emit(doc.foo, doc._id)? Well, that's because CouchDB is already kind enough to retrieve the document's ID anyway. (Sweet, no?)

include_docs

Sort of related, CouchDB has a ?include_docs=true parameter.

This is really convenient — especially when you develop the application.

I gathered from various sources that using them bears a performance penalty. The reason is that include_docs issues another b-tree lookup for every row returned in the initial result. Especially with larger sets, this may turn into a bottleneck, while it can be considered OK with smaller result sets.

As always — don't forget that HTTP itself is relatively cheap and a single POST request with multiple keys (e.g. document IDs) in the body is likely not the bottleneck of your operation — compared to everything else.

And if you really need to optimize that part, there's always caching. :-)

Need a little more?

Especially when documents of different types are stored into the same database (Oh, the beauty of document oriented storage!), one should consider the following map-example:

if (doc.foo) {
    emit(doc.foo, null)
}

.foo is obviously an attribute in the document.

JavaScript vs. Erlang

sum(), I haven't found too many of these — but with version 0.10+, the CouchDB folks implemented a couple JavaScript functions in Erlang, which is an easy replacement and adds a little speed on top. :-) So in this case, use _sum.

Compact

Compact, I learned, knows how to resume. So even if you kill the process, it'll manage to resume where it left off before.

When you populate a database through bulk writes, the gain from a compact is relatively small and is probably neglectable. Especially because compacting a database takes a long while. Keep in mind that compaction is disk-bound, which is often one of the final and inevitable bottlenecks in many environments. Unless hardware is designed ground up, this will most likely suck.

Compaction can have a larger impact when documents are written one by one to a database, or a lot of updates have been committed on the set.

I remember that when I build another set with 20 million documents one by one, I ended up with a database size of 60 GB. After I compacted the database, the size dropped to 20 GB. I don't have the numbers on read speed and what not, but it also felt more speedy. ;-)

Fin

That'd be it. More next time!

We decided to leverage RightScale when we planned our move to AWS a couple months ago in order to not have to build everything ourselves. I've been writing this blog entry for the past five weeks and here are some observations, thoughts and tips.

RightScale

First off, whatever you think, and do, or have done so far, let me assure you, there's always a RightScale way of doing things. For (maybe) general sanity (and definitely your own), I suggest you don't do it their way — always.

One example for the RightScale way is, that all the so-called RightScripts will attempt to start services on reboot for you, instead of registering them with the init system (e.g., on Ubuntu, update-rc.d foo defaults) when they are set up.

You may argue that RightScale's attempt will provide you with a maybe more detailed protocol of what happened during the boot sequence, but at the same time it provides more potential for errors and introduces another layer around what the operating system provides, and what generally works pretty well already.

PHP and RightScale

RightScale's sales team knows how to charm people, and when I say charm, I do not mean scam (just for clarity)! :-)

The demos are very impressive and the client show cases not any less. Where they really need to excel though are PHP-related demos because not everyone in the world runs Ruby on Rails yet. No, really — there's still us PHP people and also folks who run Python, Java and so on.

Coming from the sales pitch, I felt disappointed a little because a standard PHP setup on RightScale is as standard as you would think three years ago. mod_php, Apache2 and so on. The configuration itself is a downer as well, a lot of unnecessary settings and generally not so speedy choices. Then remember that neither CentOS nor Ubuntu are exactly up to date on packages and add another constraint to the mix — Ubuntu is on 8.04 which is one and half years in the past as I write this entry.

And even though I can relate to RighScale's position — in terms of that supporting customers with all kinds of different software is a burden and messy to say the least — I am also not a fan.

Scaling up

The largest advantage when you select a service provider such as RightScale is, that they turn raw EC2 instances into usable servers out of the box. So far example setting up a lamp stack yourself requires time, while it's still a trivial task for many. With RightScale, it's a matter of a couple clicks — select image, start, provide input variables and done.

Aside from enhanced AMIs RightScale's advantage is auto-scaling. Auto-scaling has been done a couple times before. There are more than one service provider which leverages EC2 and provides scalability on top. Then take a look at Scalr, which is open source, and then recently Amazon themselves added their own Elastic Load Balancer.

In general, I think auto-scaling is something everyone gets, and wants, but of course it's not that dead simple to implement. And especially when you move to a new platform, it's a perfect trade off to sacrifice a flexibility and money for a warm and fuzzy "works out of the box" feeling.

A rescue party

Of course this is the last thing you want on a Sunday evening, but in true GTD fashion, I wanted to fix it right away. Here's how.

Precaution

In order to not electrocute myself, I removed the battery and unplugged the notebook.

Get in there!

I basically unscrewed every screw there is at the bottom of the notebook, until it would let me remove the upper part of the casing and keyboard.

Then I tried to carefully clean the inner of my notebook from dust and dirt that accumulated over the past 14 months since I purchased it. I think had dust (and what not) from North America, Europe and South America in there. It was kinda gross. It really didn't look pretty. And that is despite all efforts to not eat and drink near it.

Fan

When I got to the fan, it wouldn't really move. Hence the fan error!

I forced it a little and white dust came out of it. So I decided to take more drastic measures and sucked it clean using my Dyson. In the beginning it wouldn't really move, but it took only a minute to resolve that. (Word of advice: If you are not super careful, the Dyson will try to suck in whatever it gets. So make sure to not vacuum the insides of your notebook. ;-))

Reassembly

Reassembly is pretty simple. The case clicks, and then you fill in the screws. IBM/Lenovo were smart enough to only use screws of the same type. There was a total of ten (or maybe nine), and they are all gone. So that must have worked.

Conclusion

Don't try this, unless you have to. And know what you are doing. This blog entry comes with no guarantees or extended warranty. Being able to fix little things yourself, feels good though.

I wish AWS would make this part slightly easier, e.g. by announcing a customer's own IP space.

Planet-PHP

Planet-PHP's code has been opensourced for a while and when I started setting up a planet for PEAR I wasn't exactly happy with what it did. Aside from the obvious PHP4 vs. PHP5 issues, the unfortunate lack of documentation, I don't understand why anyone wants to transform an XSL with PHP, to generate PHP. And the bottom line, it didn't work always and I didn't want to debug it any longer.

The notable features include:

• Restructured the code to only expose what is necessary in the document root.
• Fixed/improved configuration handling.
• Extended/improved templating.
• Code cleanup, where possible.
• Fancy URLs and front controller pattern using Net_URL_Mapper! :-)
• Webbased admin to add and remove feeds to the planet.

Long story short — the code is on github. It's semi-complete, on the list of things to do are removing the libraries which became obsolete, a (new) submit form, a cache and maybe re-writing the importer/aggregate script.

Also, kudus to Christian Weiske for contributing the admin and generally helping out. :-)

Scr.im

scr.im is a nifty service which allows you to spam protect your email address. So, for example, instead of display name@example.org on your website, you'd provide a link where people enter a captcha to see your email address. I know this is not compliant with the German law and what not, but I wrote a service wrapper for their API anyway. I'll put it online when I find time. The code is on Github, check the README for an example.

Net_URL_Mapper

I never had a chance to explore Net_Url_Mapper before and I must say, this is definitately one of the (many) raw diamonds in PEAR. Raw because its lack of documentation is not exactly helpful when it comes to adoption. Since I spent some time with the package on the Planet-PHP rewrite, I decided to contribute documentation. If you're anxious to check it out, follow this link, or wait until next week when the manual on the official website is updated.

Habe eben bemerkt, dass der Mobilfunkanbieter meines Vertrauens (die Mobilcom) jetzt zu Debitel gehört, oder anders herum. Auf jeden Fall hat sich im Zuge dieser großartigen Fusion der Kundenbereich der Login grundlegend geändert — anscheinend habe ich jetzt einen Benutzernameich muss mich mit meinem Benutzername einloggen.

Auf zum Benutzernamen

Der theoretische Weg zum Benutzernamen (und neuem Passwort) ist wie folgt:

• Ich gebe meine Telefonnummer in ein Formular ein und bekomme dafür die Kundennummer per Email zugeschickt. Wohin weiss ich nicht. Zum Glück hatte ich da bereits eine Emailadresse hinterlegt.
• Danach gebe ich die Kundennummer und meine Telefonnummer in das nächste Formular ein und bekomme danach meinen Benutzername zugeschickt.
• Dann gebe ich meine meine Kundennummer und meine Telefonnummer in das nächste Formular ein um ein neues Passwort per SMS zugesendet zu bekommen.

Und dann kann ich mich schon einloggen!

Äh, ja.

Die Fragen die sich zu diesem Vorgang stellen sind:

• Warum habe ich jetzt einen Benutzernamen?
• Sind Telefonnummern nicht eindeutig genug?
• Wofür brauche ich eigentlich eine Kundennummer?
• Wieso kommen alle Daten nicht per Email oder per SMS?

Spontan ergibt sich sich hier die eine oder andere kleine Rationalisierungsmaßnahme.

Und sonst?

Ich bin bereits im zweiten Schritt gescheitert — der Benutzername hat sein Ziel nie erreicht. Außerdem gab's auch noch zufällig jene Meldung:

Danke!

In advance — in order to be save than sorry — we had bought an external hard drive and did a backup of her home folder (6 GB — I wish my own backup was that size ;-)).

The one thing I ran into was that after the installation finished, I tried to reconnect to our wifi — but if failed. It wouldn't even show the network.

Since I knew that hooking up the Mini using a cable required me to move everything from her desk in one room to another room, I gave up last night and had myself a beer instead.

A solution

This morning, I briefly researched the issue on Google and found a thread on apple.com where people suggested to do the following:

• Go into System preferences > Network
• Click on Airport
• Delete the "Automatic location" profile
• Add your own
• Disable/enable Airport
• Done

Well, that almost worked for me.

I also re-added our wifi to the preferred network list and we were instantly reconnected.

Anything else?

Aside from the wifi issues almost everything migrated without issues.

This is still a pre-Intel Mac Mini. All her email, pictures and documents are in place. The only thing I need to reinstall is something called Kodak Easy Share since whatever she has installed doesn't seem to work right now.

And as a bonus, Snow Leopard feels faster even on this aging little piece of technology.

Anyway, I just thought I'd share.

In related (BC) news, most people probably read my blog because of Zend Framework, and I remember that one of the reasons I sold my clients on Zend Framework was a supposedly backward compatibility and clean API. Well, a couple years later one knows it's not all that and since another BC break was argued today on one of the mailing lists and the project lead said I spread fud, I felt l needed to write something on the topic.

Facts first.

A small history of PEAR.

I don't know how old exactly PEAR is, but the manual is copyrighted since 2001 and none of the other current frameworks have been around eight — almost nine — years.

Because PEAR has been around much longer, we also have more older code than any of those PHP5-only frameworks. In comparison, Zend Framework's first stable was release in June, 2007, almost six years later.

Major versus minor releases.

A package' version consists of x.y.z.

The rules are as follow:

• A BC break (see below) — increment x, and set y and z to 0.
• Adding a new feature — keep x, increment y and set z to 0.
• Fixing a bug — keep x and y, but increment z.

When someone refers to a major release in PEAR's context (and a lot of other projects such as Zend Framework, Solar and ezComponents follow this), it's one with a change in x. :-)

What is backward compatibility?

Backward compatibility, or BC, describes that a component, package or library preserves compatibility with an older versions.

Because programming itself and developers tend to evolve, PEAR tries to keep BC in all minor versions, but allows you to break compatibility to an earlier version with a new major release.

The exception to the rule is that you may break BC during alpha and beta releases before the package reaches a stable 1.0.0. Once a 1.0.0 is reached, BC may not be broken — for whatever reason.

PHP4?

Because PEAR aims to provide BC all the way, BC includes the PHP version when the package was first released. Which in turn means that of course you may make the code compatible to a later PHP release, but not without breaking compatibility to the initial release.

If you followed the above, you understand the reason why for example there is a Mail_Queue and (a soon to be) Mail_Queue2, or more importantly: why the Mail_Queue release in 2009 is still compatible to PHP4. Even though PHP4 EOL'd a while ago.

The first Mail_Queue package was released in September of 2002, the 1.0.0 stable release followed in December of the same year. Because its 1.0.0 was compatible with PHP4, we keep it backwards compatible with PHP4 until we release Mail_Queue2-0.1.0.

A principal

A lot of people argue that with the official end of life of PHP4, one should break BC anyway. But here is why you should not.

• Even though we all love to use PHP5, there is still a lot of PHP4 in the enterprise. And like it or not, many of those apps use PEAR, and not your funky PHP5 framework.

• How do you keep so-called necessary and unnecessary BC breaks apart? From another point of you (which is not your own), there is always a necessary BC break to fix implement something else.

• Because there is no such thing as small or acceptable BC breaks. There are BC breaks or there are none, it's one of those things that is black and white.

BC in other frameworks

I know for a fact that ezComponents is very strict on BC. I cannot comment on Solar or Symfony, but at least in Solar's case, I'm assuming that adhere to BC as well since a some former PEAR developers are active and they also follow the PEAR Coding Standard in many respects.

Zend Framework?

A friend of mine said that if Zend Framework really kept BC, we would at 10.0.0 and not on 1.9.3.

Reasons why Zend Framework likes to break BC, even though it advertises full BC:

• No versioning per components but per framework.

• Missing peer review and QA leads to unstable code in a so-called stable release. (Which in turn also fakes the stability of the entire framework since it suggests that a component that was added a couple weeks ago is as stable as a component added in 2007.)

• Because it fixes an "issue". (Biggest WTF of them all.)

The issue in question, I'm not even sure what they were trying to fix. Supposedly some developers found it too hard or did not understand how to write an adapter for Zend_Db and someone committed a fix in the 1.9 tree/branch and apparently it was OK to break BC because it was the easier way out.

I haven't updated some projects since late 1.8.x because of these BC breaks because no one can tell me what the issue is and I don't have a day to debug my application to figure out where and how it breaks. This is annoying as hell, especially since they are supposed to be tailored to the business.

On a side-note, I know of a couple components (e.g. Zend_Session) which really deserve (!) a BC break and don't get one until 2.0. And I totally get why, but why is it OK in some cases? All BC breaks fix issues!

(Btw, as I finish this post, I see an email to zf-contributor@ in my inbox where someone considers pulling the 1.9.3 release (because it obviously breaks BC). Guess I didn't spread that much FUD after all.)

The reasons why I usually avoid tech conferences include foremost the price tag (working for myself, I can technically label it as an expense, but I still have to pay for it), doubts that it'll be worth it in terms of knowledge gained and probably time. I tend to catch up with people outside of conferences (when they are in Berlin :-)) and that has worked well for me.

I'm glad I set all these things aside for Hamburg (and it was all too easy). A lot of people expressed how much they liked their (often 3rd) PHP Unconference, and I can second, or third that — job really well done. Ulf Wendel took it one step further, blogged and asked, "Is perfect too boring?", because everything worked out so well. I guess I would say, "No, it's not boring", and I'm inclined to add, "Thanks, it really felt like having a weekend off, yet I still learned something and met a ton of nice people (or connected online nicknames to real faces)!".

I can definitely see why people visit the PHP Unconference each year, and I'll be one of them next year! ;-)

As I said, I had a great time, both my topics were accepted too. One was merged with another PHP performance talk which was overbooked with PHP VIPs which is why I decided to listen to Kore Nordmann's talk on CouchDB instead, and the other one ("Deployment") — I kind of overslept. And I'm sorry about that! I'll make sure to avoid party, party Hamburg next year.

Here are the slides for my Zend Framework (performance) talk, I hope you find them interesting:

The slides and speaker-notes contain…

• a small intro as of why I think it's worth while to get into the ring with it
• hints and pointers on general PHP optimization
• I detail on a couple components (e.g. things to look out for and how to overcome them)

Make sure to check the speaker notes (using this link) — I didn't put everything in there, but a lot.

(The deployment slides will be up later this weekend.)

This also reminds me to improve my presentation-fu. I need something as kickass as keynote, but for Windows (currently). If anyone has a pointer, let me know. ;-)

In Part I, I talked about my approach to deploying a website and I offered pear and subversion as solutions to the problem. To briefly elaborate on my subversion part, I want to share the following Capistrano recipe with you.

Capistrano, isn't that Ruby?

Yes it is! Capistrano is a nifty piece of software. Not because it's so super-duper complex, but because it's pretty robust and works really well.

I am sure everyone heard of the "the right tool for the job" theory and this is along those lines. Please don't be afraid of a little Ruby to ease the deployment process. (They don't deserve your fear anyway. ;-))

Installation

On FreeBSD:

cd /usr/ports/devel/rubygem-capistrano && make install clean

On Debilian/Ubuntu:

apt-get install rubygems
gem install capistrano

Go on and create a capfile in $HOME, and this is where we'll keep our tasks.

But (primarily) due to RoundCube being licensed under the GPL, I think I do know what it entails to release code using this license. In addition to that I have read a lot about the license, I even wasted spent three hours one night to listen to RMS.

In the end — the GPL just did not grow on me, or made me happy.

Open source

I am a firm believer in open source. I release code for free. Whenever I have the choice, my free contributions include the freedom to really do whatever you want with my code. Because if I did not meant it, I would either sell the code, or not share it at all.

I recently read Zed Shaw's reasoning why he believes in the [A,L]GPL and that same day I walked into yet another license discussion on PEAR's IRC channel (#pear@efnet), and I felt like I need to write it all out.

The GPLs

GPL in a nutshell

• The GPL means that whenever I use code that is licensed under it in my code, my code automatically becomes GPL too.
• The GPL requires me to release the source code of the software when I give it to others [them].
• The GPL allows them to give it to other people as well, license still applies.
• (Contrary to popular believe, ) The GPL also allows me to sell software. I'm not required to give it away for free.

If you still do not understand what the above means, here's an example: Wordpress. Wordpress is GPL and therefor all plugins written for Wordpress are GPL too. I realize some people may think that there might not be too much that you can do in a plugin, but if you wanted to make money of your work (plugin), the options are pretty limited.

LGPL in a nutshell

The LGPL is basically the same as the GPL, but if I use LGPL software inside my software, my software does not become GPL.

Affero (L)GPL

Because web software is often not distributed (think of SAAS), the GPL people came up with an Affero clause.

This clause requires you to open source your changes to a software/library even if it's only accessible through the network. In plain English — if you do SAAS (Remember, plain English!), or a simple website, and do not directly distribute your source code to your customer, you will still have to open source your changes because your customers can access it anyway.

The Affero clause is currently available as AGPL, and soon as ALGPL.

Non-restrictive licensing

When I speak of non-restrictive (or liberal :-)) licenses, I think of the (new) BSD, MIT and Apache licenses. In a nutshell, they all allow you to really do whatever you want. Whatever, of course except for removing the copyright on the source code.

• They do not force you to open source your changes to the code.
• They do not force a license on your own code just because you happen to use it.
• The do not force you to release the source code to your customers.

Reading the above, one would see that these licenses are very compatible with typical business interests. They all come in handy for frameworks such as ezComponents or the Zend Framework — and many PEAR components use them as well. They really bring freedom of use the user, without imposing any duties on the user, and the best of all: the user can contribute anyway.

Impose

For a lot of people the world is black and white. You see other people benefiting from your own work hiding everywhere. And it's all too easy to find a license to impose your own beliefs on others. Because if they do not get it, there is a way to make them.

This rather simplified approach to a pretty complicated topic is easier to comprehend and therefor popular. And I can't blame anyone. Think further — religion. People who convert or find a thing for themselves easily become outspoken about and start preaching their new found happiness to others.

It's very human. If it makes you happy, you want to share.

This is of course meant with no offense to people like Zed Shaw who feel like they did not get their share of the cake (even though — Hey Zed! — a ton of people run your software (Mongrel)). I do understand Zed's point of view though. Visibility in the open source world does not pay your monthly bills. I'm not naive like that. On the other hand, there are more than a few examples from the the open source world where a company is build around an open source product and the company offers services — such as consulting and support — for said product.

The bottom line for myself is that I do not like to force people to do something. And no one does, right? (Except when the motives allow it!)

Conclusion

I believe that more people will contribute to open source because they believe in the cause. Not because some license forces them to do so. A lot of people get into open source because they use(d) open source software already and decided to contribute to the community. A lot of commercial entities fund open source development — heck, for whatever reason, even Microsoft does it.

If anything, the Affero clause will cause is to hinder the adoption rates of the software in question. And that is not just because all these licenses are written in English which requires a law degree, but because when you manage to understand them, they impose a threat on your own intellectual property.