Ihr wollt Eure Chance auf Presse-Coverage erhöhen? Mit ein paar simplen Basics macht Ihr es unsereins deutlich einfacher – sogar ganz ohne Kommunikation ;)

Wenn Ihr ein Open-Source-Tool entwickelt habt, soll die Öffentlichkeit ja meist davon erfahren. Sei es eine komplette Linux-Distribution oder nur ein kleines, nützliches Skript. Nun ist aktive PR-Arbeit sicherlich nicht die große Stärke vieler Entwickler und kleine Projekte werden kaum PRler in ihren Reihen haben. Aber es gibt ein paar Basics, die Eure Chancen auf Presse-Coverage deutlich erhöhen. Auch ganz ohne die lästige Kommunikation mit Menschen ;)

Aber vorab: Natürlich geht nichts über aktive PR. Schreibt Pressemitteilungen, meldet Euch bei Redaktionen, geht auf Messen – vermarktet Euer Produkt. Aber klar, einfacher gesagt als getan. Außerdem könnt Ihr eh nicht die ganze Menscheit aktiv informieren. Die folgenden Tipps gelten daher für alle Projekte.

Und denkt immer daran: Auch Journalisten sind faul/bequem/effizienzorientiert – je nach Deutung ;) Im Grundsatz geht es immer darum, es uns Schreiberlingen einfach zu machen. Wenn ich beispielsweise einen Artikel zu Editoren schreiben soll und der erste Kandidat macht Ärger, nehme ich eben den nächsten – es gibt fast immer Alternativen. Ärger kann zum Beispiel sein, dass ich das Ding nicht auf Anhieb installiert bekomme. Oder ich gar nicht erst genau erfahre, um was für ein Tool es sich genau handelt …

Produkt erklären – für Doofe!

Oft sind Sinn und Zweck einer Software gar nicht so einfach zu erkennen. Was soll etwa eine Software Testing Suite genau sein? Es gibt Dutzende Subkategorien von Software-Testing-Tools, aber häufig wird entweder vage mit Business-Slang herumgeseihert oder man wird mit Hardcore-Fachchinesisch zugeballert. Und dann fängt die Sucherei an: Was genau tut die Software denn nun?

Eure Anwender werden es vermutlich wissen – ansonsten hätten sie das Tool wohl gar nicht erst gefunden. Wir Pressemenschen sind aber nunmal in der Regel eher Generalisten, zumindest und vor allem im Vergleich mit hoch spezialisierten Entwicklern und Nutzern von Nischenlösungen.

Erklärt Euer Produkt – für Doofe. Ihr könnt Euch in der Dokumentation so viel über Technik auslassen wie Ihr mögt. Aber auf der Startseite sollte direkt oder verlinkt eine Erklärung für Menschen auftauchen, die unter Umständen erstmal gar keine Ahnung haben worum es geht. Oft habe ich zum Beispiel auf der Suche nach neuen Artikelideen in die Top-Listen von Sourceforge geschaut und bin immer wieder auf offensichtlich interessante Tools gestoßen – deren Sinn sich mir aber nicht binnen weniger Minuten erschlossen hat. Also auf zum nächsten Kandidaten …

ifttt-screen

Na guuut: Wenn Ihr einen so geilen Namen habt, dass er allein das ganze Produkt erklärt, verzichtet halt auf Erläuterungen … Aber nur dann.

Das Ganze hat noch einen netten Nebeneffekt: Nicht nur Pressefritzen, auch Anzugträger brauchen das. Stellt Euch jemanden vor, der mit seinem frischen BWL-Bachelor in seinem ersten Bürojob sitzt und Tools für irgendeinen Einsatzzweck heraussuchen soll. Vielleicht findet er irgendwo einen Hinweis auf Euer Tool, besucht die Website – und versteht kein Wort. Der Typ ist unerfahren, hat Zeitdruck. Was macht er? Klar, auf zum nächsten Kandidaten …

Und wenn Ihr schon schreibt: Auch ein paar Infos über das Projekt wären schön, selbst wenn Ihr als Personen anonym bleiben wollt.

Bilder, Bilder, Bilder

Presse funktioniert nur mit Bildern. Wenn der Journalist kein Bildmaterial hat, schreibt er über etwas anderes. Und nicht immer kann man die Bilder selbst machen – sei es aus Zeitgründen, wegen fehlender Hardware/Infrastruktur oder auch fehlender Fähigkeiten (etwa Kompilieren). Also stellt Bilder zur Verfügung. Legt sie in einen eigenen Pressebereich auf der Website oder erlaubt explizit die Nutzung in Presseerzeugnissen wie Blogs, Social Media oder Print.

