Since then, a lot has happened to the online world. Google Chrome’s market share has gone up from about 12% to more than 35% (depending on which statistic you trust). Apart from the endangered species of Opera, no other browser has added WebP support so far. Firefox has had two entries in the Mozilla bug tracking system, each filled with toxic levels of emotion and opinion, rather than facts and – more importantly – code. There is some indication that WebP support for Firefox is closer than it was in 2010.

Also, WebP has changed a lot. There is now support for lossless compression, there is alpha channel support, more metadata and animated images. WebP no longer presents itself as a suitable replacement for JPEG but also for GIF, PNG and a series of lossless image formats.

Support for WebP in Wikipedia/Wikimedia Commons remains confined to experiments, there are three open feature requests in the Wikimedia bug tracking system.

Wikimedia hero Magnus Maske has implemented an experiment on the Wikimedia Toolserver that serves out thumbnails both as WebP files and embeds them as Data URIs within the HTML code of the Wikipedia article (see for yourself).

30 months later, there is a set of impressive improvements that each warrant having another closer look at WebP.

Auf dem Höhepunkt der (inzwischen öffentlichen) Diskussion über das MAI kommt dann die Wirtschaft nochmal auf Hochtouren und versucht zu retten, was zu retten ist. Dazu gehört auch eine Stellungnahme der Welthandelskammer von 1998, die auf eine gewisse Weise zeitlos ist (Auszug):

ICC recognizes how societies are changing, with citizens speaking up and expressing their deep-felt concerns. However, in some respects, the emergence of activist pressure groups risks weakening the effectiveness of public rules, legitimate institutions and democratic processes. These organizations should place emphasis on legitimizing themselves, improving their internal democracy, transparency and accountability. They should assume full responsibility for the consequences of their activities. Where this does not take place, rules establishing their rights and responsibilities should be considered.

Die ICC anerkennt, wie Gesellschaften sich wandeln und wie Bürger sich zu Wort melden und ihre tiefsitzenden Sorgen ausdrücken. allerdings, in einigen Fällen schwächt der Aufstieg von aktivistischen Protestgruppen die Effektivität öffentlicher Gesetze, legitimer Institutionen und des demokratischen Preozesses. Diese Organisationen sollten ihr Augenmerk darauf legen, sich zu legitimieren und ihre interne Demokratie, Transparenz und Rechenschaftswesen zu verbessern. Sie sollten volle Verwantwortung über die Konsequenzen ihrer Handlungen übernehmen. Wo dies nicht der Fall ist, sollte man überlegen Regeln einzuführen, die ihre Rechte und Pflichten darlegen.

Warum zitiere ich diesen Text? Weil einige Verbände offenbar in 15 Jahren nichts aus dem MAI, seinem Scheitern und den Folgen gelernt haben. Beispiel gefällig? Bitte.

Please support ACTA for the good of Europe
Over the past two weeks, we have seen coordinated attacks on democratic institutions such as the European Parliament and national governments over ACTA. The signatories to this letter and their members stand against such attempts to silence the democratic process.

Bitte unterstützt ACTA zum Wohle Europas
In den letzten zwei Wochen haben wir wegen ACTA koordinierte Angriffe auf demokratische Institutionen wie das Europäische Parlament und nationale Regierungen gesehen. Die Unterzeichner dieses Briefes und ihre Mitglieder stehen gegen solche Versuche, den demokratischen Prozess zum Schweigen zu bringen.

Die Contentindustrie kam zumindest am 10. Februar 2012 nicht damit klar, dass auch einmal jemand anderes als sie selbst zum Thema Urheberrecht den Mund aufmacht. Logisch, dass dies als Angriff auf die Demokratie gewertet werden muss.

Nicht-Berliner können jetzt einmal weglesen, ebenso alle, die entweder nicht wählen dürfen oder schon briefgewählt haben.

Noch da? Fein.

In diesem Blogposting möchte ich ein paar Gründe nennen, wieso meine Wahlempfehlung lautet, wie sie lautet.

Wikimedia Deutschland e.V. – mein Arbeitgeber – hat im Juli an alle kandidierenden Parteien eine Liste mit 30 Wahlprüfsteinen verschickt, die wohlwollend alle im Internet geboren zumindest entfernten netzpolitischen Bezug haben. Innerhalb der gesetzten Frist (Ende August) haben und alle im aktuellen Parlament vertretenen Parteien sowie Piraten, PSG und Tierschutzpartei geantwortet. Ich empfehle weiterhin die konsolidierte Fassung aller eingegangenen Antworten.

