<anchor xmlns="http://www.tei-c.org/ns/1.0" xml:id="id_docs-internal-guid-7fc26155-7fff-fae1-9917-aaeb0b80f00a" />Auffallend ist, dass sich der deutliche Bruch in der Organisation der Entwicklung (von zwei Hauptentwicklern aus derselben Institution hin zu einer internationalen Community) kaum in der Bewertung auswirkt. Obschon nicht explizit ausgeführt, würden sich die Kennzahlen kaum ändern, wenn man diese beiden Zeiträume getrennt auswerten würde. Dies mag zum einen daran liegen, dass die Community-Edition noch relativ jung ist und daher zeitlich noch keine signifikanten Änderungen bewirken konnte. Es fällt aber auf, dass die Art, wie die Entwicklung eines Softwareprojekts organisiert ist, insgesamt eine eher untergeordnete Rolle bei den Kriterien von Anzt et al. spielt. Betrachtet man die Umstellung von einer Inhouse-Lösung zur Open Source-Community mit Hilfe der Ökosystem-Kriterien von Stürmer et al., so schlägt der Systemwechsel stärker zu Buche. Eine offene Lizenzierung gab es in beiden Fällen, die übrigen vier Punkte “Shared tacit knowledge”, “Participatory culture”, “Good governance” und “Diversified funding” sind jedoch bei der Open Source-Community in wesentlich stärkerem Maße als bei der Inhouse-Lösung oder überhaupt erst erfüllt. Dies lässt hoffen, dass MerMEId als Community-Projekt nun gut aufgestellt ist, um nachhaltig weiterentwickelt zu werden. Allerdings werden bei Stürmer et al. als Open Source-Beispiele die Entwicklung des Linux-Kernels und Bitcoin diskutiert. Die Communities sind in diesen Fällen wesentlich größer und daher voraussichtlich stabiler als bei MerMEId, wo im jetzigen anfänglichen Stadium der Community-Entwicklung eine gute “Governance”, also eine gewisse Leitung und Steuerung der Community-Prozesse, noch sehr wichtig ist.