Soll interner Code für Nichtentwickler in einer Organisation freigegeben werden?

Wo ich arbeite, haben wir viele Entwickler und eine Menge Code, der unsere proprietären Anwendungen ausführt, die von Mitarbeitern und Kunden gleichermaßen verwendet werden.

Wir haben auch eine Menge kluger Support-Mitarbeiter, die gerne die Funktionsweise unserer Systeme verstehen, um unsere Kunden besser zu unterstützen, und von Zeit zu Zeit sogar einen Patch einreichen.

Sollten wir unseren Code öffnen, damit unsere Mitarbeiter, die keine Entwickler sind, lesen können? Welche Faktoren sollten wir bei dieser Entscheidung berücksichtigen? Ich bin auf jede Art und Weise auf eine Reihe von Argumenten und Gegenargumenten gestoßen und möchte eine Entscheidung treffen, die auf den Erfahrungen anderer sowie auf gut verstandenen Risiken basiert.

Einige Argumente bisher:

• Passwörter in VCS werden angezeigt (Lösung: Passwörter entfernen - sie sollten nicht vorhanden sein)
• Code ist offen für White-Box-Sicherheitsangriffe (Gegenargument: dies hält nur die ehrlichen / faulen Angreifer fern)
• Support-Mitarbeiter können Entwickler fragen, "wie" die Dinge funktionieren (Zähler: Bringen Sie einem Mann das Fischen bei, usw.)

Öffnet jemand seinen Code für Mitarbeiter in seiner Organisation? Hat es irgendwelche Probleme verursacht?

Ich glaube nicht, dass es eine allgemeine Antwort darauf gibt. Unternehmen unterscheiden sich in ihrer Größe, geografischen Verbreitung, Unternehmenskultur, Copyright-Richtlinien, Art der zu entwickelnden Software usw. usw.

Zum Beispiel kann es für ein Unternehmen, das Software für Standard- und Infrastrukturanwendungen entwickelt, einfach sein, den Quellcode zu öffnen, auch wenn es sich um Open Source handelt, wie es Cisco vor einigen Jahren mit seiner Druckertreibersoftware (IIRC) getan hat.

Für ein Unternehmen, das eine seltene proprietäre Software entwickelt, die möglicherweise spezielle Algorithmen oder ähnliches enthält, was ihnen einen Wettbewerbsvorteil gegenüber der Konkurrenz verschafft, kann ich sehr gut nachvollziehen, ob sie bestrebt sind, ihren Code geheim zu halten. Beispielsweise begrenzt AFAIK Google die Anzahl der Personen, denen der Zugriff auf ihre Kern-Suchalgorithmus-Implementierung gewährt wird, sehr streng.

Auch eine multinationale Organisation ist heutzutage über viele Länder, Zeitzonen und Kulturen verteilt. Aus Sicherheitsgründen segmentieren sie wahrscheinlich ihr Intranet und verwenden Firewalls, um den Datenverkehr zwischen verschiedenen Segmenten / Domänen zu steuern. Ein SCM-Repo für "das gesamte Unternehmen" zugänglich zu machen, kann in der Tat eine Menge zusätzlicher Arbeit für Sysadmins und ein zusätzliches Sicherheitsrisiko erfordern. Obwohl dies im Allgemeinen keinen Nutzen bringt, wissen Arbeitgeber, die auf einem anderen Kontinent an ganz anderen Themen arbeiten, wahrscheinlich nicht einmal über unser Projekt Bescheid, geschweige denn, um einen positiven Beitrag dazu zu leisten.

Wenn es also in Ihrer Abteilung und / oder für Personen, die in irgendeiner Weise mit dem Projekt verbunden sind, Sinn macht , warum nicht? Aber im Allgemeinen bin ich mir nicht ganz sicher, ob es sich lohnt, nur um der "Offenheit" willen.

Ein letzter Hinweis: Selbst wenn Support-Mitarbeiter klug sind und gerne Patches beisteuern, würde ich sagen, dass ihre Beiträge immer von einem Entwickler überprüft werden sollten, bevor sie in das System integriert werden.

