Follow my new blog

Samstag, 30. Mai 2009

Willen zur Softwarequalität bekunden – Erste CCD Commitments [OOP 2009]

Die YooApplications AG in Basel tut es. Und die G-TAC IT-Beratung tut es auch. Beide bekunden öffentlich ihren Willen zu mehr Softwarequalität durch Arbeit nach dem Clean Code Developer (CCD) Wertesystem (www.clean-code-developer.de):

image

image

Das finde ich sehr cool! Denn durch solch ein Zeichen verändert sich die Welt schon ein Kleinwenig zum Besseren. Ein Kunde hier, eine Kunde da stolpert darüber und merkt, dass man zu Softwarequalität überhaupt einen Willen haben kann. Dass es scheinbar irgendwie etwas Besonderes bzw. Unterscheidendes ist, seine Arbeitsweise herauszustellen. Dann fragt er nach, dann denkt er nach, dann sucht er hoffentlich ähnliche Hinweise auch bei anderen Softwareanbietern. Dann steigt hoffentlich sein Bewusstsein in Bezug auf die innere Qualität von Software. Dann will er hoffentlich in Zukunft nicht mehr weniger als Software, die dem CCD-Wertesystem entspricht.

Mutig finde ich diese Bekundung aber auch. Denn wenn solcher Wille erstmal öffentlich gemacht ist, kann einer daherkommen und nicht nur interessiert fragen, worum es denn bei CCD ginge, sondern am Ende womöglich mehr wissen wollen. Vielleicht möchte er die “Auswirkungen” von CCD-gemäßer Arbeitsweise gar “sehen”? Wer sich so zu CCD bekennt, kommt also nicht umhin, CCD auch zu leben. Nicht perfekt, aber stetig strebend sich bemühend. Selbst wenn das mal lästig sein mag. Man hat´s ja aber bekundet, dass man es tut. Also muss man der Bekundung auch Taten folgen lassen. Das wird nicht jedem schmecken – und so werden sich auch nie alle zu solch einem Commitment hinreißen lassen.

Meine Hoffnung ist jedoch, dass das Beispiel der beiden Unternehmen Schule macht. Jetzt sind es zwei, morgen vielleicht drei, dann 4, 5, dann 10 dann 50 Unternehmen oder Abteilungen, die aufstehen und in solcher Weise öffentlich machen, dass sie keine Lust mehr auf “Crap” (Schrott) haben, sondern Qualität produzieren wollen und können. Dann wird Nicolai Josuttis hoffentlich doch noch widerlegt.

Samstag, 23. Mai 2009

Auf ins Raumzeitalter! - Asynchron und verteilt mit dem Application Space

Software verteilen ist keine leichte Sache. Muss das so sein? Nein, ich glaube nicht. Wir machen es uns nur selbst unnötig schwer, indem wir immer wieder und weiter versuchen, in verteilten Systemen genauso zu kommunizieren, wie in lokalen. Corba, DCOM, .NET Remoting, Webservices, WCF: sie stehen alle in derselben Tradition. Sie alle favorisieren die synchrone, methodenbasierte Kommunikation zwischen entfernten Funktionseinheiten. Ihr Credo: Wenn service.TueEtwas() lokal der Ausdruck eines Servicewunsches ist, dann sollte das auch in verteilten Systemen so sein.

Bei aller Nachrichtenorientierung, in der inzwischen WCF angekommen ist, halte ich das jedoch für falsch. Darüber habe ich auch schon ausführlich hier im Blog geschrieben. Nur wie können wir es anders machen?

Klar, es gibt Alternativen. Es gibt Technologien für asynchrone, nachrichtenorientierte, event-driven Architekturen. MSMQ/System.Messaging gehört dazu und aufbauend darauf z.B.  Mass Transit oder NServiceBus. Von größeren und teureren Werkzeugen will ich gar nicht reden.

