A couple of weeks ago we launched the website of a service we have been working on hard for over half a year. The project started as a SAAS about performance and hence the internal project name was “ProjectPAAS”. As it goes with internal project names, it became the name of the service it self.

12 seconds start now

I still have problems explaining what the service is doing in an elevator pitch. But basicaly one installs a module on a to be tested staging site from d.o with the funky URL /project/paas, configures the service on the portal of projectpaas.com and then wait an hour or two. We start a service to measure your site from the outside and from the inside, analyse the data, make a report and when you check your mail you get an in depth report on all the elements of the chain that are relevant to the performance of the website.

We measure from one or more selectable (EC2) locations in the world with over 150 metrics and we only report on real data, no yslow wisdom. We know what influence speed, we see how it is configured at your site (with the module or from the outisde) and we simulate to find the the optimal value would be for your use case.

The cliché for example that one needs parallel download (images[1-4].example.com) to bypass the maximumum connection a browser can have to a host, is just that, a cliché. When one takes DNS lookup,TCP slow start and the sliding window in to account, for certain usecase, having images[x].example.com might actually be slower. So we are opinionated, we measure, we analyse, we report, you gain speed.

Easteregg

I really like retro future so we used this for a theme around the site and facebook. But since easter (Dutch "pasen" is coming up,
do check the projectpaas.com website, find the easteregg and twitter about it. :-)

This posting isn't as much about the service of ProjectPAAS as it is about why we made the service. To share our experience and to get feedback from you. There are two reasons we made it, one is internally driven and one is externally.

The internal reason is that we have been building some of the most visited sites and webapps in Drupal in the Netherlands. So after some time we got good at performance, we understood what to do and what not to do for the complete stack of elements that define speed, HTML, CSS, Linux, Apache, MySQL and yes, Drupal. Word got out that we were good and siteowners that have been building their site at another company, came to us for advice on how to get more speed in their site.
Once we had done a dozen of these reports, we wanted to make the reports more easily accessible for the site owners and website builders. This is part of why westarted the Performance Reporting

Land here

The external reason might be more interesting for you. We made the SAAS because we think that the CMS landscape will change and our business will change.

The landscape will change. 10 years ago everybody had his/her own CMS, there were more CMS-es then websites it seemed. 5 yeas ago it was clear who were going to be the winners in the consolidation, 80% of the proprietary "solutions" were gone and open source was no longer a dirty word in enterprises. Within the open CMS-es, the global top 5 was visible though especially in Europe there were still many local open source CMS-es. This consolidation perse was good open source and especially for Drupal shops.

However, the market won't stop here. Most of the Drupal websites are not complex, they don't have any connections to backend systems, less than 10k pageviews per day and are relatively expensive to build and most of all expensive to maintain. Here is the business case for open source SAAS, solutions based on open source software like Aqcuia and Wordpress.com offer. These solutions with standard modules and a customisable template is good enough right now for 20% of the Drupal sites out there and will cost a fraction of what building it "by hand" will cost.

The users of these open source SAAS hosting solutions will only grow. Good for the parties offering these services, bad for the Drupal shops that have been building relatively simple portfolio sites. By itself, this trend might have a big impact those coding Drupal core, modules or working in for example the security team. This is not meant in a bad way, but with most of the sites going towards a smaler group of SAAS companies, the number of "independent" individuals adding to core or writing modules might actually get lower, they might have another itch. It will be very interesting to see how this will develop, I might be completely wrong here.

Performance takes time

Traditionally most Drupal shops do projects, do maintenance and do consulting. Some have found a nice niche, a place geographically apart, a specific vertical or a certain service like migration from another CMS. However, most Drupal shops build relatively simple websites for SOHO plus. I know there are many shops that work for high end enterprises. But not all the 280.000 Drupal sites fit in the Alexa top 100.000. So I do think that if you are a Drupal shop, you have to find your sweet spot the next couple of month. On the one hand we have operational excellence (a SAAS to host sites like gardens or a service like ProjectPAAS itself) and on the other hand customer intimacy (the complex sites with lots of integration with backend systems and complex workflow). There might be space between these two, but the portfolio site area will get very crowded and Drupal will not be the best tool to serve this in my opinion. This is part of the reason why we build our first SAAS around a product we understand and is close to our core business. We are already planning next services that might still be build in Drupal but will target a broader audience.