Einige der Fragen haben eine gewisse Grundhaltung schon vorweggenommen, andere waren nur von jenen Parteien beantwortbar, die schon in Parlamenten vertreten sind oder schon Regierungsverantwortung übernommen haben. Krasser Aussenseiter bei den Antworten war in der Regel die CDU, die als einzige Partei weiterhin Netzsperren befürwortet, sich nicht zugunsten von Panoramafreiheit äußern möchte, Netzneutralität bei der Einführung von Güteklassen gewahrt sieht und weiterhin sich beim Thema Presseverlegerleistungsschutzrecht ziehen lässt. Bei einigen Themen leistete die FDP ihr Gesellschaft, in einigen wenigen Fällen kam von der FDP eine sehr souveräne Abneigung gegen alles Staatliche zum Vorschein, die in den Bereichen Open Access, Gebühren für Open Government Data, Rundfunk zu einer bemerkenswerten Minderheitenposition führt.

Von vier der fünf Parteien, die vermutlich dem nächsten Abgeordnetenhaus angehören werden – SPD, Grüne, Partei die Linke, Piraten – haben wir Antworten bekommen, die mehr Gemeinsames als Trennendes besitzen. Ja, die unterschiedliche Herleitung, die sprachliche Präzision, der unbedingte Wille zu einer klaren Position ohne Einpreisung von bereits erfolgten Kompromissen, das sorgt für Abzüge oder Pluspunkte in der B-Note. Dennoch gilt im Großen und Ganzen:

1. Es gibt in der nächsten Legislaturperiode des Abgeordnetenhauses eine Situation, in der vier von fünf Fraktionen mit plusminus 75% der Sitze im Wahlkampf so etwas wie einen netzpolitischen Grundkonsens erzielt haben.
2. Wenn man die SPD als Wackelkandidaten für diesen Konsens betrachtet, sind wir weiterhin in der Nachbarschaft zu einer Mehrheit.
3. Eine Regierungskoalition ohne wenigstens einen netzpolitisch vernünftig eingenordeten Partner ist derzeit nicht in Aussicht.

Ich kann mich an keine Wahl in Deutschland erinnern, bei der dies schonmal der Fall gewesen sein sollte.

Das bedeutet umgekehrt, dass in der nächsten Legislaturperiode für alle landespolitischen Themen des Netzes und des freien Zuganges zu Informationen das Opportunitätsfenster schlechthin offen ist. Als Bonus gäbe es noch ein solides Veto für alle konsensualen Entscheidungen unter den Ländern, wenn jemand mal wieder einen Glücksspielstaatsvertrag für den Aufbau einer Sperrinfrastruktur nutzen will.

Ein paar Eindrücke aus dem Wahlkampf machen dieses an sich rosige Bild wieder kaputt. Einer davon ist Renate Künast, die bei mir bei zweieinhalb Gelegenheiten bewiesen hat, wie wenig sie das Thema interessiert, wie wenig sie auf Ratschläge dazu reagiert und wie wenig es ihr ausmacht, diese Unlust offen zu zeigen. Kann sein, dass mein negativer Eindruck von ihrer – standesgemäß nicht selbst geschriebenen Rede – auch deshalb negativ war, weil ich noch verzaubert war von dem großartigen Beitrag der designierten Verfasssungsrichterin Susanne Baer nebendran auf dem gleichen Kongress. Andere – unverzauberte – Kollegen haben ebenfalls keine Rede von Renate erlebt, auf der sie netzpolitisch irgendwas gerissen hätte.

Renate bennent sich auf ihrer Webseite weiterhin “Kandidatin für das Amt der Regierenden Bürgermeisterin von Berlin”. Ob das irgendwann mal realistisch oder vernünftig war, ist mir egal, heute wirkt es aber eher surreal. Sofern sie in den letzten Tagen indirekt zu Verstehen gegeben hat, dass sie diese Idee nicht weiter verfolgt für 2011, super. Die Grünen werden von 13,1% am 17. September 2006 auf irgendeine Zahl zwischen 18 und 21% springen und sind gut beraten, dies als uneingeschränkten Erfolg zu werten und zu verkaufen. Vermutlich wird es Platz 3 werden, aber hey, was für eine Relevanz wird das noch haben? Die grüne Fraktion wird deutlich größer werden und wird ihre Arbeit entweder als fähige Opposition oder als Juniorpartner einer Koalition fortsetzen können.