Trotz dieser Ansätze bin ich jedoch nicht zufrieden gewesen. Denn Messaging - obwohl das für die Verteilung  "ehrlichere" Konzept als der Methodenaufruf - ist irgendwie auch einschränkend und immer etwas schwergewichtig. Die Einschränkung liegt im Fokus auf den "Röhren" zwischen Funktionseinheiten. Die halte ich aber für einen Sonderfall. Und die Schwergewichtigkeit liegt im API. Messaging ist eben eng verbunden mit MSMQ. Und Messaging konzentriert sich auf die Verteilung.

Nun bin ich froh, sagen zu können, dass meine Zufriedenheit gerade sehr gestiegen ist. Denn ein Projekt, an dem ich schon einige Zeit beteiligt bin, trägt nun erstmalig öffentliche Früchte. Zusammen mit der TU Wien kann ich im Rahmen der Xcoordination Unternehmung (www.xcoordination.com) bekannt geben, dass wir die erste CTP unseres Xcoordination Application Space (AppSpace) bei CodePlex veröffentlicht haben: http://xcoappspace.codeplex.com.

Nach Vorversuchen und Andeutungen ist nun live, wovon wir meinen, dass es das Verteilen von Software sehr viel einfacher machen kann. Der AppSpace ist damit einerseits tatsächlich als Ersatz für z.B. WCF gedacht - auf der anderen Seite lieben wir aber auch WCF.

WCF ist cool. WCF ist breit und tief und universell. Das ist super! Aber wir glauben nicht, dass WCF einen API bietet, den der Durchschnittsentwickler direkt nutzen sollte, um seine Software zu verteilen. Der Preis für WCFs Mächtigkeit ist schlicht Komplexität und damit geringe Usability.

Der AppSpace verbirgt diese Komplexität nun. Er bietet aufbauend auf WCF und anderen Kommunikationstechnologien einen API für die lokale wie die verteilte asynchrone Programmierung. Er abstrahiert von den Feinheiten der WCF.

image

Wir meinen, dass damit ein Sprung in der Verteilung von Software geschafft werden kann wie vom Win16/Win32 API zu VB1.0. 1990 konnte man Windows programmieren - aber es war sauschwer, mit dem Windows API in C direkt umzugehen. Nur Experten konnten also das Potenzial graphischer Benutzerschnittstellen ausnutzen.

Dann kam VB1.0 und alles wurde anders. Mit VB1.0 konnten plötzlich Millionen von Entwicklern graphische Benutzerschnittstellen programmieren. Dazu mussten Sie zwar gegenüber den bisherigen umdenken - Stichwort "Event-Driven UI" -, aber das war nicht so schlimm.

Ähnlich sehen wir den AppSpace. (Ein bisschen Größenwahn kann nie schaden, oder? ;-) Mit dem Programmiermodell des AppSpace hoffen wir auch, die Verteilung von Code einer viel größeren Gruppe von Entwicklern zugänglich zu machen.

Dazu ist zwar auch ein Umdenken nötig - Stichwort "Asynchrone Kommunikation" -, aber das wird hoffentlich nicht so schlimm. Vor allem ist der Gewinn doppelt, wenn man sich auf diesen Paradigmenwechsel von synchron nach asynchon einlässt. Nicht nur wird die Verteilung einfacher, man bekommt auch noch die lokale Parallelverarbeitung gleich dazu.

Und warum soll nun der AppSpace der Bringer sein gegenüber anderen Messaging-Technologien? Weil sich der AppSpace eben nicht nur um Messaging dreht. Messaging ist für ihn ein Sonderfall. Oder Messaging passiert für ihn "unten drunter".

Das zentrale Konzept beim AppSpace sind vielmehr Dienstleistungskomponenten. Er bleibt also so dicht wie möglich an der Objektorientierung und der synchronen Komponentenorientierung. Deshalb bietet er auch eine DI Container Schnittstelle. Er holt die Entwickler da ab, wo sie heute stehen: bei den synchronen Komponenten. Und dann bietet er ihnen schrittweise mehr. Zuerst unterstützt er sie auf der Basis der Microsoft Concurrency Runtime dabei, von lokal synchron auf lokal asynchron umzusteigen. Und dann unterstützt er sie beim Umstieg von lokal asynchron zu entfernt asynchron.

