Як я переконаю свою компанію внести свій внесок у відкриті джерела?

Я намагаюся переконати компанію, над якою працюю, щоб внести свій внесок у створення програмного забезпечення з відкритим кодом, зокрема створення бібліотеки / компонента для веб-додатків ASP.NET. У нас з'являється "День інновацій", де ми можемо працювати над своїми особистими проектами для домашніх тварин на роботі, подібно до політики Google один день на тиждень, окрім нашої це один раз на місяць :-), і у мене є ідея, яку я хочу зробити відкрите джерело.

Інші компанії роблять це, наприклад. Системи Headspring ( http://automapper.codeplex.com - див. Банер вгорі).

Що я їм кажу? Які переваги я можу їм передати, що було б корисно для компанії? Я вже згадував про можливу експозицію нашої компанії та репутацію тощо, а також про те, щоб залучити провідних розробників програмного забезпечення, коли ми в наступний раз працюємо над наймом. Але які ще аргументи я можу зробити?

Оновлення: Компанія, в якій я працюю, - це програмне забезпечення, яке в основному будує веб-додатки в ASP.NET та MS Stack. Нашими клієнтами є в основному NHS (сектор охорони здоров'я Великобританії).

open-source asp.net contribution

— Недільна залізна стопа
джерело

Знайдіть існуючий проект з відкритим кодом, який ви модифікуєте. Тоді те, що випускаєте, має бути з відкритим кодом. Напевно, вже є щось, що може бути корисним, але просто потрібно налаштувати, щоб відповідати потребам вашої компанії.

— Macneil

Чи є ваша компанія технологічною компанією - наприклад, ви розробляєте та продаєте технології? Я думаю, що простіше аргументувати в технічній компанії, оскільки у вас є мотив прибутку для просування конкретних платформ; наприклад, Engine Yard найняв розробників JRuby для просування екосистеми Ruby в цілому, оскільки це принесе їм більше бізнесу. Якщо ваша компанія є кінцевим споживачем технологій, я думаю, ви пояснили найкращі аргументи.

— Джеремі

@ Джеремі: Так, вибачте, я, мабуть, згадав, що ми є програмною компанією, яка в основному будує веб-додатки в ASP.NET і на стеку Microsoft.

— Неділя Ironfoot

Macneil, це слід додати як відповідь, а не коментар.

— Пітер Бауфтон

@ Peter: Дякую, хоча я сумніваюся, що це насправді аргумент, який потрібно зробити компанії. Більш просто особливі обставини. У наукових колах ми часто розробляємо відкритий код, щоб ми могли збільшити вплив та не допустити різних організацій управління взяти під контроль наш код. Я знаю деяких професорів, які мають патенти на свою роботу, хоча вони протестували!

— Macneil

Відповіді:

Ви повинні скласти діловий випадок. Я робив це раніше, маючи на увазі, що інтелектуальна власність, яку ми будемо відкривати, не є основним комерційним активом (не розмежувало нас), але, випустивши код, ми створили б маркетинговий канал для Користувачі цього відкритого коду, які також є нашою цільовою аудиторією.

Ви можете використовувати цю теорію: " Компонізуйте свої комплекси "

— Скотт Вітлок
джерело

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

— Пол Дрейпер

Компонент з відкритим кодом має сенс, якщо - і лише якщо - ви розвиваєте проект і створюєте спільноту. Приймайте звіти про помилки, виправляйте помилки та регулярно робіть нові випуски. Якщо ви це зробите, як це зробили Eclipse і Mozilla, ви можете отримати користь.

Якщо цього не зробити, досвідчені люди можуть запахнути милою, що ви просто скинули з кодової бази, сподіваючись, що інші зроблять роботу за вас.

Ми б не очікували, що інші люди виконають всю роботу. Ми, ймовірно, будемо повністю розробити компонент, а потім відкрити його, дозволяючи іншим отримувати користь від нього або розвивати його далі, якщо бажаємо.

— неділя Ironfoot

Але чи підтримували б ви це тоді?

Ну, один з найбільших аргументів для відкритого коду полягає в тому, що інші можуть зробити свій внесок у нього, ідея полягає в тому, що один програміст не може сподіватися помітити і виправити 1000 помилок у своїй програмі, але 1000 програмістів можуть. Отже, крім усіх перелічених вами переваг, це зрозуміло вибір для розробки програмного забезпечення для завантаження, яке певним чином допомагає вашому власному бізнесу.

Це також ставить вас у позицію влади. Я можу це трохи розтягнути, але якщо ваша ідея досить інноваційна, ви можете створити новий стандарт, за яким повинні відповідати інші. Це означає, що кожен, хто хоче зробити що-небудь із вашим програмним забезпеченням для комерційного використання, повинен запитати вас спочатку, це означає, що ви можете кинути кілька кривих кульок, які говорять, що, хоча код відкритий, використання вашого стандарту для комерційного використання вимагає невеликого внеску, який це зовсім нерозумно, тому він має потенціал і на більш пізніх стадіях.

— Ніл
джерело

Обмеження комерційного використання коду несумісне з принципами Ініціативи з відкритим кодом та Фонду вільного програмного забезпечення. У більшості випадків я думаю, що це може спричинити більше проблем із громадою, ніж це варто. Якщо ви дійсно хочете, щоб тисяча програмістів шукала код, використовуйте ліцензію, сертифіковану OSI.

— Девід Торнлі

Ви впевнені в цьому? Я розумів, що ліцензія з відкритим кодом дозволяє кожному бачити код вільно, але це нічого не говорить про продукти, вироблені з такого коду.

— Ніл

Я повністю впевнений у цьому і згадав Ініціативу з відкритим кодом та їхні ліцензії, щоб уникнути типової плутанини. "Open Source" - неоднозначна фраза. Одне значення полягає в тому, що ви можете отримати джерело, незалежно від того, що ви можете з ним зробити. Один ліцензується ліцензіями, сертифікованими OSI, і саме це зазвичай мається на увазі, якщо ця фраза використовується з великої літери. Якщо ви хочете залучити громаду, перейдіть до визначення OSI. Набагато менше людей будуть зацікавлені допомогти у чомусь, що не має ліцензії типу OSI.

— Девід Торнлі