Как поделиться компьютерным кодом?

Я пишу бумагу с моим советником. Некоторые из ключевых вкладов нашей статьи включают в себя:

  1. Компьютерная имитационная модель системы инвентаризации
  2. Набор имитационных экспериментов и результатов для проверки имитационной модели.
  3. Реализация политики инвентаризации, которую мы предлагаем
  4. Результаты моделирования предлагаемой нами политики инвентаризации и политики инвентаризации, которые в настоящее время используются на практике.

Мы хотим сделать наш компьютерный код свободно доступным для других. Имитационная модель была написана на языке программирования Java, поэтому другие исследователи смогут довольно легко запускать код на своих компьютерах. Делясь нашим компьютерным кодом, мы надеемся, что другие исследователи разработают политику инвентаризации, которую они смогут протестировать с помощью нашей имитационной модели. (Конечно, нам было бы выгодно, если бы они сделали это и процитировали нас в своей статье!)

Вопрос: Как лучше всего поделиться нашим компьютерным кодом?

  1. Где разместить код?
  2. Под какой лицензией на программное обеспечение мы должны «опубликовать» код?
  3. Как сделать так, чтобы другим людям было легко запускать код?
О «выборе лицензии на ПО»: приглашаю всех заглянуть на tldrlegal.com
А скриншоты или (что еще лучше) рабочие примеры в сети (без установки) творят чудеса .
Лицензии CC не должны использоваться для программного обеспечения. Это прискорбно, поскольку для программного обеспечения нет столь же четких правил выбора лицензии. Choosealicense.com или tldrlegal.com должны помочь вам выбрать.
@ТимС. Есть одно исключение: лицензия CC0 может использоваться для программного обеспечения. Это простая разрешительная лицензия.
Не имеет отношения к вам, но IPOL — это журнал по обработке изображений, в котором вас просят опубликовать реализованный код вместе с документом таким образом, чтобы любой мог протестировать его вживую: проверьте это: ipol.im (перейдите к любой статье , чтобы проверить его код за считанные минуты).
Вас может заинтересовать инициатива Software Heritage: softwareheritage.org

Ответы (8)

Ответ на 1: Где я должен разместить свой код?

В зависимости от того, что предлагает вам ваш университет, вы можете разместить его в университете или, возможно, в репозитории с открытым исходным кодом, таком как Github, Bitbucket, SourceForge или аналогичный.

Многие из этих сервисов имеют вариант «платной» подписки на частные репозитории, если они необходимы.

Ответ на 2: Какую лицензию с открытым исходным кодом мне выбрать?

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

Хотя существует множество лицензий с открытым исходным кодом, в действительности они делятся на два основных семейства. Это либо разрешительные открытые лицензии (например, MIT, BSD, Apache), либо бесплатные (GNU Public License v2 или GPLv3). Вот краткий обзор Инициативы с открытым исходным кодом

Разрешающие открытые лицензии Эти лицензии обычно позволяют вам выпускать свой код, и любой может делать с ними все, что захочет, при условии, что они сохраняют определенную информацию об авторских правах с кодом. На самом деле это имеет ряд последствий.

  1. Кто-то может взять всю вашу кодовую базу, создать на ее основе продукт и продать его.

  2. Кто-то может взять части вашего кода и поместить в свой проект (коммерческий или нет).

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

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

С другой стороны, GNU GPL — это лицензия свободного программного обеспечения, которая запрещает вам делать определенные вещи. В этом смысле он более ограничителен, но по ряду идеологических причин.

  1. Если вы выпускаете программное обеспечение под лицензией GPL, вы не можете закрыть его исходный код. Всегда. Он останется открытым, и если кто-то попросит у вас исходный код, вы обязаны по условиям лицензии предоставить его (если вы размещаете его на Github или другом публичном репозитории, то вы уже выполнили это требование).

  2. Компания может взять код, создавать с его помощью продукты и продавать его (это их право на это), но они должны будут делать это при условии, что любой исходный код, который они пишут для проекта, также выпускается под лицензией GPL. Из-за этого многим компаниям, которые зарабатывают много денег на написании программного обеспечения, это не нравится, потому что им приходится постоянно публиковать код. С другой стороны, любые крутые вещи, которые они делают, публикуются под лицензией GPL, так что вы можете добавить их обратно в свой проект и улучшить. Они не могут взять ваш код, улучшить его и больше никогда им не делиться.

  3. Если вам довелось использовать какой-либо код GPL в своем проекте (скажем, вы взяли несколько строк из ядра Linux или системы управления версиями Git или чего-то еще), тогда вам также придется выпустить свой код под лицензией GPL.

