Добре розгортаючи проект з відкритим кодом

Настав час.

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

Але це не вийде з існуючими розробниками.

Вам нарешті потрібно роздрібнити код.

Як ви це робите та залишаєтесь на найкращих умовах, що можливі для існуючого проекту? Як ти не скажеш: " О так? Вилазить! "

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

Конкуренція? Вивільнення ресурсів? Користувач браконьєрство?

Як ви переживаєте цей, мабуть, важкий і тривалий процес, поки ви не зробите достатньо диверсифікацію, щоб вони більше не сприймалися як проблеми?

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

-Адам

Ви хочете попрацювати над власною форкою коду чи потрібно фрагментувати спільноту?

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

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

Нам просто не було заклику "просувати" наші зміни будь-яким публічним способом, ніж список розсилки розробників.

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

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

Джерело є для використання, тому використовуйте його.

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

І це має сенс тільки: «вилки» за своєю природою є потенційними конкурентами, тоді як «тематичні гілки» - як мінімум за дизайном - мають бути з часом об'єднані / внесені назад до проекту.

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

Потім створіть свою вилку. Звичайно, ви відповідальний розробник, тому ви ставите весь код під контроль редакції. Використовуйте Launchpad або SourceForge або Google Code чи що завгодно.

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

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

Повторити коментар кодексу:

Правильно; Я припускав, що люди, які ОП хоче залишити позаду, не здатні підтримувати проект самостійно.

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

Однак у відкритих джерелах іноді правда, що ніхто не має волі, таланту та часу, щоб запустити проект без засновника.