Das halten wir für eine natürliche Progression im Denken und in der Codierung. Wer gelernt hat, lokal asynchron zu programmieren, der hat viel weniger Probleme, wenn es dann an die Verteilung von Code geht. Mit dem AppSpace bekommt er die Verteilung dann sozusagen geschenkt.

Für die, die nun ganz gespannt darauf sind, wie denn der API des AppSpace aussieht, hier ein Codeschnippsel. Mehr gibt es bei CodePlex und demnächst in der dotnetpro. Auch Beispielprojekte werden wir bei CodePlex einstellen.

So sieht der Kontrakt eines ganz simplen asynchronen Dienstes aus, der z.B. eine Zeichenkette empfängt und serverseitig ausgibt. Das ist trivial von der Funktionalität her. An dieser Stelle möchte ich aber nur zeigen, wie schlank der AppSpace API ist.

Asynchrone Komponenten haben keine Methoden, die man direkt aufrufen könnte, sondern definieren einen Satz von Nachrichten (Message Contract), die sie über typisierte Microsoft CCR Ports empfangen.

using Microsoft.Ccr.Core;
using XcoAppSpace.Core;

public class PPingContract : Port<string>
{}

Das ist die Implementation dies Kontraktes. Eine Klasse vom Kontrakt ableiten und für jede Nachricht eine Behandlungsroutine definieren:

public class PingService : PPingContract
{
    [XcoConcurrent]
    void ProcessPing(string text)
    {
        Console.WriteLine("processing: {0}", text);
    }
}

Und jetzt der Host für die Serviceimplementation. Zwei Zeilen Code reichen aus. Die asynchrone Dienstleistung "läuft" in der Instanz eines Application Space:

using(XcoAppSpace host = new XcpAppSpace("tcp.port=9001"))
{
    host.RunWorker<PPingContract, PingService>("pingservice");
    Console.ReadLine(); // keep the host running while waiting for connections
}

Der Client ist dazu symmetrisch! Das ist einer der Vorzüge des AppSpace. Das macht ihn einfach zu bedienen, weil die Zahl der zu lernenden Konzepte so überschaubar ist:

using(XcoAppSpace client = new XcoAppSpace("tcp.port=0"))
{
    PPingContract p = client.ConnectWorker<PPingContract>("localhost:9001/pingservice");

    p.Post("hello, world!");

    Console.ReadLine(); // keep client alive
}

Das ist´s so ziemlich. Wenn Sie den Code verstanden haben (und die CCR Grundlagen kennen), dann können Sie mit dem AppSpace lokal asynchron oder verteilt asynchron arbeiten. Rückhabewerte, Notifikationen, Publish/Subscribe... das alles ist mit den immer gleichen Mitteln leicht zu realisieren. Schauen Sie mal bei CodePlex vorbei, wo ich dieses Beispiel noch etwas ausgebaut habe.

Laden Sie den AppSpace aus dem Download-Bereich herunter und spielen Sie mal damit. Ich freue mich über jedes Feedback. Bei allem Anspruch ist der AppSpace ja nicht fertig. Er ist erst am Anfang. Wir bei Xcoordination glauben aber, dass die Richtung stimmt. Wenn Sie wollen, gehen Sie in diese Richtung mit. Erste kommerzielle Projekte sind schon vorausgelaufen und melden zurück, dass es sich lohnt. Bei CodePlex und www.xcoordination.com gibt es viel Platz zum Diskutieren. Und außerdem ist der Application Space eine Open Source Software. Die können Sie aber sogar kostenlos in Ihren kommerziellen Closed Source Projekten einsetzen.

Also, auf ins Raumzeitalter mit dem Application Space! Verteilung die einfach funktioniert.

Sonntag, 17. Mai 2009

Lass wachsen! Ein Bild für die Softwareentwicklung heute [OOP 2009]