Die Linke bemüht sich um netzpolitische Glaubwürdigkeit, im Bund und auch in den Ländern, mit dem absehbaren Ende einer rot-roten Mehrheit sehe ich auch hier keinen Grund für eine Wahlempfehlung.

Und dann noch die Piraten. Eine Partei, in der man seine eigene Unsortiertheit wiedererkennt, die Selbstironie, die man gerne hätte und den Spieltrieb, der schon immer der erste Grund für Großartiges war. Im Moment sind sie Taktgeber in netzpolitischen Debatten, ich warte auf denjenigen, der mir erklärt, dass wir auch dann heute schon ein http://daten.berlin.de hätten, wenn nicht zusätzlich zu den vielen Gründen, warum das gut ist, auch noch das Bedürfnismanagement der Piraten für Transparenz, Offenheit und Maschinenlesbarkeit der Regierung gekommen wäre. Egal, was sie zu den Lücken im eigenen Parteiprogramm sagen, die Piraten deklinieren gerade ihr Staatsverständnis auf andere Bereiche des öffentlichen und privaten Lebens durch und werden zur links-liberal-libertären Partei mit Vollprogramm. Fine with me.

Es gibt Momente, wo die Wahl mit dem Herzen weniger schlimm ist als sonst. Wenn es wichtig wäre, dem netzaffinen Zwilling von Renate noch die letzten Prozentpünktchen zu geben, um Berlin vor einem Regierenden Bürgermeister Uhl zu schützen, ja dann. Wenn es wichtig wäre, nicht nur ein Statement auf dem Stimmzettel für eine quirlige aber chancenlose Partei zu machen, sondern auch die konkreten Mehrheitsverhältnisse im kommenden Parlament für die nächsten fünf Jahre herumzureissen, dann ja, dann hätte eine Kopfentscheidung freie Fahrt.

Dies ist ein solcher Moment für Herzensangelegenheiten. Am Sonntag wird jeder, der sich mit den formulierten Zielen (und dem, was noch irgendwann zu Papier und Etherpad gebracht werden wird) der Piraten identifizieren kann, sein Kreuz auf dem Stimmzettel bei der Piratenpartei machen können. Wer in Wahlbezirken mit vorzeigbaren Grünen ist, hat noch eine Erststimme für einen guten Zweck frei und wer die Grünen für eine an sich gute Arbeit in den letzten Jahren und einem brauchbaren Konzept für die nächsten fünf mit seiner Zweitstimme belohnen will, fährt auch richtig.

Kohärentere Wahlempfehlungen gibt es bei Spreeblick und bei wirres.net.

(und sagt nicht, dass ihr keine Warnung bekamt, wie viele Dramen es geben wird und wie anstrengend und kleinteilig und kompromissbeladen alles werden wird)

The proposal I want to make has all the qualities of a win-win-win situation.

a) Mubarak could stay in power of “Egypt”

b) Egyptian people could have real elections and pick whoever they like

c) The United Arab Emirates could re-use some of their currently dormant projects.

Of course, I am talking about making Mubarak the ruler of the island “Egypt” on the artificial archipelago “The World” right off the coast of Dubai.

a) Why should I store my images as WebP if no-one else and most web browsers won’t be able to display it?

b) Why should my software support WebP if no-one stores images in this format?

In order to break the circle, you rely on enthusiasts or you create smaller scenarios in which both sides of the problem are dealt with directly. Some of the enthusiasts have already started working and there is a growing number of programs or similar that can read or write WebP files. For the remaining part, it is now entirely up to Google to demonstrate its commitment to WebP, at least as a secondary lossy file format. The opportunities to deploy WebP are obvious and have been discussed already at other places:

1. Display WebP

Google is the manufacturer of the Google Chrome web browser, only two years old but already among the four largest browsers (depending on which statistics you forge). According to the public bug tracking system, WebP support is scheduled for the upcoming version 9 of Google Chrome. Very short from now, the first canary build or developer channel versions of 9.0 will be deployed to the user base, hopefully with WebP support enabled. This will actually be the first more or less convenient way to display the images after all. No more converting to PNG. Given the current pace of Chrome developement (and Google’s willingness to increment the version number faster than other people say M-S-I-E-Nine), we can expect a stable version 9 around new year, give or take a few months. So even without any support from other browser vendors, 1 in 10 web users will be able to display WebP images without any further tool to install. That’s a good start for deployment.