For the moment, if you are intersted in our product, dont be shy and talk to us on twitter or faces us. Potential resellers or users are welcome to fill out our form. We really do hope that our product can help you build faster websites and thereby push Drupal even more ahead of the curve.

A small plug, if you want to attend the Drupal event about design, frontend development and usability, be sure to take a look at frontendunited.org, London, April 13-14. I do think there are some of the best speakers lined up both from within our community and related communities, for example Christian Heilmann. The venue must be the coolest one ever to house so many Drupalistas. So think about ordering a ticket (free hugs from mortendk when you select community sponsorship) or become a sponsor and get some free tickets.

Order now and win a pony.

Last year, I was one of the coorganizers of Frontend United In Amsterdam, The Netherlands. I have organized dozen of events, DrupalCons, DrupalJams, DrupalCamps totaling a dozen of events. The best and most funny to organize of them all however was the Frontend United conference with good friends Jesper, Marek, Morten, Philippe and angel Isabelle. The weekly conference calls quickly became a selfhelp group and the best comedy channel available.

The fun we had organizing the event, clearly payed off and turned the event in to the best event I ever attended. Mostly because Fronten United is different. We have some rules to live by and these rules help us organize it and give the best value possible to the attendees. In fact, we try to be for Drupal what TED is for technology! Our rules are simple

1. Outside in, not inside out
2. Attendees first, not the sponsors (or mobile :-)
3. Grow horizontally, not vertically
4. Maximum value for attendees
5. Nerds rule

These are simple rules, resulting in a great conference. Outside in means we will look at technology, design. The unimportant stuff and then but only then Drupal. We look at speakers who are architects, painters, people whose actions or ideas are completely irrelevant for Drupals community in the narrow sense but if mapped on our community, code or license of great influence. We value attendees above sponsors. We do *heart* our sponsors, they are the best. But in the end the sponsors and the organizers work for the attendees, not the other way around. We will never do a sponsored talk, an opening by a sponsor or a case-study, mixing content and sponsors is the best way to kill a brand in our opinion. We believe in growth, but not that a number like “attendees” has anything to do with growth. We aim at 250 people max per conference and grow in quality from there. We will never have 2.000 attendees but will have the best sessions available. As for the nerds part, the group photo was taken at 13:37 time.

We succeed in all of these rules last year. All but one. Despite the fact that one sponsor went belly up and did not pay our fiscal agency, the Drupal Association (thanks!), we still made money. And thereby did not give the maximum value for our attendees.

Or did we? If you look at this blog by friend Baris Frontend-United was awesome or at the blog of the king it looks we succeeed in givin the attendees the best con ever! It was great to hear jan Willem Tulp talk about data visualization and the story of how Jeroen Wijering sold his a license for his video player to YouTube for $25 is still great to hear. No matter what your question was (“$25 per server? Client? Month?”) his answer would be $25.

Here are some snapshots of the money we made with sales and the hat-round, the venue “Pakhuis de Zwijger”, the banner with the sponsors, the excellent t-shirt with the infamous astronaut and the drinking venue with the Druplicon as a logo.

So far for 2012. On with 2013. With the help of a great all-female team in the UK, we are pulling the best Drupal conference of once again, backed by the Drupal Association (thanks), in London, 13 and 14 of April, in Cargo. Ticket sales will start shortly, great keynote speakers are already lined up but we need you as a speaker and as a sponsor! So please earmark the date in your agenda, think about an inspiring talk Frontend related and download the attached sponsor brochure. And mail we if you are interested in sponsoring, bert AT boerland DOT com.

Now lets rock London!

Ever since node 4877 in 2003 we have a “prediction” post up on drupal.org where Drupal coder and users can share their vision on what will happen the year ahead with their beloved tool. Ever? Well, we skipped last year on drupal.org. so we can not look back to the predictions you made last year on this site.

But that should not stop you to make new some new predictions. And you welcome to do so in the comments on the posting on d.o.

Will parts of Drupal end up in another CMS or framework? Will “WSCCI first” be the slogan? Or will the consolidation in the CMS landscape and the trend to leave our small island make new bridges towards other PHP projects or even make a new Pangaea, beyond PHP and the web? Will Drupal be the answer in Jeopardy on the question “what is the best CMS?”. Time will tell. Or you.. In the comments on the prediction 2013 posting.

