Der schwere Werdegang zu einem FOSSGIS-Open Source Projekt
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 69 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/17595 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
1
4
5
6
8
9
10
13
14
15
19
22
23
24
27
29
33
35
37
38
39
40
41
42
44
48
50
53
54
56
57
61
63
64
67
69
00:00
OLESoftwareGroße VereinheitlichungOpen SourceComputeranimationVorlesung/Konferenz
01:01
Open SourceSoftwareScratchmakeMiddlewareMAPProxy ServerTorvalds, LinusSoftwareFunktion <Mathematik>AnwendungssoftwareGroße VereinheitlichungLaufzeitRichtungHomepageOpen SourceSystems <München>SystemplattformEnde <Graphentheorie>MAPGeodätische LinieXML
09:27
InternetdienstmakeVersion <Informatik>CodeAPIClippingSoftwareTwitter <Softwareplattform>Web SiteSoftwareFunktion <Mathematik>ChipkarteEbeneVersion <Informatik>Web-SeitePOWER <Computerarchitektur>RichtungProzess <Physik>Mailing-ListeOpen SourceInternetdienstProxy ServerEnde <Graphentheorie>MAPComputeranimation
17:52
KonfigurationsraumFAQMailing-ListeWeb logTwitter <Softwareplattform>CodeEinfache GenauigkeitSoftwareentwicklungCodeMengeSoftwareFunktion <Mathematik>LinieSoftwareentwicklungMomentenproblemNumerisches GitterRichtungMailing-ListeOpen SourceSystems <München>Bericht <Informatik>Ende <Graphentheorie>Computeranimation
26:18
Mayer, ChristianCodeKomponente <Software>Open SourceFaktorisierungVersion <Informatik>HomepageProxy ServerVorlesung/Konferenz
29:32
Computeranimation
Transkript: Deutsch(automatisch erzeugt)
00:07
Wir hören jetzt, für einige vielleicht zum wiederholten Mal, Oli Thonhoeffer von OmniScale und Till Adams von Terrestris. Auch zu deinem Konferenz-Dauer-Thema habe ich den Eindruck, was macht eigentlich ein gutes Open Source Projekt aus?
00:21
Mal gucken, was wir jetzt noch Neues von dir hören. Ich hoffe viel. Ja, das ist natürlich ein bisschen schwer, jetzt auch gegen Gras zu konkurrieren, wie wir gerade gehört haben. Der Oliver und ich haben uns überlegt, einfach mal aus einer Firmen-Sicht auch darzulegen, wie sich das eigentlich für uns präsentiert.
00:40
Wenn wir irgendwo, weiß nicht, aus einem tollen Projekt heraus oder mehreren Projekten eine Software schaffen, sagen, super, jetzt machen wir ein Open Source Projekt. Ja, an welchen Schwierigkeiten das möglicherweise einfach hängt, um einfach mal ein bisschen Bewusstsein zu schaffen. Ein bisschen darüber hinaus, dass man eigentlich nicht nur coden muss, sondern was da eben noch alles Mögliche mit dranhängt.
01:00
Genannt haben wir das, der schwere Werdegang zu einem Open Source Projekt und wir haben uns eine ganz kurze Agenda verschrien, um erstmal vielleicht darzustellen, wer sind wir überhaupt, wie kommen wir auf diese Idee, was ist der Erfolg, welche Wege führen zu Erfolg und ja, am Ende vielleicht ein kleines Fazit aus unserer Sicht darzustellen.
01:26
Ich bin Till Adams, ich wurde ja auch schon vom Jörg nochmal vorgestellt. Ich wollte gar nicht jetzt auf unsere Firma oder sonst was eingehen, sondern im Wesentlichen stehe ich hier als einer, der von der Firmenseite ein Projekt, Shogun, da habe ich gestern einen Vortrag darüber gehalten, ja immer wieder versucht so ein bisschen auch Richtung Open Source Projekt zu schieben
01:47
und einfach auch aufzuzeigen, welche Schwierigkeiten dabei so ein bisschen aufgetreten sind. Ja, ich bin Oliver Tonnofer, komme von der Firma Omni Scale aus Oldenburg. Ja, wir machen auch einiges an Open Source Entwicklungen, klein-seitig und serverseitig und weswegen ich jetzt hier auch spreche,
02:07
ist, dass wir die Autoren von MapProxy und Impostum sind, zwei Open Source Projekte, wo wir auch viel Entwicklungs-Support anbieten. Und ja, wir haben uns überlegt, erfolgreiches Open Source Projekt, was ist
02:23
Erfolg und da sind wir zum Schluss gekommen, dass man das unterscheiden muss, also einmal zwischen dem Erfolg von denen, die die Software produzieren, also den Autoren von der Software und der Erfolg von den Nutzern. Und Erfolg für die Autoren von Open Source, da kann man sicherlich sagen, dass es
02:42
erfolgreich ist, wenn sie die eigenen Ziele, die sie in das Software gesetzt haben, erreicht haben. Und welche Ziele, kann man sich natürlich fragen, da muss man unterscheiden, was für eine Motivation denn der Autor von der Software überhaupt hatte. Ich habe das versucht, in drei Bereiche zu unterteilen, philanthropisch quasi, Open Source ist halt ein Geben und Nehmen,
03:06
das ist eine Philosophie hinter Open Source Software und das Open Source Software funktioniert nur, wenn es auch Leute gibt, die etwas geben und nicht nur Leute gibt, die etwas nehmen. Deshalb kann Motivation sein, Open Source Software zu produzieren, dass man einfach etwas zurückgeben möchte.
03:26
Und es gibt sicherlich auch Autoren, die einfach was Gutes tun wollen. Prominentes Beispiel wäre da sicherlich das Hot, also Humanitarian Open Street Map Team, die arbeiten innerhalb von Open Street Map für Krisengebiete.
03:45
Die entwickeln da Software, die mappen Daten und die sind von diesen Krisen in der Regel selber nicht betroffen, aber sie wollen Gutes tun und arbeiten deshalb an Open Source Software und in dem Fall auch Open Data. Man kann wirtschaftliche Interessen haben und deshalb Open Source Software produzieren.
04:04
Open Source, wie wir ja schon anderen Vorträgen gelernt haben, ist auch ein Business-Modell, man kann Support und Wartung anbieten, man kann Weiterentwicklung finanzieren lassen. Open Source kann auch als Marketing-Instrument sein.
04:23
Es gibt einige Firmen, die einfach nur sagen, wir machen Open Source als Buzzword, schreiben das auf der Homepage und das sehen die quasi als Vorteil, als Ziel quasi an, obwohl sie nicht viel an Open Source selber machen.
04:41
Ein weiterer Vorteil von der Open Source kann natürlich für eine Firma sein, dass man dann mit dem Projekt so ein bisschen verbunden wird und dann, wie es da steht, die Firma, die ist ja die von dem Projekt XY. Und die Motivation der Open Source Software zu entwickeln kann auch einfach praktische Gründe haben.
05:03
Im Englischen gibt es den schönen Begriff scratch your own itch, also wenn man einfach ein Bedürfnis hat, man braucht eine Software, die irgendetwas löst, man entwickelt sie und gibt sie dann einfach frei, weil man denkt, gut, da gibt es auch noch andere, die die Software nutzen möchten. Und dann kommt das nächste, ein Zitat von Linus Torvalds, a thousand eyes makes all bugs shallow.
05:24
Und ja, das heißt, wenn mehr Leute eine Software benutzen, dann ist die Wahrscheinlichkeit höher, dass da auch mehr Leute mehr Fehler finden, die dann am Ende aber dann gefixt werden und dadurch die Software dann besser wird.
05:43
So, so, so, so, aus, an, u, ich machs noch nicht mehr aus. Ja, die andere Seite ist natürlich der Erfolg des Nutzers einer Open Source Software und da steht
06:00
natürlich erstmal im Mittelpunkt, der Anwender hat irgendein Problem und das Problem möchte er mit einer Software lösen. Und ja, im Grunde genommen ist es eigentlich wie bei allen Dingen so, ob ich jetzt einkaufen gehe oder einen Projektplan letzten Endes, ich hab immer einen relativ restriktierten Kosten- und Geldrahmen, möchte also eben gucken, dass ich das
06:20
Problem mit dem Budget, was mir zur Verfügung steht, letzten Endes geregelt kriege und da fließen natürlich so Dinge ein wie Schulungsaufwand, Dokumentationen, Workshops, auch vielleicht Zeit, die ich mit Trial and Error oder Suche nach der richtigen Software versetze. Entwicklung von fehlenden Funktionen, ist ja relativ häufig so, dass man so ein bisschen guckt, sicher auch mal
06:43
im Open Source-Feld umguckt, was gibt's für eine Software, für eine Bibliothek und was fehlt mir da eigentlich noch und wie komme ich eigentlich dahin, damit die wirklich letzten Endes das tut, was sie tun will. Ich denke, da war das Beispiel von Sven Böhme heute Morgen sicherlich ein ganz gutes und treffendes und ich hab natürlich trotzdem irgendwelche laufenden Kosten, jetzt im Open Source-Bereich vielleicht weniger Lizenzkosten,
07:05
irgendwelche Wartungskosten oder auch einfach Kosten, um eine Mitarbeiter zu bezahlen, Software zu betreiben und so weiter und ich will natürlich auch gucken, dass ich einigermaßen nachhaltig das mache, vielleicht nicht ganz so nachhaltig, wie jetzt eine Archivierung tickt, ich glaube unsere Systeme haben in aller Regel eine wesentlich kürzere Laufzeit als Bibliothekardenken, zumindest was ich gerade
07:27
gelernt hab, aber das ist natürlich ein wichtiger Punkt und das sind eben auch so Eckdaten, wo ich so ein bisschen immer drauf gucke bei einem Open Source-Projekt, wie aktiv ist das Projekt eigentlich, sind da überhaupt noch Leute beschäftigt, wie viele Leute sind da beschäftigt, gut, achso, so war das, letzten Endes muss man sagen, das hat auch relativ viel mit Vertrauen zu
07:58
tun, weil ich investiere ja letzten Endes mein Geld, meine Zeit in ein Projekt an der Stelle und um mir sicherzustellen, dass ich
08:05
eben diese Ziele, die wir dort aufgelistet haben, was sicherlich auch nur ein paar sind, die es geben kann, vertraue ich ja auch ein Stück weit darauf, dass die Leute, die diese Software entwickeln, das in dem Rahmen so gut machen, dass ich letzten Endes dahin komme, wo ich am Anfang angefangen habe, dass ich mein Problem gelöst bekomme.
08:23
Gut, wir wollten das mal an ein paar Beispielprojekten darstellen, wie sich die Problematik aus unserer Sicht darstellt und ja, das erste Beispielprojekt wäre Shogun, wir haben mal als Zielgruppe ausgemacht, vielleicht einfach Entwickler, das ist ein relativ breites Feld
08:43
an der Stelle, aber schlussendlich Leute, die vielleicht das Rad nicht neu erfinden wollen, die vielleicht nicht bei Null anfangen wollen, die und zum zweiten, das liegt einfach in der Natur der Sache, dieses WebGIS Frameworks, was es letzten Endes ist, es richtet sich eigentlich an Kunden aus, ich sag mal, etwas größeren Organisationen, weil wir Mechanismen haben, um viele Geodaten zu
09:05
verwalten, viele Funktionen und so weiter und so fort, die initiale Motivation, die wir eigentlich hatten als Firma, als Firma Terrestris war, uns eigentlich selber eine Plattform zu schaffen, wo wir selber nicht immer wieder bei Null anfangen, wo wir einfach sagen,
09:22
wir haben im Prinzip eine Kernsoftware, das hieß bei uns intern, Arbeitstitel auch relativ lange, der sogenannte Terrestris Kern, das ist relativ langweilig, aber beschreibt eigentlich sehr, sehr gut, was wir damit vorhatten und erreichen wollten, um uns eben letzten Endes selber die Arbeit einfacher zu machen und das zweite war eigentlich eine Erkenntnis, die wir hatten, wo wir gesagt
09:43
haben, wir brauchen eigentlich zunehmend in unseren Projekten so ein Stück weit eine Middleware, die vielleicht auch einfach ein paar Prozesse steuert, die eine Benutzerverwaltung drin hat, Dienste absichert und so weiter und so fort. Gut, jetzt bist du.
10:00
Genau, wie jetzt Firma Omniscale, wir haben Maproxy entwickelt, Maproxy ist ein Tool, also ich kann nicht beschreiben, was es eigentlich so alles macht, aber es ist ein Tool mit sehr offenen Funktionsumfang, also wo man sich sehr viele neue Funktionen immer wieder vorstellen kann, die man da hinzufügen kann. Nutzergruppe in dem Fall sind keine Entwickler, das sind schon Nutzer, die zum Beispiel auch
10:24
WMS-Dienste aufsetzen würden, jetzt in der Behörde oder in einem Unternehmen und die Motivation, das als Open Source zu veröffentlichen, also die initiale Entwicklung, die hatten wir innerhalb von der Innovationsförderung nicht als Open Source entwickelt, hatten dann aber durchaus wirtschaftliche Interessen da mit Weiterentwicklung,
10:48
Support und Wartung da quasi dann als ein Teil von unserem Geschäftsmodell zu sehen und zum Teil Motivation da auch geben und nehmen, weil wir natürlich auch sehr viel Open Source verwenden.
11:03
Anderes Beispiel von uns ist Impossum, das ist ein Tool mit dem man Open Street Map Daten in PostGIS importieren kann, da ist die Zielgruppe ganz klar Power User, also Nutzer, die in der Lage sind Datenbank-Server aufzusetzen, Open Street Map Daten als Karten zu visualisieren, der
11:23
Funktionsumfang ist recht abgeschlossen, Version 1 konnte die Daten importieren und das hat für die meisten auch schon gereicht. Wir haben es entwickelt, weil wir die Software selber brauchten und wir haben es dann veröffentlicht als Open Source, weil wir oft haben, dass wenn möglichst viele Leute die Software nutzen, dass die halt dann auch einfach Fehler finden und wir dann
11:44
intern halt auch einfach davon profitieren, wir setzen die Software ein, wir haben Interesse, dass da keine versteckten Fehler drin sind. Und ja, wir haben jetzt, wir wollen ja darüber sprechen, die Wege zum Erfolg, was gehört denn zu einem erfolgreichen Open Source Projekt und wir haben das ein bisschen unterteilt in die einzelnen Punkte.
12:04
Und der erste Punkt, Entwicklung, das ist eigentlich so, an was jeder direkt denkt, wenn er an Open Source denkt, nämlich ist es die Entwicklung von der Software, initiale Entwicklung ist da ein großes Thema, das ist in der Regel mit sehr hohen Aufwänden verbunden.
12:24
Im Possum, wie ich eben gerade erzählt habe, haben wir halt entwickelt, weil wir selber nutzen wollten, wir haben Bedarf gehabt für die Software. Weitere Entwicklung ist ein Thema und große Features, da gehe ich gleich nochmal ein, Till wird gleich auf Version 2
12:44
nochmal darauf zukommen, was das so mit sich bringt an Problemen und externe Codebeiträge, das man natürlich als Open Source Projekt hofft man natürlich auch, dass man nicht alles selber entwickelt, sondern dass es auch externe Entwickler gibt, die sich da beteiligen.
13:04
Aber auch da gibt es Probleme, die wir nachher nochmal drauf eingehen. Das ist ein Beispiel von Maproxy, bei der Entwicklung von der Open Source Software, da ist es halt so, dass man manchmal auch größere Features hat, für die man selber als Autor vielleicht gar
13:25
keinen Bedarf hat, aber es gibt Kunden und Nutzer von der Software, die eine bestimmte Funktion haben wollen. Und das muss natürlich finanziert werden, also jemand braucht die Zeit, um das zu entwickeln oder jemand muss eine Firma beauftragen, die das entwickelt.
13:41
Und hier sind zwei Beispiele, eins, wo das sehr gut funktioniert hat, das ist die Absicherung von Maproxy, da konnten wir die Entwicklung einfach in vier Schritte aufteilen, die jeweils von einem ganz anderen Kunden finanziert wurde. Und WFS-Unterstützung, das ist eine größere Funktion, hat einen sehr hohen initialen Entwicklungsaufwand und da ist es halt problematisch, das entwickelt zu bekommen.
14:05
Es gibt viele Anfragen nach der Funktion, aber es gibt keinen, der diesen großen Batzen auf einmal quasi stemmen kann. Ja, Beispiel Shogun, kann ich eigentlich sagen, wir haben das ursprünglich mal angefangen, ich weiß gar nicht genau, wann war das, 2011, 2010, da sitzen nämlich zwei, die da viel gemacht haben,
14:25
haben dann irgendeine sogenannte Version 1x, um das jetzt mal als Startversion sozusagen aufzusetzen, wir haben ja eben in der Diskussion mitgekriegt, die Versionen sind nicht so furchtbar wichtig, haben damit auch zwei, drei Projekte gemacht, tatsächlich, es hat auch leitlich gut funktioniert, also die
14:41
UR-Idee, wir können das weiterverwenden, haben aber eigentlich schon relativ früh, das war Oktober 2013 angefangen, es war ein Entwickler von uns, mal Konzepte zu überlegen, wie man sogenannte Shogun 2, also eine komplett überarbeitete neue Version macht, und ja, seit dem Oktober 2013 ist da ehrlicherweise auch nicht furchtbar viel passiert, die Konzepte gibt es immer noch, die Ideen sind noch da,
15:06
schlussendlich hat uns als Firma einfach auch mit einer beschränkten Größe einfach die Projektarbeit so weit vorangetrieben und vor uns hergetrieben, sage ich mal an der Stelle, dass wir einfach nicht vorangekommen sind, wir haben einfach gesagt, ok, wir haben eine Version 1, mit der kommen wir so leitlich klar,
15:23
und irgendwo haben wir einen relativ hohen Projektdruck, wo wir einfach nicht da hingekommen sind, unsere ursprünglichen Ideen, unsere reinen Gedanken, die wir uns gemacht hatten, zu einer neuen Version, einer kompletten Überarbeitung, dann auch wirklich in die Tat umzusetzen. Das nächste Beispiel, was wir haben, ist Support, Mailinglisten, ich habe gestern, als wir darüber gesprochen haben, ein bisschen gegrinst,
15:45
ich finde das auch schön, dass du hier sitzt, Jörg, du erinnerst dich, als wir die mapserver.de-Liste mal gestartet haben, haben wir auch gedacht, das macht aber nur Sinn, wenn auch wirklich was passiert, und der Jörg saß in Berlin und ich saß in Bonn, und wir haben so einen kleinen Wettbewerb, glaube ich, gemacht, wer schneller antwortet, hat aber mittlerweile, glaube ich, ganz gut funktioniert,
16:04
also ich antworte da nicht mehr, das tun mittlerweile andere. Insofern war das natürlich erfolgreich. Es gibt natürlich auch so etwas wie kommerziellen Support, oder eben, wo ich eingangs der Konferenz noch mal geredet habe, Wartung und Vertriebssicherheit, aber auch das birgt das ein oder andere Problem.
16:24
Gerade bei dieser Wartung, Betriebssicherheit ist es eben so, man muss dann tatsächlich einspringen, wenn es wirklich irgendwo brennt, und das ist in so einem natürlichen Ablauf, wie so eine Firma eigentlich funktioniert, wie die Leute entwickeln, Entwickler wollen am liebsten wochenweise auf dem gleichen Projekt arbeiten, ist das immer ein Stück weit Konflikt auch einfach.
16:41
Da ruft jemand an, dann gehe ich rüber und sage, Mark, kannst du mal eben, und er ist natürlich rausgerissen aus seiner Arbeit. Das ist einfach ein kleineres Problem. Auf der anderen Seite ist es natürlich auch, wie ich vorgestern schon gesagt habe, für eine Firma ganz komfortabel, dass man erst mal Geld dafür bekommt, dass man da ist, und dann eben relativ kontinuierlich und gut planen, so eine Software weiterentwickeln kann.
17:06
Ja, Marketing ist für ein Open Source Projekt auch wichtig. Und ja, ganz einfaches Projekt, da reicht es vielleicht auch aus, wenn man eine schicke Readme Datei hat, wo alles beschrieben ist und das dann bei GitHub ist. Sobald das Projekt aber ein bisschen größer ist und auch ein bisschen nachhaltigeren, langfristigeren Eindruck machen soll,
17:26
kommt man nicht drum herum, da eine Projektwebseite zu haben. Das sind alle Sachen, die der Autor von der Software oder die Community hinter der Software steht, natürlich alles auch neben der reinen Entwicklung halt durchführen muss.
17:42
Ja, Twitter-Vorträge auf Konferenzen, vielleicht mal einen Flyer drucken, die Software für die Osgeo Live DVD vorbereiten. Das sind alles Sachen, die man in Richtung Marketing, ja, in die Marketing-Schiene packen kann, womit man aber in erster Linie als Unternehmen auch kein Geld mit verdient.
18:03
Dokumentation, auch eine Sache, was immer sehr schwierig ist. Dokumentation zu schreiben ist sehr aufwendig. Wenn wir Sachen entwickeln, neue Funktionen, dann haben wir natürlich ein Interesse, dass diese Funktion dokumentiert ist,
18:21
weil wir natürlich auch im nächsten Jahr, wenn das schon ein bisschen her ist, wollen wir noch wissen, wie das Ganze eigentlich funktioniert, was haben wir denn da eigentlich entwickelt. Aber dann fängt es schon an mit Installationsanleitungen, vielleicht für Systeme, die man selber gar nicht einsetzt, Tutorials, die es gerade Anfängern erleichtern. Da kommt kein Kunde und sagt, hier habt ihr mal Geld, um eine Woche mal so ein super Tutorial und Anfängerdokumentation zu schreiben.
18:49
Das ist natürlich schon ein Problem für Open Source-Projekte, dass man da für so etwas die Zeit einfach finden muss. Release Management, auch eine Aufgabe, die man nicht unterschätzen sollte.
19:04
Also zum Release Management gehört es, Pakete zu bauen, die zu aktualisieren, hochzuladen, Release Notes zu schreiben, was hat sich verändert, eventuell auch vorher noch Vorversion, Beta-Version Release Candidates zu machen.
19:21
Das ist auch alles Zeit, die man benötigt für so ein Open Source-Projekt, die aber niemand wirklich in Rechnung stellen kann. Qualitätssicherung, auch ein großes Thema. Da sollte man als Nutzer von der Software gucken, dass so eine Software sehr viele automatisierte Tests hat.
19:45
Aber nur so kann sichergestellt werden, dass auch langfristig die Software einfach rund läuft. Ein weiterer Punkt an Qualitätssicherung ist sicherlich, dass man, was wir eben Richtung Support gehört haben, über Mailing-Listen,
20:01
man muss einfach da aktiv sich beteiligen und gucken, was die Nutzer einfach melden. Weil hinter einer Anfrage auf einer Mailing-Liste kann einfach ein Konfigurationsfehler sein, da kann ein Nutzer sein, der einfach die Dokumentation nicht richtig gelesen hat. Aber es kann auch einfach sein, dass da wirklich ein Bug in der Software ist.
20:22
Und deshalb ist das halt auch wieder. Man muss die Mailing-Listen lesen, man muss vielleicht nachvollziehen, was sind da für Fehler und muss das dann wieder in der Software ausgleichen. Und da kommen wir dann auch zu noch einem Problem. Wir haben das genannt, Code über den Zaun werfen, so ein kleines Feature innerhalb von Map-Proxy zum Beispiel.
20:46
Da gibt es Sachen, die man auch mal in zwei, drei Stunden eben entwickeln kann. Und da gibt es dann auch externe Nutzer von der Software, die sagen, ich brauche diese Funktion, die entwickeln die schnell und sagen, hier ist jetzt dieses Feature.
21:01
Das Problem ist dann, wer schreibt die Dokumentation dafür? Wer schreibt dafür Tests? Und wer stellt sicher, dass es da keine Konflikte mit anderen Funktionen gibt, etc.? Und was ist in der Zukunft, wenn mit dieser Funktion jetzt Fehler auftauchen? Wer behebt diese Fehler?
21:20
Und das ist ein Problem, was man nicht unterschätzen darf. Einmal als Nutzer, wenn man so eine kleine Veränderung macht und die einfach beiträgt, da muss man einfach damit rechnen, dass man da noch diese ganzen anderen Punkte teilweise abarbeiten muss, bevor diese Änderung auch wirklich ins Hauptprojekt integriert wird.
21:44
Und anders ist natürlich auch, wenn jemand sagt, wenn man jemand beauftragt, eine Funktion in einem Projekt zu implementieren, dann muss man halt einfach davon ausgehen, dass die Aufwände von der Firma halt mehr sind als nur diese kleine Änderung durchzuführen,
22:00
sondern die Firma, die an dem Projekt arbeitet, muss auch Dokumentation, muss auch Test und so weiter liefern. Ja, und schlussendlich will man natürlich auch eine Community aufbauen, auch so aus dem Start-up. Hier haben wir eine tolle Software, legt die irgendwo hin, findet das erstmal auch gar keiner. Das ist so ein bisschen das Problem.
22:25
Und Community dient ja letzten Endes ein Stück weit Erfahrungsaustausch, auch vielleicht eine gemeinsame Arbeit. Gestern diese Hacking Weekends zum Beispiel angesprochen, die der Foskis veranstaltet. Und dient natürlich letzten Endes auch dafür, andere Entwickler möglicherweise auf sein Projekt einfach aufmerksam zu machen.
22:43
Und die sagen, ah Mensch, das ist ja eigentlich ungefähr das, was ich eigentlich haben wollte. Und ja, es ist letzten Endes einfach auch eine Menge Arbeit, die da reinfließen muss, um so eine Community erstmal aufzusetzen, um sowas ans Rennen zu bringen. Da greift, glaube ich, auch wieder ganz gut das Beispiel mit der Mailingliste, weil wir einfach gesagt haben, wir wollen sowas haben in Deutschland,
23:01
auch wenn das gar nicht unser Projekt war, aber dass man so Geschichten einfach irgendwo ans Laufen bekommt. Gut, am Ende ein kleines Fazit, was wir eigentlich sagen können. Die Softwareentwicklung selber, die ist eigentlich, das ist immer das, was ein bisschen im Vordergrund steht.
23:22
Aber das ist eigentlich ja wirklich nur ein relativ kleiner Teil von dem, was da eigentlich an Aufwand, an Arbeit drumherum entsteht. Und ja, um Projekte ja eigentlich wachsen lassen zu können, um wirklich vielleicht als Idealziel so ein Projekt hinzubekommen,
23:41
wie krass, was halt wirklich seit 30 Jahren läuft und sicherlich auch verschiedene Anfangsschwierigkeiten hatten. Das war ja auch gar nicht als Open Source Projekt konzipiert einmal. Da muss einfach jede Menge Arbeit reinfließen in den vielen kleinen Dingen, die wir da dargestellt haben jetzt in unserem Talk. Und mit Blick auf die Zeit hüpfe ich einfach mal weiter.
24:03
Genau, und ja, am Ende kann man sich dann fragen, wie kann ich denn selber helfen? Und ja, als Nutzer ist es so, dass man natürlich Feedback geben kann. Das hilft den Projekten immens, wenn man Fehler berichtet und sie vielleicht sogar auch schon berichtet.
24:22
Man kann anderen helfen, indem man zum Beispiel sich auf Mailinglisten beteiligt. Wenn man Nutzer ist, der sich mit der Software schon ein bisschen auskennt, dann hilft das ungemein, wenn man dann einfach anderen Leuten vielleicht dort hilft. Weil das nämlich dann wieder die Autoren, die hinter der Software stehen, halt auch einfach entlastet und die sich dann um andere Sachen kümmern können.
24:45
Dokumentation schreiben, übersetzen oder auch nur kleine Fehler finden. Das hilft da auch so ein Projekt, wenn Sie in einem Projekt die Dokumentation irgendwie merken, im Moment da fehlt was, einfach den Autoren schreiben, hier die Dokumentation, wie wäre es, wenn er das noch hinzufügt.
25:03
Und ganz wichtiger Punkt, der auch extrem einfach ist, ist Werbung machen. Also einfach darüber sprechen, welche Software Sie einsetzen, wenn Sie sich mit Kollegen treffen aus anderen Unternehmen, aus anderen Behörden. Also einfach darüber sprechen, denn am Ende sind mehr Nutzer, dann auch mehr aktive Nutzer, eventuell auch mehr Entwickler und halt auch mehr Sponsoren.
25:26
Also dass einfach dann auch mehr in die Projekte wieder zurückfließt. Das ist so ein sehr wichtiger Punkt. Und als Auftraggeber, als Sponsor, da ist es halt wichtig, wie jetzt schon öfters in dieser Konferenz angesprochen,
25:44
dass die langfristig da die Projektziele unterstützt werden und halt auch Qualität gefordert wird von den Auftraggebern und auch entsprechend finanziert wird. So dass Open Source Software halt auch langfristig eine Folge ist.
26:03
Ja und das war dann unser Einblick in was vielleicht so ein Open Source Projekt ausmacht. Und ja, wenn jetzt noch Fragen wären.
26:22
Können ja nochmal über Versionen diskutieren. Beide Fragen zuerst, dann sehen wir eben mal das Buch auf Shogun vor. Und die Vortragte eben haben wir auch gesehen, sie muss eigentlich noch von vielen mit Fragen werden.
26:49
Ist das wirklich leer als Steher? Also ich sehe viele Projekte, die gelten und genau wie schnell sie wieder... Also ein Faktor, den ich jetzt gar nicht dargestellt habe, ist, dass Shogun insgesamt natürlich eine sehr komplexe Geschichte ist.
27:02
Das heißt, die Einstiegshürde ist relativ hoch. Ich bin aber sehr, sehr froh, dass der Christian Mayer da vorne sitzt, weil der setzt das tatsächlich ein als Externer. Ist aber auch nur so halb richtig, weil als wir angefangen haben das Ding zu entwickeln, hat der Christian auch bei uns gearbeitet. Insofern kann man das auch ein bisschen in die Tasche lügen nennen.
27:24
Ich muss eigentlich sagen, nein, das haben wir nicht geschafft. Wir haben uns das vorgenommen, wir haben letztes Jahr auf der Voskis-Konferenz eine BoF gehabt zu dem Thema. Wir sind da mit Riesentraraereien, haben gesagt, super, jetzt machen wir eine Homepage, jetzt machen wir einen PSC, jetzt machen wir alles. Wir haben gestern wieder eine BoF gemacht, wir waren ehrlich zu uns selber und haben gesagt, wir haben eigentlich fast nichts erreicht.
27:44
Das ist einfach eine Schwierigkeit und aus der Konsequenz haben wir einfach gesagt, wir setzen uns jetzt gar nicht mit diesem Druck aus, um zu sagen, wir versuchen jetzt krampfhaft irgendwie ein Open Source Projekt zu relauncen oder rauszuhauen. Wir stellen den Code einfach online und gucken, was passiert. Und dann fertig. Und solange arbeiten wir als Firma natürlich weiter damit.
28:11
Also mich würde die gleiche Frage mal im Bezug auf MapProxy interessieren. Das ist ja schon eine riesen Benutzerbasis, denke ich mal. Aber wie ist die Community, die dann dahinter steht? Habt ihr da eure Ziele erreicht in den letzten Jahren?
28:26
Ich würde sagen, nein. Also da könnte deutlich mehr, gerade wenn man jetzt auf Entwicklerseite sieht, könnte da noch deutlich mehr zurückkommen. Also das Externe noch mehr entwickeln. Es gibt einige, die noch einzelne Komponenten entwickelt haben und beigetragen haben.
28:48
Es gibt dieses Code über den Soundwerfen, das ist halt wirklich ein praktisches Beispiel. Aus der Praxis kommt das, da gibt es halt oft wirklich die Entwickler, die zwar was beitragen wollen, was halt sehr gut ist, aber es ist halt nur so die Hälfte davon, was eigentlich noch gemacht werden muss, haben sie nur getan.
29:08
Und da wäre es natürlich schön, wenn da mehr kommen würde, aber es ist schwierig, das natürlich zu forcieren. Gut, vielen Dank. Die halbe Stunde ist rum. Ich denke, wir verlagern die weiteren Fragen und Diskussionen dazu in die Pause beim Kaffeetrinken.
29:26
Ihr seid ja noch den Gast des Tages da.