В конце концов, выбор лицензии больше влияет на то, как вы хотите, чтобы программное обеспечение использовалось (и, в конечном итоге, на сообщество, которое оно может привлечь). Если вы планируете коммерциализировать программное обеспечение (и неявно разрешать другим делать то же самое), вы можете использовать BSD. Если вы не хотите, чтобы люди брали на себя вашу тяжелую работу и получали от нее прибыль, не показывая вам результатов, тогда вы хотите перейти на GPL. Если вам все равно в любом случае, то вы, вероятно, могли бы просто выбрать один. Я думаю, что BSD популярен в академических кругах именно из-за аспекта коммерциализации (например, LLVM набирает обороты из-за разрешительной лицензии).

Ответ для 3: Как сделать так, чтобы другим было легко запускать код?

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

Упаковка/распространение на самом деле может быть довольно сложной задачей и обычно требует больше усилий, чем думает большинство людей. Хороший способ упростить работу программного обеспечения — протестировать его на нескольких машинах. Убедитесь, что вы не забыли ни одну из библиотек, которые вы используете, например, в своем программном проекте, и, когда это возможно, старайтесь использовать распространенные и хорошо поддерживаемые программные библиотеки. Используйте основные языки с простыми в управлении репозиториями пакетов.

При необходимости используйте программы установки, сценарии установки, Makefiles (лучше использовать distutils, который использует automake/autoconf) и т. д. Даже сценарии оболочки лучше, чем ничего. Если вы можете предоставить двоичные файлы и/или установщик, это еще больше упростит задачу. Проблема в том, что это МНОГО работы!

Сопровождайте его документацией. В идеале документация должна содержать описание того, как его настроить и запустить, с описаниями необходимых пакетов/библиотек, данными, которые вам, возможно, придется получить, и что вводить или нажимать. Обычно внимание привлекает то, что называется README или INSTALL. Также поместите инструкции на веб-страницу, большинство хостинговых решений также позволяют вам иметь веб-страницы.

Надеюсь, это все поможет. Самая сложная часть процесса — это, безусловно, шаг № 3, и большинство людей не доходят до использования хороших методов, таких как установщики, automake/autoconf и т. д., потому что это МНОГО работы, и разработка часто продвигается быстрее, чем вы можете. писать документы. Тем не менее, никто не оценивает ваш стиль, поэтому зачастую проще избавиться от него, чем сначала привести его в порядок и приукрасить.