So abstrakt und virtuell Software wie ist, fällt es oft schwer, darüber zu denken und zu reden. Schnell stellen sich unterschiedliche Bilden in den Köpfen der Gesprächspartner ein. Dann ist es hilfreich, konkret zu werden, um das Denken zu synchronisieren. Dabei helfen Analogien: eine Klasse ist z.B. wie ein Stempel, mit dem man viele Stempelabdrücke/Instanzen erzeugen kann.

Aber was, wenn es komplexer wird? Wie ist das mit einer ganzen Software? Hier ein Bild, über das ich gerade gestolpert bin:

image 
Quelle: http://ecotopian.blogspot.com/2008/04/tree-shaping-tree-house.html

Das ist ein Haus. Und da wir in der Softwareentwicklung auch von Architektur sprechen, erlaube ich mir, es als Analogie für Software zu benutzen. Die Entwurfsmuster-Bewegung verweist ja auch ausdrücklich auf die Inspiration durch bauarchitektonische Konzepte.

Warum aber dieses Haus als Analogie? Weil es besonders ist: es ist nämlich nicht gebaut worden, sondern gewachsen. Dieses Haus besteht aus Bäumen, die "in Form gebracht" wurden. Tree Shaping nennt man das auch. Bonsais sind dagegen trivial. Hier ein weniger komplexes Beispiel für "Baumformung":

image 
Quelle: http://indianblogger.com/2009/04/05/learn-growing-amazing-furniture-arborsculpture/

Häuser wachsen lassen, statt sie zu bauen. Das ist ein interessanter Gedanke aus ökologischer Sicht. Solche "Baumhäuser" sind nachhaltig und kostengünstig. Man braucht vor allem Zeit. "Leben in der Natur" bekommt dann eine ganz andere Bedeutung.

Aber zurück zur Softwareentwicklung: Warum ist ein solches gewachsenes Haus für mich eine Analogie für Software? Weil es sehr schön zeigt, wie Softwarearchitektur bzw. Softwarebau wirklich sind.

Die gewöhnliche Analogie "Hausbau" hinkt nämlich sehr schnell. Der Hausbau ist tausende Jahre alt und sehr effizient. Häuser sind heute hochmodular und werden extrem arbeitsteilig gebaut. Beides gilt für Software nicht.

Aber mit dem "Baumhaus" passt die Analogie wieder. Denn das "Baumhaus" ist nicht so arbeitsteilig errichtet worden, das "Baumhaus" hat eine wörtlich zu nehmende gewachsene Struktur, das "Baumhaus" ist rigide, es ist monolithisch. Schön anzusehen, funktional, aber im Grunde nicht mehr zu ändern. Und das sollte Ihnen bekannt vorkommen in der Softwareentwicklung.

Unsere Programme lassen wir auch wachsen. Wir haben eine Idee davon, wie sie aussehen sollen - und dann formen wir ihr Wachstum dahingehend. Wie beim "Baumhaus". Was dann rauskommt erfüllt die bei Beginn erkennbaren Anforderungen, ist jedoch starr. Die gewachsenen und weiter wachsenden Verflechtungen machen es immer schwerer, die Software zu ändern. Wie beim "Baumhaus".

So kommen Gebäude-Analogie und Software besser zusammen, finde ich. Wir können unsere Software wertschätzen für das, was und wie sie ist. So wie wir ein "Baumhaus" wertschätzen können.

Aber wir sehen auch ganz klar die Grenzen des "Baumhauses". Es ist nicht transportabel, es zu "bauen" dauert sehr lange, es ist absolut inflexibel. Und so werden uns im Umkehrschluss auch die Grenzen unserer "gewachsenen" Software deutlich.

Der Hausbau kann anders bauen. Warum sollten wir in der Softwareentwicklung das nicht auch können. Wir sind nicht auf "gewachsene Software" festgelegt. "Bonsai-Programme" müssen nicht sein. Wir können vom Hausbau und anderen Branchen noch einiges in Bezug auf Flexibilität und Effizienz lernen.

Freitag, 8. Mai 2009

