Собственная система документации «утечки» и как их остановить?

Question

Возможность использовать BitKeeper бесплатно была отозвана владельцем авторских прав Ларри МакВоем после того, как он заявил, что Эндрю Триджелл пересмотрел протоколы BitKeeper в нарушение лицензии BitKeeper. На Linux.Conf.Au 2005 Триджлл продемонстрировал в своем выступлении, что использованный им метод обратного инжиниринга заключался в том, чтобы просто подключиться к соответствующему порту сервера BitKeeper и ввести «help».

- [Википедия на Git] (http://en.wikipedia.org/wiki/Git_(software)#Early_history)

Иногда дело не в том, что кто-то пропускает вашу документацию или исходный код, а в том, что кто-то не помнит, чтобы удалить одну или две служебные функции. Какого рода процессы и процедуры используются для предотвращения прохождения подобных утечек?

Answer 1

Не создавая их в первую очередь.

Answer 2

Я не думаю, что вы можете просто избежать проприетарной документации, но я думаю, вы должны четко пометить ее как таковую.

Любой код, который вы пишете для внутренних целей, должен быть частью отдельного проекта и также четко обозначен.

Answer 3

Это касается связанной темы, где вы закомментируете вещи «временно».

При кодировании важно иметь процесс, который защищает вас от этого.

• При внесении изменений " временных " убедитесь, что вы их аннотировали, чтобы найти. Модульные тесты здесь превосходны.
• Убедитесь, что инфраструктура достаточно интеллектуальна, чтобы вы могли иметь различные типы сборок. Вы не хотите всегда помнить, чтобы отключить определенные вещи для определенного типа сборки. Удалите любую возможность человеческой ошибки, как только узнаете, что вы ее создаете. (По крайней мере, создайте билет для этого.)

Answer 4

Не пытайтесь помешать сторонним технологиям быть совместимыми с вашими.

Серьезно, если вам не хватает уверенности в том, чтобы позволить третьим сторонам производить совместимые замены, то подумайте, найдет ли так много людей ваш продукт в первую очередь ценным.

Answer 5

Будьте предельно осторожны с ними и следите за тем, чтобы только нужные люди получали правильную документацию (это включает в себя уверенность, что руководство не овладевает проприетарной документацией).

Я работал над настройкой некоторого проприетарного программного обеспечения, написанного моей компанией (которое основывалось на безопасности через неизвестность) для клиента. Я удостоверился, что создал две версии документа, полный технический документ проекта моей настройки, и другую с удаленными битами "безопасности", чтобы поделиться с клиентом. Я сделал ошибку, сделав это доступным для менеджмента, который поделился этим с клиентом.

К счастью, клиент ничего не сказал об этом (он задал несколько вопросов, но не стал придавать этому большого значения, я думаю, они привыкли к качеству программного обеспечения моей компании;)).