Corporate Social Responsibility and using Open Source

A star in a network
It may differ per country and continent, but for most of the regions I know of, Corporate Social Responsibility (CSR) has become a standard within corporations as a way of buying, selling and producing goods and services. We all know that resources are scarce and hence should be used for the best possible use and more important, reused when possible.

By reusing resources to produce new goods or services, we make optimal use of that what is there. This is no longer a “left" or “green" political statement but is being executed by all parties in the political and economical arena, simply because it is in the interest of the person doing so as well as all other persons. It makes economical sense to reuse resources, be good for persons, the community and the environment. Even if it was just for the tragedy of the commons or from a prioner’s dilemma point of view. For those interested in how doing good or bad impacts the group, this academic PDF might be a good start. If you master Dutch this TED quality keynote during a DrupalJam conference of my friend Yoast on vimeo is truly something to watch.

Garden city of to-morrow

So it is my opinion that CSR has moved beyond empty platitudes and has become truly in the genes of people and companies. Many people think that CSR started as corporate philanthropy, a way of the rich to donate to the poor. I don't think this is true, in every revolution, there have been powers to do good for the environment, the people and the community. For example during the Industrial Revolution there was a very strong new socialism trend with taking care of the housing, commnities and villages of the workers, “The garden cities of to-morrow". Not because “the Rich" want to do good perse (“philanthropy"), but because it made sense economically; less death and diseases (less risk) and a richer and happier workforce (and new business models around this growth).

Urban gardening

Most of the definitions I have seen of CSR have in common that it is an integral vision towards sustainable business with social responsibility in business decisions to balance the social and economic impact of the decision. That by itself is an excellent definition and one that will be supported by anyone who is been doing business. The implementation most see however is to have a policy on carbon footprint in a company or to only buy agricultural products that are produced in a sustainable way, without pesticides. All fine.

But it seems that there is a very easy way to have implementation of CSR: by using a product that is produced to be be reused, made with the knowledge of thousands and with target audience of the world. The product that is not wasting a single second of the future and not wasting a drop of the paste. Indeed, I am talking about using open source software (OSS)!
OSS is by definition made with CSR in mind, it is being produced by different people all over the globe to be reused for you and your knowledge will be direct input for making the product better, iterate on the development and implementation.

And hence, a company that is using open source has a sustainable competitive advantage by using valuable rare resource in the most optima form. Therefor I dare any company that is using software to produce goods, to take using open source software into account and into its’ Corporate Social Responsibility policy. For by using open source software, we can truly make a better world by using more knowledge and less resources.

A very healthy situation for any company.


PS: if you want more information on this vison, do visit the 12 Best Practices from Wunderkraut session at the DrupalCon Amsterdam. Or visit Wunderkraut at booth number 1 in the sponsor lounge, right by the coffee! We are part of the community that uses and make open source software. With passion.

An old (but not dated) presentation on why Drupal is "so slow" hitting 7k views :-)

An old (but not dated) presentation I did for a PHP meetup on how to get Drupal to perform better. Still valid. Watch it if you are in to Drupal, webperf and checkout as well.

Want accessability geldt enkel voor websites (niet voor brochures, brievenbussen of HTML mail)

maar als het om mail of offline uitingen gaat, kijkt niemand naar accesability

Ik ben voor een open web. Voor toeganglijke websites. En oprecht van mening dat zeker elke overheids site daaraan moet voldoen. Maar als het om offline zaken als brochures gaat, dan kijkt niemand naar kleurstelling. Leesbaarheid. Of dat blinden ook de brochre teksten kunnen verkrijgen. Want dat is geen doel, daar zijn geen badges voor.

Of bijvoorbeeld mail. Hier een voorbeeld van gemeente Amsterdam, maar geldt voor *elke* nieuwsbrief. Mailclients zijn namelijk niet gemaakt om HTML mail te lezen. Je kan natuurlijk gewoon plain text mail versturen. Zonder plaatje tracker die ziet wanneer ik welke mail waar en hoe laat open. Maar dat wil je niet.

  1. Vele accesability mannen (m/v) gaan enkel voor websites, of een brochure van een gemeente leesbaar is voor kleurenblinden, de tekst beschikbaar voor blinden, de brievenbus benaderbaar is vanaf de rolstoel, daar zijn geen badges voor en dus niet van belang
  2. HTML mail is ondergeschoven. Niemand kijkt naar afschuwlijke HTML laat staan dat de default leesbare plain/text zou zijn
  3. Plaatjes uit de mail gven zijn allemaal voorzien van tracking cookies. Hoe laat ik mijn mai open, wel of niet de nieuwsbrief lees, mijn browsersie... en alles zonder opt in of uit. "Cookie wet" anyone?

... stilte....

SPDY and webperformance

Robert M. White

  1. Performance matter for all websites
  2. Performance is not just (80%) frontend
  3. SPDY kills 80% of your frontend problems

In the Drupal and broader web community, there is a lot of attention towards the performance of websites.