Что касается вашей части платных подписок: у Bitbucket есть бесплатный план только для ученых, который дает вам неограниченное количество бесплатных частных репозиториев.
Какую бы лицензию вы ни выбрали, вы всегда можете сами использовать ее так, как вам удобно, ведь вы являетесь правообладателем. Это означает, что вы можете использовать его в проекте с закрытым исходным кодом, даже если вы выбрали GPL в качестве лицензии.
Имейте в виду, что GPL — неисключительная лицензия. Поэтому, если вы являетесь владельцем авторских прав (осторожно: если вам платят за вашу работу, во многих юрисдикциях работодатель владеет авторскими правами!) вы можете в дополнение к бесплатной и открытой версии GPLd предоставить несвободные, закрытые версии. Т.е. GPL вашего кода по-прежнему позволяет вам продавать несвободные/закрытые лицензии, например, компании, которая хочет использовать ваш код в своем несвободном/закрытом продукте. (Конечно, только если у вас нет стороннего программного обеспечения с лицензией, запрещающей это)
Если вы выпускаете программное обеспечение под лицензией GPL, вы не можете закрыть его исходный код. Всегда. Он останется открытым, и если кто-то попросит у вас исходный код, вы обязаны по условиям лицензии предоставить его . Это неверно. Если вы выпускаете свое собственное программное обеспечение под лицензией GPL, вы можете перелицензировать его в любое время. Другим по-прежнему разрешено распространять ваше программное обеспечение, опубликованное под GPL, и его исходный код, но у вас нет никаких обязательств, и вы также можете решить, что с определенного момента новые версии больше не являются GPL.
Под пунктом 1 я бы добавил примечание о важности использования системы, которая архивирует ваш код. Например, zenodo интегрируется с github для обеспечения надлежащего архивирования выпусков github. Это необходимо для академической работы. guides.github.com/activities/citable-code
«Это либо разрешающие открытые лицензии [...], либо они бесплатные [...]». Неа. Свободная лицензия может быть разрешающей или с авторским левом . Любая разрешительная лицензия является свободной лицензией. Данная лицензия является бесплатной, если пользователю предоставлены четыре основные свободы , определенные Free Software Foundation .
На самом деле, если вы планируете коммерциализировать свое собственное программное обеспечение, GPL дает вам значительно больше коммерческих преимуществ, чем лицензия BSD/MIT. В то время как GPL не позволяет вашим конкурентам добавлять функции в код без передачи исходного кода (что позволяет вам распространять его вместе с вашим кодом под GPL), вы, как владелец кода, не имеете таких ограничений для своего собственного кода и можете продавать функции, для которых вы не отдаете источник.
В те дни, когда Docker не существовало, распространять «исполняемый код» было очень сложно. Тем не менее, я бы посоветовал ОП взглянуть на Docker как на потенциальный способ распространения исполняемого кода в виде образа докера, который люди могут выполнять без установки чего-либо, кроме Docker Engine.
Осторожный! Пока код принадлежит вам, вы можете делать с ним все, что пожелаете, в будущем. Т.е. выпустить версию 1 с открытым исходным кодом, изменить ее и закрыть как версию 2. Версия 1 является открытой и остается такой. Также убедитесь, что код принадлежит вам. Если это часть исследовательского проекта, тот, кто предоставил деньги, вероятно, имеет права на результаты. Если вы были наняты проектом, проект является владельцем того, что вы написали. По крайней мере, здесь, в Чили, по закону все, что вы разрабатываете в рамках своего образования, принадлежит вашей школе.

В некоторой степени ответ будет зависеть от того, чего вы хотите достичь с помощью этого релиза. Недавно на эту тему был фантастический пост в блоге.

Если код в отличной форме, и вы надеетесь, что другие будут использовать его, то выбор лицензии будет отражать вашу философию. Лицензия в стиле BSD, если вы просто хотите, чтобы алгоритм и код были опубликованы, или, возможно, лицензия в стиле авторского лева (GPL), если вы хотите, чтобы улучшения возвращались в общее пользование.

Если код не в такой хорошей форме, но ради прозрачности должен быть там, рассмотрите что-нибудь вроде CRAPL , который признает беспорядочный характер современных вычислительных наук. Думаю, стоит процитировать преамбулу:

I. Preamble

Science thrives on openness.

In modern science, it is often infeasible to replicate claims without
access to the software underlying those claims.

Let's all be honest: when scientists write code, aesthetics and
software engineering principles take a back seat to having running,
working code before a deadline.

So, let's release the ugly.  And, let's be proud of that.

Что касается реальной механики размещения кода, используйте GitHub или Bitbucket . Эти сервисы предоставят вам хостинг кода, дом для проекта, возможность управлять вкладом и возможность отслеживать ошибки и проблемы.

