it-swarm-eu.dev

K čemu je kanonická odpověď na „je to open source, odešlete opravu“?

Nebezpečí, že někdy na produktu navrhnete nějakou funkci, zejména open source, je, že dostanete odpověď: „proč to neděláte?“.

To platí a je skvělé, že můžete provést změnu sami. Prakticky však víme, že produkty se často zlepšují, protože programátoři poslouchají hlas uživatelů - i když tito uživatelé jsou jiní programátoři. Efektivní způsob, jak tyto změny provést, může zahrnovat někoho, kdo již na projektu pracuje, který tuto myšlenku převzal a implementoval.

Existují některé běžné termíny používané k označení problémů s vývojem softwaru. např. Bikeshedding . Používá se běžný termín, který v podstatě odpovídá: „Ano, vím, že mohu změnit téměř cokoli na světě - i uzavřený zdroj. Mohl bych být najat a jít napsat ten kód. pozorování, které může být ve skutečnosti užitečné pro jiného kodéra, který se již dobře hodí k tomu, aby tuto změnu snadno provedl - nebo jen obecně diskutuje o možnostech. “

[p.s. (pár dní) - měl jsem zdůraznit, že „podat náplast“ se často říká s obavami a já hledám vhodnou vtipnou odpověď.]

217
Vincent Scheib

Je to obtížné: protože uživatel za produkt přímo nebo nepřímo neplatí, nemůže požádat o implementaci funkce. Není to, jako byste byli zúčastněnou stranou nebo přímým zákazníkem, který produkt objednal, a dokonce ani koncovým uživatelem komerčního produktu.

Toto bylo řečeno, „odeslat opravu“ není platná odpověď. Není to zdvořilé. Není to správné. I pro produkt s otevřeným zdrojovým kódem. „Odeslat opravu“ je krátká verze:

"Je nám jedno, jestli se vám náš produkt líbí nebo ne. Jděte a upravte jej, pokud chcete, ale neobtěžujte nás svými požadavky zákazníků."

A co odeslání záplaty?

No, není to tak snadné. Udělat to:

  • Musíte znát jazyk (y) použitý v projektu open source.

  • Musíte být schopni načíst zdrojový kód z ovládacího prvku verze, abyste jej mohli upravit.

  • Musíte mít nainstalovány všechny správné verze všech závislostí sestavení (včetně knihoven runtime i nástrojů sestavení).

  • Musíte mít možnost kompilovat tento zdrojový kód, což není v některých případech tak zřejmé. Obzvláště, když velký projekt trvá několik hodin, než se sestaví a zobrazí 482 chyb a tisíce varování, můžete být odvážní jít a hledat zdroj těchto chyb.

  • Měli byste velmi dobře rozumět tomu, jak se projekt dělá, jaký styl kódování použít, pokud existuje, jak spustit testy jednotek atd. Pokud projekt nemá slušnou dokumentaci (což je často u projektů s otevřeným zdrojovým kódem), může to být opravdu těžké.

  • Musíte se přizpůsobit projektu a zvyklostem vývojářů, kteří se na projektu aktivně podílejí. Například, pokud používáte .NET Framework 4 denně, ale projekt používá .NET Framework 2.0, nemůžete použít LINQ ani kódové smlouvy ani jiné tisíce nových funkcí nejnovějších verzí rámce.

  • Vaše oprava musí být přijata (pokud změnu neprovedete pouze pro sebe, bez úmyslu ji sdílet s komunitou).

Pokud máte v úmyslu aktivně se na projektu podílet, můžete dělat všechny tyto věci a investovat do něj čas. Pokud na druhou stranu existuje jen nepříjemná drobná chyba nebo jednoduchý prvek, který chybí, strávit dny, týdny nebo měsíce studiem projektu, pak je samotná práce za pár minut prostě nepřiměřená, pokud se vám to nelíbí.

Existuje tedy kanonická odpověď na „je to open source, odešlete opravu“? Nemyslím si to. Buď jí vysvětlíš, že je nezdvořilá, nebo si s ní prostě přestaneš mluvit.

116
Arseni Mourzenko

Kanonická retorta je odeslat opravu.

79
wnoise