WebP is meant to be small and my early peek at its performance tells me this is promise they can keep. The everyday scenario in which size is usually most important is accessing the web via your smartphone from a crappy 3G network. And again, Google has its own software platform, Google Android. It is entirely up to Google to add WebP support to Android so that at least newer smartphone could access it. We might see WebM support for Android soon, so the library would already be there.

With Google Picasa, there is also a classic application, installed locally on the machine of the user. Support for WebP (both read and write) will help promote this file format. And Picasa.

2 Serve WebP images whenever possible.

If you look at a gallery of images at Picasaweb, you simply don’t care about the original file format and the method of transportation for looking at the thumbnails or the gallery as long as it’s fast. Google could replace JPEG with WebP images whenever the Browser indicates support for this image format. It could indicate the WebP usage with a tiny little icon in some corner. There is a precedence for both, the support for “HTML5+WebM” at Youtube.

3. Lower the hurdle

Most People will play with something if it does not involve installation of cygwin, downloading new packages and compiling your own webpconv converter tool.  Most people would enjoy a simple drag-drop file uploader that outputs a WebP file and offers a few sliders for quality adjustment. Google did the right thing in offering its comparisons in a file format other browsers could understand but there is much much more possible.

4. Promote it the way a image file format can be promoted

I note that google.com does not yet offer content in WebP where it would be possible. Where is the effort to offer .webp files at http://www.google.com/press/images.html next to the jpeg ones? I am willing to assume that many Apple Quicktime installations only happened because someone wanted to look at a movie trailer in Full HD. Someone at Google might do the calculation and see if a web site for Boston Globe’s “the big picture” in “HD” or some excellent flickr content or any other “news in pictures” stream might be worth the money and/or effort spent. Ask Canon to offer a special firmware to the Canon EOS 1Ds or 5D that produces .webp files already.

As a result of this conversation, there is now one more feature request in Wikimedia’s bug tracking system: Bug 25611: Support optimized WebP thumbnails as alternative to JPEG

If you access a Wikipedia page, you are likely to see images in the article. Usually, these images are coming from Wikimedia Commons and we encourage people to upload these images in a high resolution. Thanks to the MediaWiki syntax, it is rather easy to adjust the image size via the thumbnail parameter.

The file format of thumbnails depends on the file format of the original image. JPEG and TIFF images are thumbnailed as JPEG, SVG and PNG are downsized to PNG files.

If you access a rather large Wikipedia articles, the size of the thumbnails will reach a single digit Megabyte level, for example the current version of the German language article on Germany.

Size of the Article "Germany" at de.wikipedia.org

If a single Wikipedia article (and not even the largest one) is 3.67 MB large and 2.7 MB of it are images, a reduction in size would make a difference to the readership where the bottleneck is bandwidth. In the case of the article on Germany, a larger part of the images are in PNG format. By the way, the screenshot is taken from Google Chrome’s developer tools, a great way to see what is going on between a web site and your browser.

For the purpose of a small experiment, I picked the article on Albrecht Dürer in the English language Wikipedia.

Total size of the article (including stylesheets and website logo and icons): 892.74 KB
Size of images: 352.51 KB.

Text compression will turn a 126.53 KB html file into 33.05 KB.

Several .js and .css files with slightly above 400 KB should remain in the browser cache if you have accessed Wikipedia before. Therefor, if you are a non-first time Wikipedia visitor, the thumbnails of the article will easily be the by far largest chunk of data you will have to download.

In this example, there are 18 JPEG thumbnails ranging from 5122 to 28788 Bytes. The image size ranges from 100*146 to 220*343 Pixels. In the current compression, Bytes-per-pixel starts at 1,42 and ends at 5,03.

All images were available at Wikimedia in a higher resolution from slightly-above-thumbnail (311*485) to reasonably-large (2192*2831).

The original thumbnail (13.586 Bytes)

In my test, I will load the original files and convert them to BMP files of the size of the thumbnails. I will convert these files to .webp using whatever quality the webpconv will pick and additionally at a quality setting that I consider to be still useful.