While "performance" is a very complex topic on its' own, let us in this posting define it as the speed of the website and the process to optimize the speed of the website (or better broader, the experience of the speed by the user as performance.

This attention towards speed is for two good reasons. On one hand we have the site that is getting bigger and hence slower. The databases get bigger with more content and the the codebase of the website is added with new modules and features. While on the other hand, more money is being made with websites for business even if you are not selling goods or run ads.

Given that most sites run on the same hardware for years, this results in slower websites, leading to a lower pagerank, less traffic, less pages per visit, lower conversion rates. And in the end, if you a have a business case for your website, lower profits. Bottemline: If you make money online, you are losing this due to a slow website.
When it comes to speed there are many parameters to take in to account, it is not "just" the average pageloading time. First of all the average is a rather useless metric without taking the standard deviation into account. But apart from that, it comes down to what a "page" is.

A page can be just the HTML file (can be done in 50ms)
A page can be the complete webpage with all the elements (for many sites around the 10seconds)
A page can be the complete webpage with all elements including third party content. Hint: did you know that for displaying the Facebook Like button, more Javascript is downloaded then the entire jQuery/backbone/bootstrap app of this website, non cacheable!
And a page can be anything "above the fold"

Moon Retro future
And then there are more interesting metrics then these, the time to first byte from a technologic point of view for example. But not just technical PoV. There is a website one visits every day that optimzes its' rendable HTML to fit within 1500 bytes.
So ranging from "First byte to glass" to "Round trip time", there are many elements to be taken into account when one measures the speed of a website. And that is the main point: webperformance is not just for the frontenders like many think, not just for the backenders like some of them hope, but for all the people who control elements elements in the chain involved in the speed. All the way down to the networking guys (m/f) in the basement (hint sysadmins: INITCWND has a huge performance impact!) Speed should be in your core of your team, not just in those who enable gzip compression, aggregate the Javascript or make the sprites.

Steve Souders (the webperformance guru) once stated in his golden rule that 80-90% of the end-user response time is spent on the frontend.

Speedy to the rescue?
This 80% might be matter of debate in the case of a logged in user in a CMS. But even if it is true. This 80% can be reduced by 80% with SPDY.
SPDY is an open protocol introduced by Google to overcome the problems with HTTP (up to 1.1 including pipeling, defined in 1999!) and the absence of HTTP/2.0. It speeds up HTTP by generating one connection between the client and the server for all the elements in the page served by the server. Orginally only build in chrome, many browsers now support this protocol that will be the base of HTTP/2.0. Think about it and read about it, a complete webpage with all the elements -regardless of minifying and sprites- served in one stream with only once the TCP handshake and one DNS request. Most of the rules of traditional webperf optimalisation (CSS aggregation, preloading, prefetching, offloading elements to different host, cookie free domains), all this wisedom is gone, even false, with one simple install. 80% of the 80% gone with SPDY, now one can focus on the hard part; the database, the codebase. :-)

The downside of SPDY is however that is is hard to troublshoot and not yet avaliable in all browsers. It is hard to troubleshoot since most implementations use SSL, the protocol is multiplexed and zipped by default and not made to be read by humans unlike HTTP/1.0. There are however some tools that make it possible to test SPDY but most if not all tools you use every day like ab, curl, wget will fail to use SPDY and fallback like defined in the protocol to HTTP/1.0

So can we test to see if SPDY is really faster and how much faster?
Yes, see Evaluating the Performance of SPDY-Enabled Web Servers (a Drupal site :-)
SPDY performance

So more users, less errors under load and a lower page load time. What is there not to like about SPDY?

That is why I would love to run with SPDY, see this issue on d.o/2046731. I really do hope that the infra team will find some time to test this and once accepted, install it on the production server.

Performance as a Service
One of the projects I have been active in later is ProjectPAAS, bonus point if you find the easteregg on the site :-) . ProjectPAAS is a startup that will test a Drupal site, measure on 100+ metrics, analyse the data and give the developer an opinionated report on what to change to get a better performance. If you like these images around the retro future theme, be sure to checkout the flickr page, like us on facebook, follow us on twitter but most of all, see the moodboard on pinterest

Pinterest itself is doing some good work when it comes to performance as well. Not just speed but also the perception of speed.

Pinterest lazyloading with color
Pinterest does lazyload images but also displays the prominent color as background in a cell before the image is loaded, giving the user a sense of what to come. For a background on this see webdistortion

Congratulations you just saved 0,4 seconds
If you are lazyloading images to give your user faster results, be sure to checkout this module we made; lazypaas, currently a sandbox project awaiting approval. It does extract the dominant (most used) color of an image and displays the box where the image will be placed with this color. And if you use it and did a code review, be sure to help it to get it to a real Drupal module.

From 80% to 100%
Lazyloading like this leads to better user experience. Because even when 80% of the end-user response time is spent on the frontend, 100% of the time is spend in the client, most ofthen the browser. The only place where performance should be measured and the only page where performance matters. Hence, all elements that deliver this speed should be optimized, including the webserver and the browser.

Now say this fast after me: SPDY FTW. :-)

XML feed