Toto je standardní odpověď, když si vývojáři nemyslí, že se obejdou, aby něco udělali v rozumném časovém rámci, ale opakovaně to bylo vychováváno.

Je to nejvíce nespravedlivé, když to bylo opakovaně vychováváno, ale osoba, která se naposledy zmínila, to o tom neví, a právě dostane „za to bereme náplasti“ okamžitě. V takovém případě je diskusní skupina udržována, ale uživatel si myslí, že je to nové téma. Každopádně, s největší pravděpodobností, pokud dostanete "brát záplaty" hned, neměli byste si to osobně, ale možná budete chtít přečíst archivy a sledování chyb pro více informací o problému.

Pokud opakovaně předkládáte žádost sami, „přijímání záplat“ je potenciálně zamýšleno jako zdvořilý štětec, oproti některým méně zdvořilým alternativám ...

A pak samozřejmě existují hrubí udržovatelé, kteří řeknou „brát záplaty“, aniž by nikomu vysvětlili, ale řekl bych, že je to menšina.

Pokud jste někdy udržovali projekt s otevřeným zdrojovým kódem se spoustou uživatelů, budete vědět, že existuje 100x více požadavků, než by mohli udržovatelé kdy dosáhnout, a mnoho z těchto požadavků je pro žadatele důležité, ale bylo by to neuvěřitelně obtížné, nebo by narušilo mnoho dalších uživatelů, nebo by mělo nějakou jinou vadu, která je viditelná pouze při globálním porozumění projektu a kódové základně. Nebo někdy existují jen soudní hovory a trvá příliš mnoho času na to, abychom se každý hádali znovu a znovu.

Většina společností s otevřeným zdrojovým kódem vám vůbec nedá přístup k vývojářům a díky zákaznické podpoře získáte jen tiché zacházení nebo zdvořilý, ale falešný příběh. Takže v open source máte alespoň některé možnosti (platit někomu za kódování funkce atd.) A zatímco vývojáři mohou být hrubí, přinejmenším dávají přímé odpovědi. Raději bych měl "ne" než obvykle "je to na našem plánu ... [2 roky později] ... je to stále na našem plánu" něco, co jsem dostal od řady prodejců ...

Takže si nemyslím, že existuje retort. Možná je správce open source opravdu zaneprázdněn, možná je to blbec, ale pravděpodobně mají těžkou práci a dostat se do debaty „kdo má poslední slovo“ nikam nevede. To nejlepší, co můžete udělat, je přispět nějakým způsobem a pokusit se být konstruktivní.

Možná to není kód, ale možná existuje spousta analýz a dokumentace uživatelských scénářů, které byste mohli udělat. Když jsem udržoval správce oken GNOME, mnohokrát by bylo užitečné, kdyby lidé šli analyzovat problém globálně s ohledem na všechny uživatele, a skutečně si zapsat problémy a výhody a nevýhody a co by se mělo stát z globálního hlediska.

