Ich habe in den letzten 5 Jahren für große und kleine Unternehmen gearbeitet. Mir ist aufgefallen, dass sich niemand, zumindest an den Stellen, an denen ich gearbeitet habe, um den Quellcode der Anwendungen kümmert. Zum Beispiel könnte ich jederzeit meinen USB-Schlüssel mitbringen und eine Kopie des gesamten Systems bekommen, einige Firmen haben es auf einen Vertrag gesetzt, dass Sie den Quellcode nicht nehmen können, aber wenn Sie Ihre Kopie nie öffentlich machen, wird das niemand bemerken Sie haben diesen Code genommen.
Meine Frage ist also, wie kann ich ein Projekt/Unternehmen organisieren, um zu verhindern, dass Entwickler den Quellcode stehlen?
Könnte das eine gute Option sein, alle nur an einem Teil der Software arbeiten zu lassen und dann den Manager dazu zu bringen, ihn zusammenzuführen und nur zu riskieren, dass der Manager eine Kopie davon bekommt? Wird beispielsweise ein Softwareentwickler, der bei Salesforce oder Adobe arbeitet, eine vollständige Kopie des Quellcodes auf seinem PC haben?
Vielen Dank :)
Zumindest müssen Sie den Entwicklern den Code zur Verfügung stellen, an dem sie arbeiten. Dies schränkt Ihre Fähigkeit ein, ihren Zugriff einzuschränken. Sie können Bibliotheken für andere Codeabschnitte bereitstellen, dies kann jedoch Hindernisse für die Behebung von Fehlern schaffen.
Es gab Fälle, in denen Mitarbeiter Code gestohlen und versucht haben, konkurrierende Dienste zu erstellen. Die mir bekannten Fälle wurden im Nachhinein erfolgreich mit rechtlichen Mitteln behandelt. Das Eigentum am Code sollte vertraglich mit denjenigen geregelt werden, die ihn verwenden. Das Urheberrecht kann ebenfalls gelten.
Abgesehen von Frameworks und Bibliotheken, die zunehmend aus der Open-Source-Community gezogen werden oder verfügbar sind, gibt es nur wenig Code, an dem ich gearbeitet habe, der für zukünftige Projekte von großem Nutzen wäre. Die von mir verwendeten internen Frameworks waren nicht so robust wie die konkurrierenden Open-Source-Frameworks.
Ich habe in restriktiven Codekontrollumgebungen gearbeitet, aber sie hatten nur Checkpoints und zukünftige Codearbeiten wurden an Codeversionen durchgeführt, die nicht aus der Codekontrollumgebung extrahiert wurden. Dies führte zu erheblichen Problemen, bei denen der Quellcode für veröffentlichte Versionen nicht abgerufen werden konnte, da er nirgendwo nachverfolgt wurde.
Wenn Manager den Code zusammenführen, wird der Zugriff auf die vollständige Kopie eingeschränkt. Es ist jedoch wahrscheinlicher, dass Manager diesen Zugriff erfolgreich nutzen können. Ich würde den Codezugriff lieber auf die Entwickler beschränken.
Die meisten Entwickler haben nur den Code, mit dem sie auf ihrem System arbeiten müssen. Dies kann ein erheblicher Teil des Systems sein, aber wahrscheinlich nicht das gesamte System. Bei guter Wiederverwendung von Code steht ihnen möglicherweise ein erheblicher Teil des Systems als Bibliotheken zur Verfügung. Größere Sites verfügen im Allgemeinen über mehrere Repositories und beschränken den Zugriff auf die Teams, die Zugriff benötigen. Code-Browser können Entwicklern ermöglichen, den Code aus anderen Projekten zu durchsuchen, die sie benötigen, um verwandte Fehler zu beheben.
Code-Locking-Systeme neigen dazu, den Entwicklungsprozess zu verschärfen. Ich habe wenig oder gar keinen Mehrwert durch Code-Locking gesehen. Gute Kommunikation und Revisionsverfolgung bieten einen erheblichen Mehrwert. Das Zusammenführen des Codes durch einen Manager scheint ein weiterer Ansatz zum Code-Locking zu sein.
Es hat Vorteile, einen Review-Prozess zu verwenden, um Änderungen in den freigegebenen Code zu integrieren. Es gibt verschiedene Ansätze, die verwendet werden können. Sie alle erfordern die Nachverfolgung von Änderungen, was den Aufwand für das Änderungsmanagement erhöht.
Todd A. Jacobs
jmort253
Bruno Quintana Fleitas