In den meisten Organisationen, in denen ich gearbeitet habe, stand das Code-Repository allen Entwicklern offen.

In einigen Fällen wurde es auch zum Speichern von Dokumenten (z. B. Spezifikationen und Anforderungen) verwendet, um sie neben der Software zu versionieren. In diesem Fall hatten auch die meisten anderen Mitarbeiter Zugriff. Wo das Repo nur für Code verwendet wurde, hatten Nicht-Entwickler normalerweise keinen Zugriff - aber ich hörte nie jemanden, der sich beschwerte, also war es wahrscheinlich auch keine große Sache.

Ich würde so viel Offenheit wie möglich empfehlen. Wenn also Leute Zugang wünschen, geben Sie es ihnen, es sei denn, es gibt ein offensichtliches Problem. Aber das ist wirklich eine Frage der Kultur der Organisation ...

Ich teile diesbezüglich eine allgemeine / pragmatische Ansicht und kann auch von der Art der Arbeit / Organisation abhängen. Aber ich glaube, dass die Codebasis für alle offen sein sollte (dies wird auch Offenheit und Vertrauen innerhalb der Organisation zeigen).

Ich arbeite auch in einem ähnlichen Setup wie Sie, in dem wir ein Suppor / Helpdesk-Team haben, das sich um Kundenanfragen kümmert. Bestimmte komplexe Bereiche des Systems erfordern jedoch zusätzliche Hilfe. In meinem Fall ist die Codebasis offen für alle, bei denen wir keine Probleme festgestellt haben.

• Ich denke, durch das Öffnen der Codebasis können andere Mitglieder des Supportteams, die daran interessiert sind, auch die Codebasis durchsuchen und sich mit den Geschäftsregeln / -bereichen vertraut machen, an denen sie interessiert sind oder die Antworten suchen müssen (und möglicherweise ihr technisches Verständnis verbessern und sich etwas ansehen) anders als die monotone Routine, wenn es die Zeit erlaubt;)). Dies kann sich auch als nützlich erweisen, wenn Mitglieder des Support-Teams Kundenprobleme und Protokolle erhalten und in der Lage sind, auf mögliche Bereiche des Codes zu verweisen / zu helfen, in denen dies geschieht, indem sie sich beispielsweise die Stapelverfolgung ansehen (dies hängt natürlich vom Problem usw. ab). Das spart auch Zeit für den Entwickler, aber je nach Problem natürlich.

Eine aktuelle Dokumentation / Wiki des Produkts, die alle Geschäftsregeln / -entscheidungen enthält, ist ebenfalls hilfreich. Aber natürlich müssen Sie sicherstellen, dass das Wiki ständig aktualisiert wird, um neue Verbesserungen und / oder Fehlerbehebungen (bei Verhaltensänderungen) zu korrigieren. Meine ehrlichen Gedanken

Aus organisatorischer Sicht: Menschen kommen und gehen. Das Projekt (oder Produkt) muss sich weiterentwickeln. Daher gibt es in den meisten Organisationen normalerweise ein "Offen für alle Repositorys", um den Code zu verwalten.

Normalerweise gibt es Zugriffsrechte usw., um einen unbefugten Zugriff zu verhindern (um Code-Diebstahl usw. zu verhindern), aber die meisten höheren Versionen sind nicht wirklich daran gehindert. Innerhalb einer Organisation muss man Leuten (genug) vertrauen, dass man ihnen Code anvertrauen kann. Das Verbergen von Code vor Mitarbeitern (oder Kollegen) ist ein großer entmotivierender Faktor.

In unserer Organisation haben Leute, auch wenn sie nicht wirklich zum Code beitragen, direkten Zugriff auf Code, der hilft, weil sie versuchen, die Probleme vor Ort (mit Eigentumsrechten) zu bekämpfen / zu beheben, anstatt die Dinge zurück an den Entwickler zu werfen und einzuschlafen!