Die Zukunft der IDEs ist hier - Intentional Programming [OOP 2009]

imageVor 4-5 Jahren hatte ich die Zukunft schon einmal gesehen. Damals auf der SD West Konferenz in Los Angeles. Jetzt wieder - aber dieses Mal im Internet. Sie scheint nun auch nicht mehr in so weiter Ferne zu liegen. Die Zukunft der IDEs ist für einige nämlich schon hier. Intentional Software - die ambitionierte und geradezu geheimnisvolle Firma von Softwarepionier Charles Simonyi - hat schon die ersten Releases ihrer Intentional Domain Workbench hinter sich. Bisher ist in deren Genuss allerdings nur ein kleiner Kreis von Anwendern gekommen.

Nach Jahren der eher verschlossenen Türen und vorsichtigen Äußerungen sucht Intentional Software nun jedoch vermehrt den Kontakt zur Entwicklergemeinde, wie es scheint. Selbst auf einer so kleinen Konferenz wie der SET 2009 war Charles Simonyi mit seinen Mitarbeitern, um ihre Vision von der Softwareentwicklung der Zukunft vorzustellen.

Das Bild oben skizziert, worum es geht: Software ist nurmehr eine abstrakte Beschreibung einer Problemlösung, die viele Darstellungen haben kann. Sie ist sogar so abstrakt, dass ihre "wahre Form" in der IDE nicht direkt bearbeitet wird. Für Visual Studio ist Software letztlich der Quelltext, den wir schreiben. Für die Intentional Domain Workbench ist es hingegen ein interner Baum. Und diesen Baum projiziert die Workbench als ganzes oder in Teilen so, wie es für den Anwender am besten passt. Programmierer sehen ihn z.B. als C#- oder Ruby-Code, Domänenexperten als Tabelle oder Graph oder Diagramm.

Und wo ist der Unterschied zu den domänenspezifischen Sprachen samt Werkzeugen wie Oslo, die gerade en vogue sind? Wo ist der Unterschied zum Model Driven Development?

Die Schnittmenge ist natürlich die domänenspezifische Darstellung. DSLs, MDD, Intentional Software bringen das Programm näher an den Domänenexperten. Der Transfer von Formulierungen in der Domänensprache in einem Anforderungsdokument in Code soll leichter werden. Oder noch besser: Domänenexperten sollen im Idealfall selbst programmieren.

image Dass das möglich ist, haben Tabellenkalkulationsprogramme wie Excel schon für viele Problemdomänen gezeigt. Vor Excel bzw. VisiCalc mussten Anwender entweder den Taschenrechner bemühen oder ihre Kalkulationen Programmierern erklären, die sie dann z.B. in C oder Fortran umgesetzt haben. Heute greift der Domänenexperte selbst zu Excel oder - um ein anderes Beispiel zu nennen - MATLAB.

In ihrem Lösungsansatz für die "Domänenprogrammierung" unterscheiden sich DSLs, MDD und Intentional Software jedoch. Die Intentional Domain Workbench profiliert sich dabei aus meiner Sicht durch zweierlei:

  • Abstrakte Repräsentation: Der Quellcode von Software hat nichts mehr mit einer Ausführungsplattform oder Problemdomäne zu tun. Er ist wirklich abstrakt, also nicht mehr textuell.
  • Perspektivenvielfalt: Quellcode soll auf viele verschiedene Weisen im Ganzen oder in Ausschnitten dargestellt und bearbeitet werden können. Alle Sichtweisen sind gleichberechtigt. Quellcode kann daher auch gleichzeitig verschiedene Problemdomänen repräsentieren.
  • Fließende Darstellung: Die vielen Perspektiven auf den Quellcode fließen in der Workbench umeinander. Sie müssen sich nicht zwischen der einen oder der anderen entscheiden, sondern können nebeneinander oder ineinander immer wieder anderen Perspektiven einnehmen.