Today, it is 614 weeks ago that Drupal 1.0 has been released, 4.295 days in the past, or 103.080 hours ago. During this time period, the Drupal community released 14 major versions, from 1.0 to 7.0. The new release is planned around mid august 2013 and hence will be the 15th major release. For those less in to the history of Drupal releases but can count and think that 8.0 as the 15th major release doest add up, it doesn't. Between 4.0 and 5.0 we spend 5 years releasing 4.1 up to 4.7, in our numbering scheme back then major releases.

During all these versions the Drupal community supported the current version and the version before. So with 7 being the current major release, we also support the 6 release that first saw the light of day on 13 february 2008 and will continue to do so up to around 15th of august 2013. Work on Drupal 6 started around december 2006, six and a half years ago by the time Drupal 8 will be released.

During all these versions the Drupal community had a no backwards compatibility philosophy. Modules that work in version 6 will not work in version 7. So for many of the thousands of modules we host on Drupal.org we have a stable and a development release for version 6 of Drupal and for version 7.

Today is also the day that people are using SaaS for all kinds of services. People and companies rely on the Google mail and experience a new version of this product on a daily basis, even without knowing it or seeing the difference cosmetically. Today people have hundreds of apps installed on their tablets and phones and upgrade those on a weekly or even daily basis at a touch of a finger.

Today is also the day that a manufacturer like Apple releases new major OS versions every year at extremely low prices and with a low barriers when it comes to the upgrade pain. Ubuntu -a leading Linux distribution package company- releases new versions of their product time boxed, complete predictable. Every 6 month users have the latest supported Linux distribution available and can update and upgrade with great ease.

I often explained Drupal’s lack of backwards compatibility towards users and customers as “Breaking with yesterday, building tomorrow”. Comparing it to Windows 7 that contains code of Windows XP, windows ME, Windows 95, Windows 3.11 and even all the way up to emulating code of MS-DOS 6.2. In order to move forward, we break with supporting the past unlike that product of Microsoft. Where Microsoft had to put every piece of history in its backpack when stepping forwards and carry all the weight of the history around towards the future, the Drupal community could break with yesterdays code and API’s and jump towards a brand new tomorrow.

Today I have problems saying so. Microsoft isn't the dominant example anymore and as stated, the competitors like Google, Apple and Linux are moving towards a “real time” experience of their products where users can enjoy the tools of today that have been build for them today on technologies available today.

With this in mind, it is good to look back at Dries’ last talk during the most excellent DrupalCon Munich. In a small room that was completely packed, Dries hinted around on what Drupal might be in the future. As always, he choose his words wisely and made sure what he said could be a thought experiment and might or might not happen, no promises no demands.

One of the things Dries hinted at that not many people seem to have picked up on, was that Drupal should be shortening it’s release cycles, towards for example half a year. And when you shorten your release cycle like that, you have to make sure that upgrades are cheap. Meaning you must stop our mantra of breaking compatibility between major versions. I do think that a new way of looking at our releases (what) and cycles (when) is more then needed.

Today planning and sticking to the plan is just as hard as it was yesterday. And hence even when we aim at an 18 month release cycle we end up with twice the amount in a code slush. Note though that even the18 month was derived from looking at the past, like steering a car by looking rearview mirror. It is possible, but assumes conditions remain constant.

While we know that the Ceteris Paribus world is not real, the world is continuously changing and the constant being that people constantly say that the change is only going faster. And in fact, even if the conditions in the future are the same, fact is that we as a community are in the risk of being overtaken by the past, proprietary CMS-es and other open source CMS-es that have been looking up towards us up to now.

Today I don't know what the answer is for the best release date of Drupal 9 and higher. But I do know that the current release cycles are breaking us up. I have seen very talented frontend designers quit Drupal because they didnt want to work anymore with outdates templates systems or jQuery versions. But, didn’t they want to “scratch their own itch?”. Sure they did, they just scratched it on another place, not in Drupal. I think Dries and others know that something has to change, I do not know the answer, but I would welcome a timeboxed (half a year) cycle and 3 older versions supported with backwards compatibility. Or an Long Term Support version next to more cutting edge version. Or something Dries will come up with on the next month.