Що потрібно зробити перед тим, як викласти код відкритого програмного забезпечення

Викласти проект з відкритим програмним кодом – це більше, ніж викласти код в Інтернеті.

Інтерес до програмних продуктів з відкритим вихідним кодом зростає останні 10 років. Linux стоїть і в пральних машинах, і в бойових дронах. Більшість програмістів не можуть уявити своє життя без широкого асортименту безкоштовних і відкритих інструментів у своєму розпорядженні.

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

Чим ви можете допомогти своїм проектом, щоб його помітили?



Перед тим, як відкрити який-небудь код, я відповідаю на питання, які виклав в цій статті. Але не обов'язково в такому ж порядку.

Ви можете слідувати кожному пункту чеклиста, а можете тільки його частини. Пам'ятайте про мету – допомогти іншим дізнатися про ваш проект, швидко розібратися, як його використовувати, і взяти в ньому участь.

Ліцензія
  • У вашого проекту є ліцензія?
Без ліцензії ваш проект не є програмним забезпеченням з відкритим вихідних кодом. Більше про це читайте тут.

  • Ця ліцензія схвалена OSI/FSF?
Деякі ліцензії можуть виглядати так, як ніби вони підходять для ліцензування програмного забезпечення з відкритим вихідним кодом. Але вони не мають такого права. Перевірте список ліцензій, схвалених OSI і FSF.

  • Ваша ліцензія сумісна з іншими в екосистемі?
Перевірте, будь ліцензування у проектів схожої тематики. Більше про сумісність ліцензій читайте тут.

Сайт
  • Є у вашого проекту сторінка в інтернеті?
Readme на Gihub, profile на SourgeForce або спеціалізовані сайти. Вашого проекту потрібно мати своє місце в інтернеті.

  • Відвідувачеві сторінки відразу буде зрозуміло, що це?

  • І як це працює?

  • Ви використовували візуальні елементи?
Скріншоти і діаграми – легкий спосіб захопити увагу читача.

  • Ви залишили свої контакти?
Напевно ви захочете почути думки людей, які зацікавлені у вашому проекті.

Доступність
  • Ви надаєте спосіб поширення «рідний» для мови програмування?
Це може бути npm, gem або crate. Якщо у вашої мови є система управління пакетами, ваш проект повинен бути зареєстрований у ній.

  • Ви можете запропонувати спосіб поширення дистрибутива для *nix?
Можливість встановлювати програмне забезпечення з знайомих джерел – це вершина комфорту вашого користувача. Якщо у вас є час, подбайте про те, щоб розмістити ваш проект для Fedora, Debian/Ubuntu або Homebrew.

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

Документація
  • Ваша документація починається з короткого керівництва по установці?
Чим легше встановити і запустити ваш проект, тим імовірніше, що хтось його спробує.

  • Включений інтерфейс/посилання на API?
Крім того, щоб дати можливість «спробувати» ваш проект, інтерфейс/посилання на API – вкрай важливі, якщо хтось дійсно захоче використовувати ваш продукт.

  • Вашу документацію, взагалі, можна знайти?
Пошукова функціональність зробить вашу документацію більш корисною. Навіть якщо це тільки одна сторінка з ctrl-f у браузері.

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

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

  • Він включає декілька завдань для початківців?
Зробіть кілька дійсно простих завдань, щоб залучити тих, хто тільки починає програмувати для опен-сорс проектів. Поділ функцій на дві або виведення додаткового аргументу командного рядка – це чудові завдання для тих, хто незнайомий з кодом проекту.

  • Всі завдання добре пояснені?
Переконайтеся, що всі завдання добре описані, та інші програмісти легко можуть працювати з ними, якщо їм буде цікаво.

Інструменти
  • У вашого проекту є автотесты?
Набір тестів полегшить перевірку змін на сумісність з рештою кодом проекту програмістам, які беруть участь у вашому проекті.

На старт, увага, реліз!

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

І коли перший розробник прийде і напише що-то в коді, не забудьте зазначити, як чувак з «Великого Лебовські»:


Тільки що з Іллінойсу

Якщо ви знаєте, що ще можна додати до цього списку, напишіть коментарях до статті або в твіттер автору статті: @radekpazdera.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.