Schauen Sie sich einmal dieses Video einer Präsentation der Workbench an. Für einen schnellen Eindruck von der Dynamik dieser visionären IDE empfehle ich allerdings den Download der WMV-Datei; spulen Sie darin vor bis zu Minute 14. Da gehts los mit der Demo, aus der die Screenshots oben stammen. Bis zu Minute 45 ist dann die Zukunft der IDEs schon auf Ihrem Desktop. Seien wir gespannt, wann sie schließlich als öffentliche Beta materialisiert. Aber warten Sie nicht darauf! Intentional Software hatte schon viel Zeit und wird wohl auch noch weiter Zeit haben. Man scheint auf Qualität bedacht statt Hype. Eine wohltuende Haltung in Zeiten sich überschlagender CTPs.

Donnerstag, 7. Mai 2009

SET 2009 CCR Beispiele

image Gestern auf der SET 2009 in Zürich habe ich einen Vortrag über die Concurrency Coordination Runtime (CCR) von Microsoft gehalten. Leider standen mit nur 45min zur Verfügung :-( Dennoch glaube ich, dass die Botschaft, die Zukunft liege bei asynchronen Komponenten, um Multicore Prozessoren auszureizen, bei den Teilnehmern angekommen ist. Der Raum war jedenfalls voll und alle schienen am Ende zufrieden. Vielleicht waren sie aber auch nur noch benommen vom Codefeuerwerk, dass ich abgebrannt habe? ;-) Denn ich habe neben 1-2 Flipchartblättern nur Code mit CCR-Beispielen gezeigt. Den gibts hier auch zum Download. Da asynchrone Programmierung für viele neu ist, mögen die Konstrukte auf die Schnelle nicht immer einfach zu verstehen gewesen sein, auch wenn ich mich auf die CCR-Grundlagen beschränkt habe. In jedem Fall freue ich mich, dass am Ende noch 10 Minuten "Überziehungszeit" war, um auch noch die transparente Verteilung von CCR-basierten asynchronen Komponenten demonstrieren. Denn: Wer schon lokal asynchron programmiert, hat es viel einfacher, skalierbare verteilte Architekturen aufzusetzen.

Sonntag, 3. Mai 2009

Werbung in .NET-Fachblättern

image Wieviel Werbung steckt eigentlich in unseren .NET-Fachblättern? Bei Lektüre der aktuellen Ausgabe des dot.net Magazins ist mir irgendwie aufgefallen, dass da viele Events des Verlags beworben wurden. Das schien mir rein gefühlsmäßig ungewohnt. Also hab ich mal Werbefläche gezählt:

  • dot.net Magazin 6/2009: Auf 100 Seiten inkl. Umschlag finden sich da ca. 24 Seiten Werbung unterschiedlicher Größe. Das sind 24% des Heftumfangs. Davon sind 17,8 Seiten Werbung für Verlagsprodukte (Zeitschriften, Bücher, Trainings, Events), also 74%.
  • dotnetpro 5/2009: Auf 150 Seiten kommen 23,15 Seiten Werbung (15%), davon 11 für Verlagsprodukte (48%).

Einen solchen Unterschied in Umfang und Art der Werbung hätte ich nicht erwartet. Was können wir daraus aber ableiten?

Zunächst einmal ist zwar die dotnetpro mit 12,70 EUR pro Heft im Abo teurer als das dot.net Magazin für 7,49 EUR - aber der Preis pro werbefreier Seite ist gleich: 0,10 EUR.  Zwar kostet die Seite im dot.net Magazin nur 0,07 EUR, bei der dotnetpro jedoch 0,08 EUR - aber das dot.net Magazin enthält eben anteilig mehr Werbung. Deshalb liegen sie bei den "Nutzseiten" wieder gleichauf. Wer sich zwischen den Magazinen entscheiden muss, sollte sich also nicht vom Preis auf dem Umschlag irritieren lassen.