(Místo toho bylo obvyklé začít plamenit, jako by to byl jediný uživatel, na kterém záleželo, a neexistovaly žádné kompromisy. A když je to skvělé, a to bylo datové místo, a často se mi podařilo zůstat zdvořilý nebo dokonce vyřešit jejich problém nakonec .. "hořící neznamená, že se nic nestane rychleji. Jen to zaměňuje emoce a ztrácí čas každého."

67
Havoc P

Důvodem, proč dostanete tuto odpověď, není to, že udržovatelé jsou trhnutí, je to proto, že jste je dostatečně nepřesvědčili o hodnotovém návrhu je pracuje na vašem prvku pro vás.

Nejlepší odpovědí je zahájit dialog o hodnotě vaší funkce pro jejich komunitu jako celek, abyste zjistili, zda je můžete přesvědčit, aby změnili názor. Možná mají pravdu a vědí více o potřebách své vlastní komunity než vy - ale pak zase možná ne.

Pokud je tato funkce pro vás hodnotná a pro komunitu má malou či žádnou hodnotu, zjistím, že peníze jsou vynikajícím motivátorem, zatímco stížnost na jejich postoj není.

43
Rein Henrichs

K čemu je kanonická odpověď na „je to open source, odešlete opravu“?

Neexistuje žádná přiměřená retorta, která by pravděpodobně mohla změnit. Pokus přesvědčit dobrovolníky, aby udělali něco, co nemají v úmyslu dělat, je ztráta času ... nebo horší.

Vaše možnosti jsou:

  • Udělejte, co naznačuje reakce; tj. implementujte funkci a odešlete ji jako opravu. Říká se tomu „něco dávat zpět“.

  • Najděte někoho, kdo by byl ochoten tuto funkci implementovat za skutečné peníze. Může to být samotný projekt (např. Na oplátku za sponzorství), někdo přidružený k projektu, nebo nějaký náhodný „kodér k pronájmu“.

  • Najděte alternativní produkt.


Pokud jste obdrželi tuto odpověď, když jste podali „užitečný“ návrh, zvažte, jak byste možná odpověděli, kdybyste byli v jeho botách. Jak byste například odpověděli, kdybyste si mysleli, že tento návrh nemá smysl/promyšlený/srozumitelný/atd., Ale nemáte čas ani trpělivost, abyste se zapojili do zdlouhavé debaty?


Zapojil jsem se do dlouhodobě provozovaného projektu s otevřeným zdrojovým kódem a jednou z nejvíce nepříjemných věcí jsou lidé, kteří sedí v „arašídové galerii“ a pepřují vám proudem návrhů, jak věci dělat „lépe“, které:

  • jsou neúplné, nesrozumitelné nebo přímo nesmyslné,
  • jsou nevyzkoušené nápady s objektivně nízkou šancí na úspěch,
  • implementace by vyžadovala obrovské úsilí a/nebo
  • jsou v rozporu s uvedenými cíli projektu.

Nejlepší odpovědí je často výzva, aby se osoba zapojila do projektu ... a doufali, že si vezmou nápovědu ..., aby se „postavili nebo zavřeli“. Naneštěstí ti nejvíce nepříjemní ani nenaznačují.

Samozřejmě další reakcí na takové lidi je vůbec nereagovat nebo je zcela ignorovat.

31
Stephen C

Odpověď by byla rozumná, kdybyste se vy a dotyčný programátor shodovali a věděli to samé o kódové základně a jazyce a všech dalších věcech relevantních pro tuto konkrétní věc, na kterou poukazujete.

Nejste si rovni (nebo byste to asi prostě udělali), tak bych navrhl, aby byla řádná retorta:

"Neexistuje způsob, jak to dokážu udělat tak rychle a dobře, jak je to možné, a proto jsem vás požádal, abyste mi na prvním místě pomohl. Prosím!"

Věřím, že je proti základní lidské přirozenosti říci, že „ano, ano, to, na co jsem dlouho strávil a je opravdu dobrý, je tak jednoduché, že kdokoli může přijít z ulice a dělat tak dobrou práci, jako [~ # ~] i [~ # ~] může ".

20
user1249

Kanonická retorta má projekt rozvětvovat.

16
user16764

Kanonická odpověď na „odeslat opravu“ je:

"Nemám potřebné dovednosti, zkušenosti ani čas, takže mi prosím řekni, kam mám doručit případy piva tomu muži, který to pro mě může udělat."

15
gbjbaanb

Odeslat komplexní testovací případ.

13
alecco

„Pokud to uděláš, zahrnu to“ je mnohem lepší než „ne”.

Pokud nemůžete dělat práci z nějakého důvodu, vysvětlete okolnost správci projektu soukromě.

Pokud nechcete nějakým způsobem přispět k projektu s otevřeným zdrojovým kódem, který byste chtěli použít, měli byste místo toho hledat komerční podporu nebo jiný komerční produkt.

11
yfeldblum

"Děkuji za odpověď."

Protože:

  • Při nulové ceně poptávka (požadavky na funkce) převyšuje nabídku (dostupné kodéry pro implementaci uvedených funkcí).
  • Ragování na všechno, co je poskytováno, postrádá třídu IMHO.
  • To je celý bod FOSS: lidé, kteří přinesou vlastní zeleninu a maso, aby do kamenné polévky přidali výživu. Pokud nemůžu něco přispět, měl bych být vděčný, že můžu jíst vůbec, a nestěžovat si, že nejím lépe.
10
John

Nemusíte nic říkat. Samotná skutečnost, že vývojáři reagovali, je dostatečně známkou toho, že již vědí, že problém existuje, a že to způsobuje bolest (alespoň některým) uživatelům.

Na konci dne nic, co říkáte, nepřesvědčí vývojáře, aby pro vás pracoval, pokud to nechce.

9
Dean Harding

Dobrý projekt s otevřeným zdrojovým kódem bude mít systém žádostí o chyby/funkce, kde uživatelé mohou odesílat chyby/funkce a ostatní o nich mohou hlasovat, takže správci mohou identifikovat, co je důležité pro komunitu jako celek. Nejrychlejším způsobem, jak se dostat na místo, je však odeslat opravu. Období ... žádné možnosti.

9
Michael Brown

Jen odpověď „odeslat opravu“ je hrubá IMO, ale přesto ... pokud používáte software s otevřeným zdrojovým kódem pro něco vážného, ​​musíte být připraveni se o něj postarat v případě potřeby.

Následující text je založen na příspěvek Jeremias Maerki (ze slávy Apache FOP):

Pokud pro vás něco nefunguje, máte několik možností:

  • Toto je open source: můžete to opravit sami.
  • Pokud to nemůžete sami opravit, můžete počkat, až někdo bude mít volný čas a bude si myslet, že je zábavné ho implementovat.
  • Pokud k tomu nedojde, můžete najít nebo najmout někoho, kdo to udělá za vás.

Myslím, že je to velmi platná plná verze odpovědi „odeslat opravu“.

8

Osobně bych raději odpověděl: „Toto je známý problém, ale bohužel se nejedná o problém, který by se měl vyřešit brzy. Vývojáři pracují na dalších otázkách. Momentálně neexistuje žádný ETA.“

Odpověď „odeslat opravu“ je velmi hrubá, protože předpokládá řadu věcí:

  1. Všichni uživatelé programu jsou programátoři nebo všichni reportéři chyb jsou programátoři.
  2. Všichni programátoři znají jazyk, ve kterém se program nachází.
  3. Všichni programátoři vědí o všech problémech, které může mít program jakéhokoli druhu.
  4. Všichni programátoři mají volný čas na práci na projektu s otevřeným zdrojovým kódem.

I když předpokládáme, že tvůrce odpovědí „odeslat opravu“ zná všechny výše uvedené, to jednoduše způsobí, že prohlášení zní takto: „X hodin mého času má větší hodnotu, než je řádově větší počet hodin času, který byste měli vstát. urychlit a opravit problém ".

Obecně platí, že když dostanu hrubou odpověď od vývojáře, když se ptám na problém, který mám, nebo odešlete chybu, --- přestaňte tento program používat. Například už nepoužívám uTorrent (ne open source, ale bod zůstává), protože odpovědi, které jsem dostal na jejich „podpůrném“ fóru, byly tak hrubé. Odeslal jsem problém, který jsem měl na fóru Hlášení chyb. Vlákno bylo okamžitě uzamčeno s odkazem na jiné vlákno o podobném, ale odlišném problému ve vlákně (které bylo samozřejmě také zamčeno). Mezitím jsem otevřel vlákno na fóru General Discussion s dotazem, zda někdo našel řešení problému. V době, kdy trvalo uložení tohoto vlákna a návrat zpět a zjištění, že moje první vlákno bylo zamknuto, moje vlákno v General bylo zamčeno a můj účet fóra byl zakázán pro rušivé chování. Odinstaloval jsem uTorrent a od té doby jsem se nevrátil.

8
Bacon Bits

Pokaždé, když to uvidím, okamžitě začnu hledat alternativní produkt. To je pro mě nebezpečné znamení, že se správci nezajímají o své uživatele (špatné, pokud se váš projekt používá všude) nebo ztratili zájem o projekt. Obě tyto obvykle znamenají, že projekt brzy zemře nebo bude sužován stagnací, protože vývojáři odmítají projekt posunout vpřed

(Všimněte si, že neříkám, že úplně první hlášení o chybě, které vidíte s tímto druhem reakce, kterou spustíte. Musíte se podívat na obecný trend. Pokud většina hlášení o chybách končí tímto druhem odpovědi, postupujte podle této rady. je to jen několik, pak se jedná o nejpravděpodobnější požadavky na funkce, které neodpovídají cílům projektu nebo jsou velmi specifické pro konkrétní použití)

Jak @MainMa řekl, začít přispívat do zcela nového projektu je velmi obtížné. Většina vývojářů tomu nerozumí, protože na projektu pracují měsíce/roky a dává jim to smysl. To může být někdy poctivá chyba.

6
TheLQ

Občas vtipkuji, že svobodný software může být zdarma jako v pivu, zdarma jako v řeči nebo zdarma, protože dostanete to, za co platíte.

I když to říkám vtipně (pracuji pro společnost, která používá mnoho OSS), ale myslím, že tam je pravda - pokud chcete komerční úroveň podpory, pak musíte buď použít komerční software s vhodným podpůrným řešením, nebo najít softwarové řešení s otevřeným zdrojovým kódem, které vám umožňuje tuto úroveň podpory (obvykle prostřednictvím někoho, kdo je za to poskytován, ale potenciálně prostřednictvím vaší organizace, která zaměstnává nebo přiřazuje vývojové prostředky, aby na něm pracovala).

„Odeslat patch“ je rozzlobený, ale zdůrazňuje něco o OSS a možná by to mělo být připomenutí, že OSS není pro každého v každé situaci to pravé, alespoň ne bez toho, aby se ujistil, že pro něj máte pevný rámec podpory (buď in-house, placené nebo prostřednictvím komunity).

Často uvažujeme o softwaru, který je zdarma jako v pivu, ale ne jako v řeči (to je neotevřený freeware). Možná se jedná o případ, kdy bychom měli uvažovat o softwaru stejně svobodném jako v řeči, ale ne jako v pivu.

3
Jon Hopkins

Přepněte na dobře udržovanou alternativu.

Podle mých zkušeností s dobře udržovanými open-source projekty je to, že pokud vytvoříte dobře definovanou zprávu o chybě nebo požadavek na funkci, pak má velmi vysokou šanci na implementaci.

2
vartec

Je několik způsobů, jak to udělat.

  • Návrh funkce a hlasování. ale to vyžaduje čas.

  • Najměte si společnost, která ji potřebuje k vytvoření opravy. To je samozřejmě nejlepší řešení, ale připravte se na spolupráci s chlápkem, který vyrábí software s otevřeným zdrojovým kódem, který chcete upgradovat.

  • Důležité je také zjistit, proč tato funkce není implementována. Tato funkce je často mimo rámec softwarového projektu: tým tuto funkci nechce, necítí se nezbytně potřebovat nebo si prostě myslí, že to není dobrý způsob, jak něco udělat. V tomto případě byste měli projekt pouze rozvětvit a sami si ho vyrobit.

  • Používejte proprietární software, který dělá to, co chcete.

  • Pamatujte, že software OOP=) často usnadňuje proces integrace funkce.

  • Kňučení na mailing listu, na irc nebo na fóru jen vyrazí programátory a dá munici zastáncům OSS.

1
jokoon

„Dokážu pracovat na jedné věci najednou, ale mohu si stěžovat na mnoho věcí najednou. Myslím, že obě funkce jsou užitečné.“ - akkartik na ycombinátor .

1
Vincent Scheib

Domnívám se, že když člověk pracuje na projektu, poskytuje vydání a podporu, vzniká nevyslovená, implikovaná smlouva o podpoře mezi dev a uživatelem. Dev převzal implicitní odpovědnost za podporu kódové základny pro své uživatele, včetně přidání funkcí na vyžádání.

„Odeslat opravu“ podle mého názoru v podstatě dává uživatelům prst. To je kontextové - někdy je to jen příliš velké úsilí k provedení, někdy by to zničilo existující projekt nebo vyvolalo hnisající creaturitis, nebo z jakéhokoli jiného důvodu. Nakonec se ale říká: „zašroubuj, nedělej to“. Což je podle mého názoru v určité míře porušením této nevyslovené smlouvy.

1
Paul Nathan

Navrhl bych vytvořit projekt pro implementaci této funkce na webech, jako je RentACoder/ELance/atd., A zveřejnit o tom na fóru původního open source projektu. Kterýkoli z programátorů v projektech s otevřeným zdrojovým kódem, včetně autora, má nyní finanční motivaci zvážit vaši žádost.

0
Renji Panicker

Neexistuje nic, co bys mohl říci, že to udělá donutí. Koneckonců, proč by měl? Kvůli přání jednoho uživatele? Není to dost dobrý důvod.

Ale, pokud můžete shromáždit přiměřený počet uživatelů a uvést racionální důvody („Chci to“ není racionální důvod.) Proč by tato funkce mohla být užitečná, obecně a pro vás a počet jiní by prostě mohl změnit názor.

I když existuje i zvláštní případ, který je třeba vzít v úvahu. To je dev. je unavený vývojem aplikace, pomalu si přeje opustit ji (má jiné věci udělat), a tak pomalu opouští žádosti o funkce. Kromě toho, že se ho snažíme přesvědčit, aby kód vydal, v tomto případě prakticky neexistuje nic, co by se dalo udělat, a to ani s ohledem na výše uvedené.

0
Rook

Zejména projekty s otevřeným zdrojovým kódem jsou přátelské k odměnám nebo financování rozvoje určité funkce, i když nová funkce nevede k oficiálním vydáním.

Plus, ano, jedním z nápadů, které stojí za zveřejněním open source, je, aby každý a každý měl právo a odpovědnost za vlastní příspěvky.

S uzavřeným zdrojem je nejlepším prostředkem shromáždit statisticky důležitou skupinu z uživatelské základny, která chce řešení jako ta, která chcete.

0
Apalala

Podle mých zkušeností je tato odpověď obvykle dána, pokud žádost uživatele neodpovídá cíli projektu. Stává se to, když si lidé myslí, že budete implementovat vše, co vám navrhují, a ještě něco víc - zdarma, otevřený zdroj a skvělá a šťastná budoucnost.

„Odeslat opravu“ je poměrně hrubá odpověď (a nemělo by se tomu samozřejmě vyhýbat. Zejména v této stručné a ostré formě. Existuje mnoho způsobů, jak vyjádřit zhruba stejnou zprávu - například „vyzvat uživatele“, aby vám pomohli, protože nemáte čas jej implementovat sami). Ale jak to je, je to jasný indikátor „přestat ztrácet čas“. Jako takový toho není moc, co byste mohli udělat, ani neexistuje „kanonická“ odpověď.

Nejlepší odpověď, na kterou mohu myslet, je vlastně předložit patch. Za předpokladu, že vaše oprava funguje, jste alespoň prokázali, že myšlenka není úplně nereálná. Obvykle to znamená, že lidé odpovědní za projekt návrh znovu zváží.

0

„odeslat opravu“ je legitimní výměna nápadů, které se nehodí k cílům projektu. Z dlouhodobého hlediska je asi lepší říct, že nápad je na hovno, nebo se snažíte použít projekt na něco, co je daleko od zamýšleného rozsahu, ale „hej, pokud si myslíte, že to, co žádáte, je tak triviální, proč ne“ t zkusíte, aby se vešly do naší stávající kódové základny "je někdy vhodné.".

Pokud je to pro zamýšlené uživatele projektu menší a skutečně užitečné, stačí předložit hlášení o chybě, jasně popsat problém, provést kroky k reprodukci, naznačit, že používáte aktuální noční sestavení, a ponechat jej při tom.

To, co se může zdát jako drobná jednoduchá změna, která by pomohla tunám uživatelů, může být ve skutečnosti velká bolest v zadku, který by nikdo kromě vás nepoužil. To je nejlepší případ pro „odeslání záplaty“.

Je také možné, že jste narazili na případ jako notoricky známý správce glibc, který vypadá, že má jednostopou mysl, že jeho systém je vesmír, jeho interpretace specifik je Božím slovem, a to je vše, co je v něm, bez ohledu na to, kolik lidí by dalo přednost jinak.

0
Kevin Peterson