Що є канонічним ретортам до "це відкритий код, подати виправлення"? [зачинено]

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

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

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

[ps (кілька днів у) - я мав би зазначити, що "подати патч" часто говорять з кривим гумором, і я шукаю відповідного дотепного відгуку.]

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

На це, як сказано, "надіслати виправлення" не відповідає дійсності. Це не ввічливо. Це не правильно. Навіть для продукту з відкритим кодом. "Надіслати виправлення" - це коротка версія:

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

Що з поданням патча?

Ну, це не так просто. Зробити це:

• Ви повинні знати мову, якою користуєтесь у проекті з відкритим кодом.

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

• У вас повинні бути встановлені всі правильні версії будь-яких залежностей від збірки (включаючи обидві бібліотеки виконання та засоби збирання).

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

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

• Ви повинні адаптувати себе до проекту та до звичок розробників, які активно беруть участь у проекті. Наприклад, якщо ви використовуєте .NET Framework 4 щодня, але проект використовує .NET Framework 2.0, ви не можете використовувати LINQ, ні кодові контракти, ні інші тисячі нових функцій останніх версій фреймворку.

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

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

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

Канонічний реторт - подати патч.

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

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

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

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

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

Більшість компаній, що не мають відкритого коду, взагалі не нададуть вам доступ до розробників, і ви просто отримаєте тихе поводження або ввічливу, але неправдиву історію від служби підтримки клієнтів. Так, у відкритому коді, принаймні, у вас є деякі варіанти (заплатити комусь, щоб кодувати функцію тощо), і хоча розробники можуть бути грубими, принаймні вони дають прямі відповіді. Я вважаю за краще "ні", ніж зазвичай, "це в нашій дорожній карті ... [2 роки потому] ... це все ще є в нашій дорожній карті", яку я отримав від багатьох постачальників ...

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

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

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

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

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

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

Що є канонічним ретортам до "це відкритий код, подати виправлення"?

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

Ваші варіанти:

• Робіть те, що пропонує відповідь; тобто реалізуйте функцію та подайте її як виправлення. Це називається "повернути щось назад".

• Знайдіть когось, хто хотів би реалізувати цю функцію для вас за реальні гроші. Це може бути сам проект (наприклад, взамін на спонсорство), хтось, пов'язаний з проектом, або якийсь випадковий «кодер для найму».

• Знайдіть альтернативний товар.

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

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

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

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

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

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

Ви не є рівними (або ви, мабуть, просто зробили б це), тому я б запропонував належним ретортом бути:

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

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

Канонічний реторт - це роздрібнити проект.

Канонічна відповідь на "подати виправлення":

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

Подайте вичерпний тестовий випадок .

"Якщо ви це зробите, я включу його" набагато краще, ніж "ні".

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

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

"Дякую за відповідь."

Оскільки:

• При нульовій ціні попит (запити на функції) перевищує пропозицію (доступні кодери для реалізації зазначених функцій).
• Нахабство на все, що надається безкоштовно, не вистачає класу IMHO.
• У цьому і полягає вся суть ФОСУ: люди, які приносять овочі та м’ясо, додають собі їжу в кам’яний суп. Якщо я не можу щось внести, я повинен бути вдячний, що я можу їсти взагалі, а не скаржитися, що не харчуюся краще.

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

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

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

Особисто я скоріше отримав би відповідь "Це відома проблема, але, на жаль, це питання не скоро вирішується. Розробники працюють над іншими питаннями. Наразі ЗНО немає".

Відповідь "надіслати патч" дуже груба, оскільки передбачає ряд речей:

1. Усі користувачі програми - це програмісти або всі репортери помилок - програмісти.
2. Усі програмісти знають мову, якою є програма.
3. Усі програмісти знають про будь-які проблеми, які можуть мати будь-які програми.
4. Усі програмісти мають вільний час для роботи над проектом з відкритим кодом.

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

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

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

Далі ґрунтується на публікації Єремії Маеркі (слава FOP Apache):

Якщо щось не працює для вас, у вас є кілька варіантів:

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

Я думаю, що це дуже дійсна повна версія відповіді "надіслати виправлення".

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

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

Як сказав @MainMa, починати робити внесок у абсолютно новий проект дуже важко. Більшість розробників цього не розуміють, оскільки працюють над проектом місяці / роки, і це має сенс. Іноді це може бути чесною помилкою.

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

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

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

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

Перейти на доглянуту альтернативу.

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

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

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

"Надіслати патч" - це, по-моєму, пальчик для користувачів. Це контекстуально - іноді це просто занадто багато зусиль, щоб реалізувати, іноді це призвело б до руйнування існуючого проекту, або виникнення кричущого креатуриту, або будь-якої з інших причин. Але, врешті-решт, це говорить: "Викрутіть, не робіть цього". Що, на мій погляд, є певним чином порушенням цього невимовного контракту.

Є кілька способів, як це слід зробити.

• Пропозиція та голосування. але для цього потрібен час.

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

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

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

• Пам'ятайте, що програмне забезпечення OOP часто полегшує процес інтеграції функції.

• Скидання в списку розсилки, на irc або на форумі просто змусить програмістів і дасть боєприпаси прихильникам OSS.

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

Але , якщо ви можете зібрати розумну кількість користувачів і надати раціональні причини («я хочу це» - це не раціональна причина), чому ця функція може бути корисною, загалом, і для вас, і для багатьох інших він просто може змінити свою думку .

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

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

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

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

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

"Надіслати виправлення" - це відносно груба відповідь (і цього, звичайно, слід уникати. Особливо в цій стислій і різкій формі. Існує багато способів висловити приблизно те саме повідомлення - наприклад, "запросити" користувачів на допомогу, оскільки ви не встигнете самостійно реалізувати це). Але, як це є, це чіткий показник "перестань марнувати свій час". Таким чином, ви не могли б з цим зробити чимало, а також немає "канонічної" відповіді.

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

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

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

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

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

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

Я фактично зареєструвався, щоб відповісти на це питання.

Чи є потреба у реторті? ця відповідь зазвичай використовується, коли розробник знає про проблему, але не вважає це важливим.

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

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

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

Ні, я просто дозволю це дозволити

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

підсумок: канонічна реторта повинна була б подати виправлення, але якщо ви цього не можете, немає необхідності в реторті

Почніть багатство за потрібну функцію.

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

Найкраще, що я можу придумати, - "ти смоктав".

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

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