Dann ist die Werbung im dot.net Magazin zu fast 75% selbstbezüglich. Wer ein dot.net Magazin in der Hand hat, erfährt durch Werbung vor allem etwas über andere Produkte des dot.net Magazins bzw. des Unternehmens dahinter. Das ist aus Verlagssicht vielleicht erstmal eine gute Sache. Doch als Leser bin ich - wenn Werbung denn schon da ist (und ja: sie muss auch sein) - an Vielfalt interessiert. Dass ein Unternehmen allein meine Bedürfnisse erfüllen kann, ist wenig wahrscheinlich. Die dotnetpro bietet da mehr; ihre Anzeigenverkäufer sind erfolgreicher. Woran das liegt? Vielleicht an der Abonnentenzahl (8130 in Q1/09 bei der dotnetpro vs. 3557 beim dot.net Magazin, s. www.ivw.de)?

Schließlich - das war der Ausgangspunkt meiner Auszählung - ist es interessant zu sehen, dass das dot.net Magazin so stark für Veranstaltungen wirbt: 56% der Anzeigen ist darauf konzentriert (dotnetpro: 30%). In Zeiten des Internets hat offensichtlich die persönliche Anwesenheit wieder einen hohen Stellenwert erreicht. Woran mag das liegen? Ich denke, weil persönliche Anwesenheit eben doch mehr bringt als nur im stillen Kämmerlein zu lesen. Und weil sich für persönliche Anwesenheit leichter Geld verlangen lässt als für Lektürestoff.

Tja... und nun? Was mache ich mit diesen Erkenntnissen? Es gibt keinen Handlungsbedarf. Aber ich freue mich, dass ich meinem Gefühl trauen konnte. In der Werbung der .NET-Fachblätter hat sich etwas verändert. Schauen wir mal, wie es weitergeht.

PS: Jetzt habe ich nochmal in meinen Schrank gegriffen und zwei andere Magazine "ausgezählt". Als Zusammenfassung eine Tabelle:

image

Interessanterweise hat die amerikanische Zeitschrift keinen höheren Werbeanteil als die deutschen. Aber vor allem ist das CoDe Magazine dasjenige mit der geringsten Eigenwerbung, obwohl es ausdrücklich als "Kompetenzdemonstration" des Softwarehauses EPS Software gedacht war.

Auch gehen höhere Kosten pro werbefreie Seite nicht notwendig mit weniger Werbung insgesamt einher, wie das Objektspektrum beweist.

Unterm Strich ist das Feld dennoch recht dicht: Bei Zeitschriften-Fachpublikationen auf Papier müssen Leser einen Preis von ca. 0,1 EUR pro werbefreie Seite bezahlen. Fachbücher wie "Programmieren mit C#" oder "Refactoring" liegen mit 0,08 EUR bzw. 0,09 EUR scheinbar darunter, bieten pro Seite aber viel weniger Inhalt. Eine Buchseite enthält ca. 2.500 Zeichen, eine Zeitschriftenseite mehr als 6.000. Auf Zeitschriftenseiten normiert kosten Buchseiten daher ca. 0,20 EUR, sind also knapp doppelt so teuer wie Zeitschriftenseiten. Und das, obwohl das Buchlayout tendenziell einfacher ist. Es wird wohl daran liegen, dass Bücher "werbefreie Zonen" sind.

Und jetzt die Masterfrage: Wieviel würde der Inhalt online kosten? Wieviel wären wir bereit, dort zu zahlen? Nur 0 EUR wie üblich? Oder könnte eine dotnetpro auch 8.000 Abonnenten online haben? Einen Seitenpreis gäbe es dann zwar nicht mehr, aber vielleicht einen Artikelpreis. Ein dotnetpro-Artikel hat im Schnitt 5 Seiten, schätze ich mal. Er kostet auf Papier also werbefrei 0,50 EUR. Würden wir ihn für vielleicht 0,30 EUR auch im Internet lesen in einem online Abo? Oder würden wir lieber 0,75 EUR bezahlen und dafür eben nur die Artikel lesen, die uns wirklich, wirklich interessieren? Ähnliches gilt für Bücher und ihre Kapitel.

Ich denke, das sind Fragen, an denen die Verlage nicht mehr vorbeikommen. Vielleicht gibt es doch Handlungsbedarf?