В качестве дополнения, и Github, и Bitbucket предлагают академические учетные записи, если вы регистрируетесь с институциональным адресом электронной почты. Таким образом, вам даже не придется путать свою обычную учетную запись, если она у вас уже есть.
Что-то, что можно использовать в сочетании с github и bitbucket, это readthedocs ( readthedocs.org ). Это позволит вам создать хороший сайт с документацией по коду, инструкциями по установке и т. д. Очень полезный сайт.
Я бы предостерег от лицензий с авторским левом (если только у кого-то нет веских причин для этого). Это де-факто ограничительно, так как не каждый продукт может его использовать.
@PiotrMigdal: пока это неисключительная лицензия (например, GPL) и исходное авторское право находится в одних руках, авторское лево не проблема: вы (или, скорее, ваш работодатель/университет) можете дополнительно лицензировать его по различные термины для тех, кто нуждается в специальных терминах. Это часто становится проблемой, если у вас есть несколько владельцев авторских прав на части кода. Я бы уделил больше внимания тому, чтобы иметь аналогичную лицензию на «окружающее» программное обеспечение (например, для пакета R авторское лево вполне разумно, даже если это еще не требуется из-за зависимостей пакетов с авторским левом)
@cbeleites Это неисключительно, но как только другие люди начинают вносить свой вклад (и это одна из целей открытых лицензий), чтобы поставить другую лицензию на новый контент, AFAIK, требуется согласие каждого участника. Если проект в какой-то степени успешен, он фактически становится невозможным. Я не утверждаю, что люди не должны использовать GPL (конечно, есть варианты использования); просто его последствия менее тривиальны, чем может себе представить новичок в открытом программном обеспечении (самое главное, что авторское лево не является самым разрешительным ).

Мэтью Г. и Ирвин дали отличные ответы, но я хотел бы предоставить некоторые дополнительные ресурсы и ссылки для тех, кто заинтересован.

Во-первых, взгляните на ответы на этот похожий вопрос на sccomp.SE:

Какие материалы я должен включить в журнальную статью (или опубликовать в Интернете), чтобы мои вычислительные исследования можно было воспроизвести?

Воспроизводимость была предметом семинара 2012 года в ICERM ; вы найдете много полезного материала на вики и в окончательном отчете (особенно см. приложения D, E и F).

Архив/хостинг

Обновление : вы можете получить DOI и постоянный хостинг для моментального снимка вашего кода через Figshare или Zenodo .

Лицензирование

См. этот раздел вики для обширного списка ресурсов .

Упрощение запуска кода

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

  • ActivePapers : ActivePaper — это отдельный файл, содержащий все программное обеспечение и наборы данных, связанные с исследовательским проектом.
  • RunMyCode : эта услуга основана на инновационной концепции веб-сайта-компаньона, связанного с научной публикацией.

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