The quality parameter used by webpconv itself was always between 81 and 85, resulting in 18 files that sum up to 350 KB – 26 KB larger than the sum of the JPEG thumbnails created by the MediaWiki software.

With quality 50, I end up at 181 KB, 44% smaller than the JPEG image set.

WebP auto setting: 9.641 Bytes

With quality 20, we end up with a severe reduction in visual quality and a total size of 75,8 KB. Several images are distorted almost beyond recognition, others still serve the purpose of a thumbnail perfectly fine. If the purpose was a reduction of size of 50%, a quality setting of 45 would fit. In any way, the comparison is not entirely possible in my comparison since I did not use any image manipulation other than image size reduction and compression. Best of my knowledge, MediaWiki’s software tools apply contrast and sharpness adjustments during the thumbnailing process.

WebP at quality 50: 4.163 Bytes (a.k.a "your hair is gone")

I am going to end this post with a series of thumbnails both in the original thumbnail version and various stages of WebP compression. Since your browser is most likely unable to display .webp files directly, I converted the images to .png in a lossless manner.

WebP at Q=20 : 1.367 Bytes (a.k.a. "the entire Dürer gone")

In order to give a recommendation on WebP, you have to keep in mind the purpose of a thumbnail: A quick impression on the content of an image. You have to see what is in the image, you don’t have to see every tiny detail of it. Anyone who wants to see more can click on the image and look at the (hopefully larger) image without further compression and resizing. WebP at q=50 manages this job quite well with an impressive reduction in size. Keeping in mind that thumbnails are ususally the largest part of a new Wikipedia site (if you have already the css and js stuff in your browser cache), a size reduction here would severely affect the total size of a page. Contrast and Sharpening could also be applied here and might improve the visual quality as perceived by its users.

I welcome your feedback.

WebP offers compression that has shown 39.8% more byte-size efficiency than JPEG for the same quality in a large scale study of 900,000 images on the Web.

Some description about the study can be found at Google.com. There is also a gallery with a couple of images taken from the media repository Wikimedia Commons. Since Google has released the tool to create .webp images, I was able to conduct some tests on my own.

Elke Twesten, member of the state parliament of Lower Saxony, Germany

I did not want to pollute my test with an image that had already been compressed in a lossy format before. Since my camera can output both JPEG and CR2 (canon raw) files, I could use one of the RAW images and convert them to a nice 61 MByte large image, 5616 * 3744 pixel in size. The first image was a portrait image of a German politician, Elke Twesten from the state parliament of Lower Saxony. A JPEG version of an image of this series can be found at Wikimedia Commons under a Creative Commons license. Since I used a flash for this image, the quality of the image is reasonably good for comparison purposes and some features of the image, such as hair and the eye can potentially reveal some strengths and weaknesses of the codecs.

I also produced a 1600 pixel and a 640 pixel wide version of the image, since most use cases in the web will not require images with more than 5000*3000 pixels. So for this first run, I end up with three files:

1. twesten-5616.bmp – 63.078.966 Bytes – md5: b5ce657dc865adc9c16cf1d05d120681
2. twesten-1600.bmp – 5.116.854 Bytes – md5: eba526672acb7261b2b3112376ace55a
3. twesten-0640.bmp – 817.974 Bytes - md5: a68aae497299976254142f00be483c45

The webpconv converter tool allows to add a quality parameter ranging from 0 to 100. As the number increases, so does the size of the image and hopefully the quality, too.

Image size of the three twesten images depending on quality parameter

Right now, there is no software available to display .webp files directly. Google Chrome might be getting support for this file format soon, based on the changes in the SVN.

So in order to make easy comparisons, I went ahead and converted the WebP files back to PNG, not adding additional compression artifacts.

The conversion from .bmp to .jpg was done via ImageMagick 6.4.0 with just the quality setting adjusted from 1 to 100. The relationship between quality parameter setting and size is a bit different, please note that the y-axis is already using a logarithmic scale.

JPEG size with the three twesten images depending on the quality parameter setting.

So we basically end up with three times 100 pairs of images, one in JPEG, one in WebP each. Since the quality parameter is not something that can be directly compared to between these formats, there are two approaches for comparison:

1. Compare the size of two images with the same visual quality.
2. Compare the visual quality of two images with the same size.