Wieder ein Praxisbeispiel: Ich soll einen Artikel über NAS schreiben und benötige ein Bild von einem NAS – irgendeinem. Bei einem längeren Artikel mache ich bestenfalls selbst ein Foto. Für eine kurze News oder Ähnliches lohnt sich schon das nicht. Wenn ich nun bei Anbieter A im Pressebereich nichts finde, schaue ich bei Anbieter B – und schon sehen Tausende Menschen beispielsweise nicht das Synology-, sondern das QNAP-NAS. Gerade im eher hektischen Print-Alltag sind bei mir damals viele Anbieter tatsächlich genau wegen fehlender Produktbilder eben nicht erwähnt worden. (Der Grund dürfte bei großen Konzernen teils sein, dass sie kontaktiert werden wollen – der Sinn von Presseabteilungen … Aber hey: Für eine 1.000-Zeichen-News kontaktiere ich in der Regel mal niemanden!)

Aber auch bei Software muss das sein. Software zu installieren und gegebenenfalls auch noch mit Daten zu füllen, damit die Oberfläche überhaupt nach etwas aussieht, ist zeitaufwändig. Und bei Dingen wie Netzwerk-Software bisweilen auch irrwitzig komplex.

checkmk graphing

Um so einen Screenshot zu erstellen, benötigt man viel Zeit – denn ohne Daten wäre der Graf gar nicht vorhanden. Im Redaktionsalltag ist das nur bedingt zu leisten.

Also tut Euch den Gefallen und macht ein paar hübsche, große Screenshots und erlaubt die Nutzung. Zur Not auch über Lizenzen statt explizite Hinweise, aber:

Ordentlich lizenzieren

Ganz wichtig, auch für kleinere Projekte: Verseht Eure Software mit einer Lizenz und erklärt sie. Ohne Lizenz ist es bisweilen schwierig, eine Open-Source-Lösung überhaupt zu empfehlen – bei professioneller Software unmöglich. Aber erklärt die Lizenz auch in Auszügen – die wenigsten Journalisten, selbst reine IT-Autoren, werden sich mit freien Lizenzen auskennen. Schreibt also – nach Euren Möglichkeiten – wenigstens kurz und knapp, was man mit dem Code in etwa machen darf und was man beachten muss. Und wieder: Auch für Anzugträger enorm wichtig!

Noch wichtiger sind Erklärungen bei Lizenzen für Bilder. Die meisten Projekte geben für die Bilder keine expliziten Lizenzen an, dabei – siehe oben – sind Lizenzen die besten Genehmigungen überhaupt. Mit einer Creative-Commons-Lizenz, am besten CC-BY-SA, seid Ihr gut aufgestellt – und das CC-Projekt ist auch ein Meister darin, Lizenzen für Otto Normalverbraucher verständlich zusammenzufassen.

pr basics

Die „Deeds“ sind Kurzversionen der CC-Lizenzen (hier als Auszug).

Und wenn sich jetzt jemand denkt: Das ist doch ein Open-Source-Projekt – ist doch selbstverständlich. Oder: Screenshots sind doch eh nicht geschützt, was soll das Theater? Selbstverständlichkeiten funktionieren nur bei gleichgesinnten Fachleuten und Diskussionen ob der Schöpfungshöhe von Screenshots passen nicht in den Arbeitsalltag. Geht davon aus, dass die meisten Journalisten eher zu vorsichtig sind. Und was passiert, wenn die Lizenzierung Fragen aufwirft? Na?! Genau: Nächster Kandidat …

Normale Kontaktmöglichkeit

Ihr mögt gerne über Foren, Messenger, IRC oder Brieftauben kommunizieren und viele andere Entwickler und Open-Source’ler auch – aber das Standard-Kommunikationsmittel für „normale Menschen“ ist derzeit noch die gute alte E-Mail. Oder glaubt Ihr ernsthaft, Anzugträger oder Journalist würden sich durch Eure Community wühlen? Für einen Mini-Beitrag, der in einer Stunde produziert werden muss? Nö! Nächster Kandidat …

Binaries/Demos/Images

Für längere, ausführliche Artikel und Anleitungen – oder einfach gute Beiträge – genügen Bilder und Erklärungen nicht. Die Software muss zum Laufen gebracht und bespielt und gescreenshottet werden. Also kommt bitte nicht ausschließlich mit Quellcode um die Ecke. Für die echten Nutzer mag das eine brauchbare Idee sein. Aber Ihr wisst selbst, wie häufig dabei etwas schief geht – und wieder: Es mangelt oft an Zeit oder Fachwissen, was zu Nächster-Kandidat-Gedanken führt.

Zumindest zum Antesten solltet Ihr Demos, Binaries, komplette Linux-Images, Images für virtuelle Maschinen oder meinetwegen Docker-Container anbieten. OK, Docker hilft dann auch nicht jedem … Aber Ihr wisst, was gemeint ist. Zu dem Thema gehört übrigens auch die Anleitung: Installation und erste Schritte solltet Ihr mit in Punkt 1 oben packen. Gebt den Menschen eine Schritt-für-Schritt-Anleitung für die Installation und dann zumindest mal ein, zwei praktische Beispiele für die Nutzung der Software – wenigstens, wenn es irgendeine Art von (üblichem) Workflow gibt.

screenshot von gutenberg

Wenn möglich, stellt eine Demo zur Verfügung, wie hier der Editor Gutenberg (nun, die hätten’s wohl besser gelassen …).