Может быть полезно поместить ваш код в формат рабочего листа , где вы можете вставлять комментарии и даже математические формулы (например, используя блокнот IPython или рабочий лист Sage. Вот пример .

Примеры

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

+1 за упоминание виртуальных машин. Я думаю, что это имеет большое значение для ряда дисциплин, где воспроизведение исторически было трудным.

Я рекомендую гитхаб.

Другие данные ответы хорошо детализированы и включают его, но с учетом множества других вариантов. Выбор явно хороший. Без конкретных преимуществ, хотя я предлагаю вам просто использовать github.

Мое обоснование заключается в том, что я чувствую, что github стал явным лидером в области хранения и обмена кодом. Это базовая технология git, поскольку современная система dvcs в значительной степени заменила более старые технологии, такие как svn. Сейчас у него более 2,8 миллиона пользователей, что весьма впечатляет.

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

Github позволяет вам иметь как общедоступные (любой может просматривать), так и частные репозитории, доступ к которым вы контролируете. Для обновления вы добавляете запрошенные ssh-ключи пользователей, чтобы предоставить доступ к обновлению.

Все ответы выше великолепны. Я просто хотел бы добавить, что если вы планируете опубликовать его на веб-сайте своей лаборатории или на любом личном веб-сайте, вам также следует скопировать его куда-нибудь еще.

Во многих областях оказывается, что данные ( включая исходные программы ) постоянно исчезают. Когда лаборатория переезжает в другой университет, закрывается или подвергается какой-либо реструктуризации, ее веб-сайт, скорее всего, изменится, а хранящиеся там данные могут быть утеряны. Поэтому, если в вашем университете нет централизованного репозитория, вы должны разместить свой код там, где он может храниться десятилетиями, например, на Github.

На мой взгляд, это связано с конкретным кодом, которым вы хотите поделиться.

Я просто хочу привести пример кода JavaScript, которым вы можете поделиться на http://jsfiddle.net/. Мы можем протестировать наш JavaScript, CSS, HTML или CoffeeScript онлайн в Интернете. Существует также возможность пригласить людей для совместной разработки нашего кода.

Удачи.

Хорошая точка; Добро пожаловать в academia.SE!

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

В наши дни вы, вероятно, поместите его на какой-нибудь сервер, где все те, у кого есть доступ к бумаге, могут получить доступ к коду, и никто другой.
Конечно, вам нужно выяснить, кто это будет. Большинство исследовательских работ считаются секретами компании (или секретами отдела) и не предназначены для публичного распространения. Ваш код подпадает под те же ограничения.
Просто разместив его на github, google code или source forge без предварительного разрешения ваших работодателей/координаторов, вы не получите много друзей, на самом деле вы можете получить довольно солидный иск о возмещении ущерба и/или тюремном заключении. для этого.

Возможно. Имейте в виду, что с github вы можете иметь общедоступный репозиторий, который эффективно «выбрасывает ваш код». Однако у Github также есть частные репозитории, доступ к которым вы контролируете с помощью ключей ssh.
Я категорически не согласен с вашим мнением о доступе к коду. Если это научно-исследовательская работа, вы по определению хотите, чтобы ее прочитало как можно больше людей. Как ученые и исследователи, я считаю, что мы обязаны обеспечить воспроизводимость опубликованных результатов исследований. Если программное обеспечение, которое мы разрабатываем, отвечает за эти результаты, мы должны опубликовать это программное обеспечение вместе с статьей. В противном случае результаты не имеют большого значения.
@ThomasArildsen, это хорошо в теории. На практике многие научные исследования подпадают под NDA и режимы безопасности, которые делают невозможным публичное раскрытие информации в течение длительного времени после завершения проекта и/или без предварительного разрешения финансирующей его организации.
@jwenting Очень жаль, когда требования спонсоров ограничивают исследования таким образом, и я думаю, что мы должны стараться избегать этого, насколько это возможно. В двух последних исследовательских проектах, в которых я участвовал, на получение грантов положительно повлиял тот факт, что мы обещали опубликовать весь код.
@ThomasArildsen да и нет. Поскольку результаты ваших исследований (и/или серьезные политические последствия) часто связаны с серьезными коммерческими стимулами, безопасность, если это часто необходимо, ради тех, кто финансирует программу. Да, невозможность поговорить об этом с кем угодно, не заставив этого человека подписать соглашение о неразглашении, также может задержать или предотвратить поступление идей в команду, но без этого процесса часто не было бы команды вообще.

В различных ответах есть много хороших советов; Я остановлюсь только на пункте 3: «Как сделать так, чтобы другим людям было легко запускать код?»

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

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

Каждый раз, когда вы делаете новую проверку или клонируете свой репозиторий, начните с запуска тестового сценария. Когда он достигает первой ошибки любого рода, подумайте, как вы могли бы настроить сценарий, чтобы избавиться от этой ошибки (если это легко сделать) или определить состояние ошибки и дать пользователю какое-либо информативное сообщение. Например, если вы зависите от libfrozzitналичия его заголовочных файлов для компиляции, вы, возможно, не сможете установить его, но вы можете, по крайней мере, попытаться проверить его наличие и, если он отсутствует, завершиться ошибкой с сообщением «libfrozzit not found . Установить с помощью apt-get frozzit-dev или yum install frozzit-devel?"

Напишите тесты любого типа, будь то базовые модульные тесты или функциональные тесты, для вашего кода. Даже если вы выберете самую простую функцию и отправите через нее одно значение или запустите myprogram --helpее и убедитесь, что она печатает какое-либо сообщение, это означает, что вы запустили тестовую среду и значительно упрощаете для кого-то другого добавить тест. Если вы можете достичь, скажем, 5% тестового покрытия вашего кода, это значительное преимущество, потому что даже это будет большим подспорьем для тех, кто задается вопросом, правильно ли построен код.

Упрощение создания и запуска кода для других — это не волшебство, и его нельзя сделать взмахом палочки или запуском специального инструмента. Дело в том, что каждый раз, когда вы обнаруживаете, что выполняете ручную настройку, чтобы заставить что-то работать, независимо от того, насколько она проста, спрашиваете себя: «Как бы я автоматизировал необходимость этой ручной настройки»?

Как поделиться компьютерным кодом?
СпросиСетьПолитика конфиденциальности1y, 0v