While size is something that can be measured and reasonably be expressed in a single number, quality is in the eye of the beholder. The twesten-0640 images in JPEG range from 2.303 Bytes to 188.898 Bytes, the WebP images range from 1.552 Bytes to 46.638 Bytes. For the range between 2.303 to 46.638 Bytes, there are two reasonably similar files in each format available.

Let’s start with the smallest one: twesten-0640-q13.webp (2303 Bytes) vs twesten-0640-q1.jpeg:

Twesten-0640 at JPEG with quality 1: 2303 Bytes

Twesten 0640 at Webp-Quality 13: 2303 Bytes

Both images do not even remotely qualify as high quality but it is impressive to see how far both images are apart.

The next pair I picked was WebP-q39 with 5736 Bytes and JPEG-q17 with 5754 Bytes respectively.

JPEG Q:17 / Size: 5754 Bytes

WebP Q:39 / Size:5736 Bytes

I still feel confident to declare WebP a winner in this comparison, the quality in the WebP image has now reached a point that no longer causes eye cancer. It is my personal impression that WebP is able to keep the distance to JPEG, a format that is now more than 20 years old.

If anyone thinks there are jpeg converters out there who can produce less terrible results, please let me know. I am more than happy to make my original files available to anyone under a very permissive license term (CC-by or CC-by-sa).

Or you can simply download the twesten-1600.bmp file here.

If you think the image itself was particularly unfair to one format, feel free to release different images (as uncompressed as possible) to allow others to compare their findings. I would love to see a web application where you can upload uncompressed images and receive a selection of JPEG, JPEG2K, JPEG XR and WebP compressed versions in various qualities and sizes.

As Brion rightfully noted, the examples I gave in this post so far are far from realistic, unless you really want to squeeze every bit. When bandwidth is measured in Megabits per second, there is little reason to settle below a certain minimum standard of visual quality, so I would like to give some examples from the upper third.

The Twesten-1600 image starts at 6.647 Bytes (q:0) when compressed with WebP and it ends at 246.970 Bytes (q:100). JPEG is a different beast with q1= 11.733 Bytes to q100=1.125.070 Bytes. I am going to show parts of the images at 400%.

Uncompressed BMP at 400%

JPEG at q=70 / 88912 Bytes / 400%

WebP at q=80 / 77551 Bytes

While being 13% smaller, the visual impression of the WebP image is still better than with JPEG, where artifacts are clearly visible. WebP seems to cover some of these artifacts up by a rather aggressive blurring, detailed structures still survive this process.

So langsam sickert Flattr auch bei Wikipedia rein, beispielsweise in den Upload-Kommentaren beim Medienrepository Wikimedia Commons:

Wäre es also nicht irgendwie naheliegend, wenn Wikipedia unter jeden Wikipedia-Artikel einen Flattr-Button packen würde? Folgende Gedanken schiessen mir zuerst – unsortiert und definitiv in irgendeiner Reihenfolge – in den Kopf:

1. Privatsphäre: Wikipedia-Besucher sollen davon ausgehen können, dass die Privacy-Policy der Foundation eingehalten wird. Ein dynamisches Einbinden von Flattr-Buttons von einem von der Foundation unkontrollierten Flattr-Server scheidet also aus, weil dann ein Bewegungsprofil der Wikipedia-Leser entsteht, das grundsätzlich abgeschnorchelt werden kann.
2. Kollaboration: Wem stehen Flattr-Gelder für einen Artikel zu, wenn an ihm 200 Autoren mitgeschrieben habe und man es so einrichten will, dass nicht die Wikimedia Foundation das Geld erhalten soll?
3. Kannibalisierung: Klickquoten von 30 Eurocent pro Flattr sind ziemlich gut, aber liegen weit unter der durchschnittlichen Spendenhöhe für Wikimedia. Würde ein Flattr-Button einen Einbruch der Gesamtspendenhöhe an die Foundation bedeuten, wenn man es so einrichten will, dass die Wikimedia Foundation das Geld erhalten soll?
4. Accounts: Wie viele der monatlich 300 Millionen Wikipedia-Leser haben einen Flattr-Account und wie viele könnten, wenn sie daran Interesse hätten, sich bequem einen besorgen, solange Flattr noch im Einladungs-Modus ist?
5. Kommission: Mit 10% Kommission ist Flattr eher auf der ungünstigen Seite der Finanztransaktionssysteme, auch wenn die Vergleichbarkeit natürlich hinkt.