Aktiv werden …

Mit den fünf Tipps könnte Ihr dafür sorgen, dass Journalisten, Blogger, Autoren und auch anzugtragende IT-Manager, die wie auch immer zu Eurem Projekt gekommen sind, nicht sofort wieder abhauen, weil sie nach zwei Minuten schon die bevorstehenden zwölf Stunden Einarbeiterei riechen.

Wenn Ihr Euch ein wenig mehr Aktivität und Kommunikation zutraut: Nutzt kostenlose Presseportale für eine simple Pressemitteilung, erstellt eigene Social-Media-Accounts für das Projekt und ballert Medien, Journalisten und Blogger – dezent … – mit Infos zu. Sofern es einen Anlass gibt (neue Software, neue Version oder ähnliches), werden sich die meisten von uns über die Info freuen. Themen ergeben sich nicht immer über Nacht ;) Zumal: Gerade für Print-Kollegen ist es häufig auch durchaus interessant, direkten Kontakt zu Entwicklern zu haben – schlicht, um exklusive Geschichten machen zu können. Es ist eben keine Einbahnstraße, Ihr bettelt nicht nach Coverage, Ihr habt etwas anzubieten, was unsereins durchaus haben will.

Dieser Tipp eignet sich freilich nicht für kommerzielle Projekte, zumindest nur bedingt. Wenn das ganze nach dem Versuch von versteckter Werbung aussieht, sollten die meisten Kollegen der schreibenden Zunft sofort dicht machen. Wobei es bei Open Source immer noch Möglichkeiten gibt.

Ernsthaft?

Zwei Dinge könnte ich mir vorstellen, die bei diesem Artikel, sagen wir Verwunderung auslösen: Erledigen diese Basics nicht sowieso alle? Und kann der doofe Journalist nicht einfach etwas Zeit investieren oder sich melden?

Nun, nein, diese Basics erledigen viele nicht – selbst viele Großkonzerne schaffen es zum Beispiel nicht, vernünftige Bilder zur Verfügung zu stellen. Entweder gibt es gar keine oder schlechte oder alte oder ganz kleine oder es fehlt eine schriftliche Genehmigung, die viele Redaktionen durchaus haben wollen. Vernünftige Produkterklärungen? Schaut Euch mal die neuesten Blockchain-Produkte von Microsoft oder IBM oder Amazon an – klare, deutliche, einfache Erklärungen sucht man da stets vergebens.

Und nochmal nein, man kann die Zeit nicht immer investieren. Ich habe schon 50-Euro-News geschrieben, bei denen es mich letztlich zwei Stunden gekostet hat, einfach nur zu verstehen, was die Deppen denn von mir wollen. Fairerweise muss ich dazusagen, dass es sich dann eigentlich immer um Buzzword-Junkie-Produkte aus dem Anzugträgerumfeld handelte.

Super Beispiel für alles zusammen sind die beliebten Listicals, also Top-10s, 5-Lösungen-für-ABC-Artikel und so weiter. Wenn ich in einem 200-Euro-Artikel zehn Tools vorstellen soll, habe ich extrem großzügig gerechnet 20 Minuten pro Tool, um gerade noch wirtschaftlich zu bleiben. Ein Tool in 20 Minuten zu finden, zu verstehen, zu installieren, mit Daten zu füttern, zu screenshotten und auch noch zu vertexten geht durchaus – gerade eben so, wenn alles super super glatt läuft. Und es simple Tools sind. Und keine Nieten in der Erstauswahl sind. Also selten. Quasi nie.

Wenn aber alle obigen Tipps ordentlich umgesetzt wurden, ich eine Demo antesten kann und gute Bilder gestellt bekomme, geht das bei nicht allzu komplexer Software ganz gut. Andernfalls gilt das Nächster-Kandidat-Prinzip und es kommt halt die Konkurrenz in die Liste.

Außerdem: Auch Journalisten haben bisweilen schlichtweg keinen Bock und nehmen trotz genügend Zeit und Fähigkeiten lieber den einfacheren Weg. Traurig, ist aber so. Wenn Ihr Coverage wollt, macht den Leuten die Arbeit einfach.

Mehr zum Thema Open Source findet Ihr hier – oder wie wäre es mit Tipps zu kostenlosen Bildern für kommerzielle Zwecke?

Über den Autor

Mirco Lang

Mirco Lang

Freier Journalist, Exil-Sauerländer, (ziemlich alter) Skateboarder, Dipl.-Inf.-Wirt, Einzelhandelskaufmann, Open-Source-Nerd, Checkmk-Handbuchschreiber. Ex-Saturn'ler, Ex-Data-Becker'ler, Ex-BSI'ler.

Computer-Erstkontakt: ca. 1982 - der C64 des großen Bruders eines Freunds.

Wenn ich Dir helfen konnte und/oder Du hier mehr über Open Source, Linux, Bastelkram oder auch Windows-Basics lesen möchtest:
Spendier mir einen Kaffee via Paypal.

Kommentieren:

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.