Должен ли базовый корпус быть открытым исходным кодом?

Question

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

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

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

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

С базовым случаем является открытым исходным кодом, я думаю, что будет польза:

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

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

Answer 1

Я думаю, что код с открытым исходным кодом всегда хорош (до тех пор, пока он не попадает в зависимость от прибыли, если это код, для которого может/будет выполняться спекуляция). Одно из самых больших преимуществ open-source, которое я видел, - это то, что пользователь хочет реализовать функцию, они могут сделать это сами. Это также дает покупателям элемент гордости - если вы помогли что-то сделать, зачем использовать что-то еще?

С деловой точки зрения, вот некоторые методы, чтобы получить деньги, по-прежнему получать выгоду от открытого источника:

• Если вы беспокоитесь о конкурентах с помощью кода, написать пользовательскую лицензию, которая позволяет но никто больше не может повторно использовать код в проприетарном приложении. Например, вы можете лицензировать в GPLv3, но с дополнительными предложениями, которые позволяют использовать его, как если бы это было в соответствии с условиями LGPL, и которые позволяют интегрировать код с другими продуктами GPL (чтобы их можно было смешивать, важно часть OSS). Это позволяет вам получать прибыль, но не ваши конкуренты, в то время как выгоды сообщества.
• Двойное лицензирование похоже на пункт №1, но это затрудняет использование кода, представленного пользователями (поскольку он будет связан лицензией OSS и только этим). Вы могли бы также гибридизировать подход, который был бы полезен, если вы намереваетесь продавать библиотеку коммерчески.
• Вместо того, чтобы продавать только код, продавать другую недвижимость. Я знаю об одной игре, которая была успешной (насколько это нишевая инди-игра, в любом случае) путем открытого поиска кода, но продажи графики и наборов уровней.