Jaka jest kanoniczna retorta do „to open source, prześlij łatkę”? [Zamknięte]

Niebezpieczeństwo zasugerowania jakiejkolwiek funkcji produktu, zwłaszcza open source, polega na tym, że otrzymasz odpowiedź „dlaczego tego nie zrobisz?”.

To ważne i fajnie, że możesz sam dokonać zmiany. Ale wiemy praktycznie, że produkty często się poprawiają, ponieważ programiści słuchają głosu użytkowników - nawet jeśli ci użytkownicy są innymi programistami. I skutecznym sposobem wprowadzenia tych zmian może być ktoś, kto już pracuje nad projektem, podejmując pomysł i wdrażając go.

Istnieje kilka typowych terminów odnoszących się do problemów związanych z programowaniem. np . jazda rowerem . Czy jest używany często używany termin, który zasadniczo odpowiada: „Tak, wiem, że mogę zmienić prawie wszystko na świecie - nawet zamknięte źródło. Mogę zostać zatrudniony i napisać ten kod. Ale w tym przypadku robię tylko spostrzeżenie, które w rzeczywistości może być przydatne dla innego kodera, który jest już dobrze przystosowany do łatwej zmiany - lub po prostu ogólnie omawia możliwości ”.

[ps (kilka dni później) - Powinienem zauważyć, że „prześlij łatkę” często mówi się z ironicznym humorem i szukam odpowiedniej dowcipnej odpowiedzi.]

To trudna kwestia: ponieważ użytkownik nie płaci bezpośrednio ani pośrednio za produkt, nie może poprosić o wdrożenie funkcji. To nie tak, jakbyś był interesariuszem lub bezpośrednim klientem, który zamówił produkt, a nawet nie końcowym użytkownikiem produktu komercyjnego.

To powiedzenie: „prześlij łatkę” nie jest prawidłową odpowiedzią. To nie jest grzeczne. To jest niepoprawne. Nawet dla produktu open source. „Prześlij łatkę” to krótka wersja:

„Nie obchodzi nas, czy podoba ci się nasz produkt, czy nie. Przejdź i zmodyfikuj go, jeśli chcesz, ale nie zawracaj nam głowy życzeniami klientów”.

Co powiesz na przesłanie łatki?

Cóż, to nie jest takie proste. Aby to zrobić:

• Musisz znać języki używane w projekcie open source.

• Musisz mieć możliwość załadowania kodu źródłowego z kontroli wersji, aby móc go zmodyfikować.

• Musisz mieć zainstalowane wszystkie prawidłowe wersje dowolnych zależności kompilacji (w tym zarówno biblioteki wykonawcze, jak i narzędzia kompilacji).

• Musisz być w stanie skompilować ten kod źródłowy , co w niektórych przypadkach nie jest tak oczywiste. Zwłaszcza, gdy skompilowanie dużego projektu zajmuje kilka godzin i wyświetla 482 błędy i tysiące ostrzeżeń, możesz odważnie szukać źródła tych błędów.

• Powinieneś bardzo dobrze zrozumieć, w jaki sposób realizowany jest projekt , jakiego stylu kodowania użyć, jeśli w ogóle, jak przeprowadzać testy jednostkowe itp. Jeśli projekt nie ma porządnej dokumentacji (co często ma miejsce w przypadku projektów open source ), może to być naprawdę trudne.

• Musisz dostosować się do projektu i nawyków programistów, którzy aktywnie uczestniczą w projekcie. Na przykład, jeśli korzystasz z .NET Framework 4 codziennie, ale projekt korzysta z .NET Framework 2.0, nie możesz używać LINQ, ani kontraktów kodowych, ani innych tysięcy nowych funkcji najnowszych wersji frameworka.

• Twoja łatka musi zostać zaakceptowana (chyba że zrobisz zmianę tylko dla siebie, bez zamiaru dzielenia się nią ze społecznością).

Jeśli masz zamiar aktywnie uczestniczyć w projekcie, możesz zrobić wszystkie te rzeczy i poświęcić na to swój czas. Z drugiej strony, jeśli brakuje tylko denerwującego drobnego błędu lub prostej funkcji, spędzania dni, tygodni lub miesięcy na studiowaniu projektu, wykonanie samej pracy w ciągu kilku minut jest po prostu nieuzasadnione, chyba że ci się podoba.

Czy istnieje kanoniczna retorta do „to open source, prześlij łatkę”? Nie wydaje mi się Albo wytłumaczysz osobie, że jest niegrzeczna, albo przestaniesz z nią rozmawiać.

Kanoniczna retorta polega na przesłaniu łatki.

Jest to standardowa odpowiedź, gdy programiści nie sądzą, że zaczną coś robić w rozsądnych ramach czasowych, ale była wielokrotnie podnoszona.

Jest to niesprawiedliwe, gdy jest wielokrotnie wychowywane, ale osoba, która ostatnio o tym wspominała, nie wie o tym i po prostu dostaje „bierzemy za to łatki” od razu. W tym przypadku opiekun ma dość dyskusji, ale użytkownik uważa, że ​​jest to nowy temat. W każdym razie, najprawdopodobniej, jeśli od razu dostaniesz „branie łatek”, nie powinieneś brać go osobiście, ale możesz przeczytać w archiwum i narzędziu do śledzenia błędów, aby uzyskać więcej szczegółów na temat problemu.

Jeśli wielokrotnie sam wysuwasz prośbę, „usuwanie łatek” może potencjalnie być względnie uprzejmym oderwaniem od innych mniej uprzejmych alternatyw ...

No i oczywiście są niegrzeczni opiekunowie, którzy powiedzą „branie łat” bez żadnego wytłumaczenia, ale powiedziałbym, że to mniejszość.

Jeśli kiedykolwiek utrzymywałeś projekt open source z dużą liczbą użytkowników, będziesz wiedział, że jest 100 razy więcej żądań, niż opiekunowie mogliby kiedykolwiek uzyskać, a wiele z nich jest ważnych dla zlecającego, ale byłoby to niezwykle trudne, lub zakłóciłoby wielu innych użytkowników, lub miałoby jakąś inną wadę, która jest widoczna tylko przy globalnym zrozumieniu projektu i bazy kodu. Lub czasem są tylko wezwania do osądu, a kłócenie się z każdym z nich trwa zbyt długo.

Większość firm, które nie są źródłami otwartymi, w ogóle nie daje ci dostępu do programistów, a po prostu uzyskasz ciche traktowanie lub uprzejmą, ale fałszywą historię z obsługi klienta. Tak więc, w otwartym kodzie źródłowym masz przynajmniej kilka opcji (zapłać komuś za zakodowanie funkcji itp.) I chociaż programiści mogą być niegrzeczni, przynajmniej dają proste odpowiedzi. Wolę mieć „nie” niż zwykle ”jest to na naszej mapie drogowej… [2 lata później]… wciąż jest na naszej mapie drogowej” coś, co otrzymałem od wielu dostawców…

Więc nie sądzę, żeby była retorta. Być może opiekun oprogramowania open source jest po prostu bardzo zajęty, może są palantem, ale w każdym razie prawdopodobnie mają ciężką pracę i debata „kto ostatni raz” nigdzie się nie zmierza. Najlepsze, co możesz zrobić, to w jakiś sposób przyczynić się i starać się być konstruktywne.

Może to nie jest kod, ale być może istnieje wiele analiz i dokumentacji scenariuszy użytkownika, które możesz zrobić. Kiedy utrzymywałem menedżera okien GNOME, wiele razy byłoby pomocne, aby ludzie analizowali problem globalnie, biorąc pod uwagę wszystkich użytkowników, i naprawdę zapisywali problemy, plusy i minusy oraz to, co powinno się stać z globalnej perspektywy.

(Zamiast tego zwykłą rzeczą było zacząć płonąć, jakby byli jedynym użytkownikiem, który się liczył i nie było żadnych kompromisów. I chociaż to świetnie, i był to punkt danych, a często udało mi się zachować uprzejmość, a nawet rozwiązać problem w końcu .. płomienie nie przyspieszają niczego. To po prostu wprawia emocje w problem i marnuje czas wszystkich).

Powodem, dla którego otrzymujesz tę odpowiedź, nie jest to, że opiekunowie są szarpnięciami, ale to, że nie przekonałeś ich odpowiednio o propozycji wartości, jaką oni pracują nad twoją funkcją dla ciebie .

Najlepszą odpowiedzią jest rozpoczęcie dialogu na temat wartości Twojej funkcji dla całej społeczności , aby przekonać się, czy możesz przekonać ich do zmiany zdania. Może mają rację i wiedzą więcej o potrzebach swojej społeczności niż ty - ale z drugiej strony, może nie.

Jeśli ta funkcja jest tylko dla ciebie cenna i ma niewielką lub żadną wartość dla społeczności, uważam, że pieniądze są doskonałym czynnikiem motywującym, podczas gdy narzekanie na ich podejście nie jest.

Jaka jest kanoniczna retorta do „to open source, prześlij łatkę”?

Nie ma rozsądnej retorty, która mogłaby coś zmienić. Próba przekonania wolontariuszy do zrobienia czegoś, czego nie zamierzają zrobić, jest stratą czasu ... lub gorzej.

Twoje opcje to:

• Rób, co sugeruje odpowiedź; tj. zaimplementuj funkcję i prześlij ją jako poprawkę. Nazywa się to „oddawaniem czegoś”.

• Znajdź kogoś, kto byłby skłonny zaimplementować tę funkcję za prawdziwe pieniądze. Może to być sam projekt (np. W zamian za sponsoring), ktoś powiązany z projektem lub jakiś losowy „programista do wynajęcia”.

• Znajdź alternatywny produkt.

Jeśli otrzymałeś tę odpowiedź, gdy zaproponowałeś „pomocną” sugestię, zastanów się, jak mógłbyś zareagować, gdybyś był w jego sytuacji. Na przykład, jak zareagowałbyś, gdybyś pomyślał, że ta sugestia nie była opłacalna / dobrze przemyślana / zrozumiała / itp., Ale nie miała czasu ani cierpliwości, aby zaangażować się w przedłużającą się debatę?

Byłem zaangażowany w długo działający projekt systemu operacyjnego typu open source, a jedną z najbardziej denerwujących rzeczy są ludzie, którzy siedzą w „galerii orzeszków ziemnych” i wysypują cię strumieniem sugestii dotyczących robienia rzeczy „lepiej”, które:

• są niekompletne, niezrozumiałe lub wręcz nonsensowne,
• są niesprawdzonymi pomysłami z obiektywnie niską szansą na sukces,
• wymagałoby ogromnego wysiłku w celu wdrożenia i / lub
• są sprzeczne z podanymi celami projektu.

Często najlepszą odpowiedzią jest wyraźne wezwanie osoby do zaangażowania się w projekt ... i nadzieja, że ​​skorzystają z podpowiedzi ... aby „założyć lub zamknąć się”. Niestety, najbardziej irytujące nawet nie biorą podpowiedzi.

Oczywiście inną odpowiedzią na takie osoby jest brak odpowiedzi lub całkowite zignorowanie ich.

Odpowiedź byłaby rozsądna, gdybyś ty i programista byli równi, i wiedzielibyście prawie to samo o podstawie kodu i języku oraz wszystkich innych rzeczach związanych z tą konkretną rzeczą, którą wskazaliście.

Nie jesteś równy (lub prawdopodobnie po prostu byś to zrobił), więc sugerowałbym odpowiednią retortę:

„Nie ma możliwości, żebym mógł to zrobić tak szybko i dobrze, jak potrafisz, dlatego właśnie poprosiłem cię o pomoc. Proszę!”

Uważam, że powiedzenie wtedy „och, tak, to, nad czym spędziłem długo i jest naprawdę dobry, jest tak proste, że każdy może przyjść z ulicy i wykonać tak dobrą robotę jak Mogę ”.

Kanoniczna retorta polega na rozwidleniu projektu.

Kanoniczna odpowiedź na „prześlij łatkę” brzmi:

„Nie mam wymaganych umiejętności, doświadczenia ani czasu, więc czy możesz mi powiedzieć, gdzie mam wysłać skrzynki piwa facetowi, który może to dla mnie zrobić?”

Prześlij kompleksową walizkę testową .

„Jeśli to zrobisz, uwzględnię to” jest znacznie lepsze niż „nie”.

Jeśli nie możesz wykonać pracy z tego czy innego powodu, wyjaśnij to osobiście opiekunowi projektu.

Jeśli nie chcesz w żaden sposób wnosić wkładu w projekt typu open source, z którego chciałbyś skorzystać, powinieneś poszukać wsparcia handlowego lub innego produktu komercyjnego.

"Dzięki za odpowiedzi."

Dlatego:

• Przy zerowej cenie popyt (zapytania o funkcje) przewyższa podaż (dostępni koderzy do implementacji wspomnianych funkcji).
• Szarpanie się na wszystkim, co zapewniono za darmo, nie ma klasy IMHO.
• Taki jest cel FOSS: ludzie przynoszą własne warzywa i mięso, aby wzbogacić kamienną zupę. Jeśli nie mogę coś wnieść, to powinienem być wdzięczny, że mogę w ogóle jeść i nie narzekać, że nie jem lepiej.

Nie musisz nic mówić. Sam fakt, że programiści odpowiedzieli, jest wystarczającą wskazówką, że już wiedzą, że problem istnieje i że powoduje ból (przynajmniej niektórych) użytkowników.

Pod koniec dnia nic, co powiesz, nie przekona programisty do pracy dla ciebie, jeśli nie będzie chciał.

Dobry projekt open source będzie miał system zgłaszania błędów / funkcji, w którym użytkownicy mogą zgłaszać błędy / funkcje, a inni mogą głosować na nie, aby opiekunowie mogli zidentyfikować to, co jest ważne dla całej społeczności. Najszybszym sposobem na wprowadzenie funkcji jest jednak przesłanie łatki. Okres ... nie można tego obejść.

Osobiście wolałbym uzyskać odpowiedź: „To znany problem, ale niestety nie jest to problem, który należy rozwiązać w najbliższym czasie. Deweloperzy pracują nad innymi problemami. W tej chwili nie ma ETA”.

Odpowiedź „prześlij łatkę” jest bardzo niegrzeczna, ponieważ zakłada wiele rzeczy:

1. Wszyscy użytkownicy programu są programistami lub wszyscy zgłaszający błędy są programistami.
2. Wszyscy programiści znają język, w którym znajduje się program.
3. Wszyscy programiści wiedzą o każdym rodzaju problemu, jaki może mieć każdy program.
4. Wszyscy programiści mają czas wolny na pracę nad projektem typu open source.

Nawet jeśli założymy, że twórca odpowiedzi „prześlij łatkę” wie wszystko powyższe, to po prostu sprawia, że ​​stwierdzenie brzmi: „X godzin mojego czasu jest wart więcej niż rząd wielkości więcej godzin twojego czasu, w którym wstaniesz przyspieszyć i naprawić problem ".

Zasadniczo, kiedy otrzymuję nieuprzejmi odpowiedź od dewelopera, kiedy pytam o problem, który mam lub zgłaszam błąd, ja przestaję używać tego programu. Nie używam już na przykład uTorrenta (nie open source, ale o to chodzi), ponieważ odpowiedzi, które otrzymałem na ich forum „wsparcia” były bardzo niegrzeczne. Zgłosiłem problem na forum z raportami błędów. Wątek został natychmiast zablokowany za pomocą łącza do innego wątku na podobny, ale inny problem w wątku (który również został oczywiście zablokowany). W międzyczasie otworzyłem wątek na forum dyskusji ogólnej, pytając, czy ktoś znalazł rozwiązanie tego problemu. W czasie, gdy trzeba było zapisać ten wątek i wrócić i zobaczyć, że mój pierwszy wątek został zablokowany, mój wątek w ogóle został zablokowany, a moje konto na forum zostało zablokowane za zachowanie zakłócające. Odinstalowałem uTorrent i od tamtej pory nie wróciłem.

Samo odpowiedzenie „prześlij łatkę” jest niegrzeczne IMO, ale nadal ... jeśli używasz oprogramowania open source do czegoś poważnego, musisz być przygotowany, aby zająć się nim, jeśli zajdzie taka potrzeba.

Poniższy artykuł oparty jest na postu Jeremiasa Maerki (znanego z Apache FOP):

Jeśli coś nie działa, masz kilka opcji:

• To jest oprogramowanie typu open source: możesz to naprawić samodzielnie.
• Jeśli nie możesz tego naprawić samodzielnie, możesz poczekać, aż ktoś będzie miał czas wolny i uzna, że ​​wdrożenie go jest przyjemne.
• Jeśli tak się nie stanie, możesz znaleźć lub zatrudnić kogoś, kto zrobi to za Ciebie.

Myślę, że jest to bardzo ważna pełna wersja odpowiedzi „prześlij łatkę”.

Za każdym razem, gdy to widzę, od razu zaczynam szukać alternatywnego produktu. Dla mnie jest to niebezpieczny znak, że opiekunowie albo nie dbają o swoich użytkowników (źle, jeśli twój projekt jest wszędzie używany), albo stracili zainteresowanie projektem. Oba z nich zwykle oznaczają, że projekt wkrótce umrze lub będzie nękany stagnacją, ponieważ programiści odmawiają kontynuowania projektu

(Pamiętaj, że nie mówię, że pierwszy raport o błędach, który widzisz z tego rodzaju odpowiedzią, którą uruchamiasz. Musisz spojrzeć na ogólny trend. Jeśli większość raportów o błędach kończy się z tego rodzaju odpowiedzią, zastosuj się do tej porady. Jeśli to tylko kilka, są to najprawdopodobniej żądania funkcji, które nie pasują do celów projektu lub są bardzo specyficzne dla konkretnego zastosowania)

Jak powiedział @MainMa, rozpoczęcie tworzenia nowego projektu jest bardzo trudne. Większość programistów nie rozumie tego, ponieważ pracują nad projektem od miesięcy / lat i ma to dla nich sens. Może to czasem być uczciwy błąd.

Od czasu do czasu żartuję, że darmowe oprogramowanie może być darmowe jak w piwie, wolne jak w mowie lub wolne, gdy dostajesz to, za co płacisz.

Mówię to żartem (pracuję dla firmy, która używa dużo OSS), ale myślę, że jest w tym prawda - jeśli chcesz wsparcia na poziomie komercyjnym, musisz albo użyć komercyjnego oprogramowania z odpowiednią ofertą wsparcia, albo znaleźć oprogramowanie typu open source, które pozwala na taki poziom wsparcia (zazwyczaj przez kogoś, kto za to zapewnia, ale potencjalnie przez twoją organizację zatrudniającą lub przydzielającą zasoby programistyczne do pracy nad nim).

„Prześlij łatkę” jest denerwujące, ale podkreśla coś na temat OSS i być może powinno przypominać, że OSS nie jest odpowiedni dla wszystkich w każdej sytuacji, przynajmniej nie upewniając się, że masz solidne ramy wsparcia (albo wewnętrznie, opłacane za społeczność lub za jej pośrednictwem).

Często myślimy o oprogramowaniu, które jest bezpłatne jak w piwie, ale nie w mowie (to znaczy nie otwarte darmowe oprogramowanie). Być może jest to przypadek, w którym powinniśmy myśleć o oprogramowaniu tak wolnym jak w mowie, ale nie tak jak w piwie.

Przełącz się na dobrze utrzymaną alternatywę.

Z mojego doświadczenia z dobrze utrzymanymi projektami typu open source wynika, że ​​jeśli utworzysz dobrze zdefiniowany raport o błędzie lub prośbę o funkcję, ma ona bardzo dużą szansę na wdrożenie.

„Mogę pracować tylko nad jedną rzeczą na raz, ale mogę narzekać na wiele rzeczy naraz. Myślę, że obie funkcje są przydatne”. - akkartik na ycombinator .

Uważam, że kiedy pracujemy nad projektem, dostarczając wydania i wsparcie, powstaje niewypowiedziana, dorozumiana, umowa wsparcia między deweloperem a użytkownikiem. Twórca przyjął domyślną odpowiedzialność za obsługę bazy kodów dla swoich użytkowników, w tym dodawanie funkcji na żądanie.

Moim zdaniem „Prześlij łatę” zasadniczo daje palec użytkownikom. Jest to kontekstowe - czasami jest to po prostu zbyt duży wysiłek, aby go wdrożyć, czasem zniszczyłby istniejący projekt lub wywoływałoby rozgorączkowane zapalenie skóry lub z wielu innych powodów. Ale ostatecznie mówi: „pieprzyć cię, nie robiąc tego”. Co, moim zdaniem, jest do pewnego stopnia naruszeniem tej niewypowiedzianej umowy.

Można to zrobić na kilka sposobów.

• Propozycja funkcji i głosowanie. ale to wymaga czasu.

• Zatrudnij firmę, która potrzebuje go do zrobienia poprawki. Oczywiście jest to najlepsze rozwiązanie, ale przygotuj się na współpracę z facetem, który tworzy oprogramowanie open source, które chcesz zaktualizować.

• Ważne jest również ustalenie, dlaczego ta funkcja nie jest zaimplementowana. Często funkcja ta jest poza linią projektu oprogramowania: zespół nie chce tej funkcji, nie czuje się potrzebny lub po prostu myślą, że to nie jest dobry sposób na zrobienie czegoś. W takim przypadku powinieneś po prostu rozwidlić projekt i zrobić go sam.

• Użyj zastrzeżonego oprogramowania, które robi to, co chcesz.

• Pamiętaj, że oprogramowanie OOP często ułatwia proces integracji funkcji.

• Zawodzenie na liście mailingowej, na irc lub na forum po prostu wkurza programistów i daje amunicję zwolennikom OSS.

Nic, co możesz powiedzieć, zmusi go do tego. W końcu dlaczego miałby? Z powodu życzeń jednego użytkownika? To nie jest wystarczający powód.

Ale jeśli możesz zebrać rozsądną liczbę użytkowników i podać racjonalne powody („Chcę tego” nie jest racjonalnym powodem). Dlaczego ta funkcja może być użyteczna, ogólnie i dla ciebie oraz wielu innych osób, on może po prostu zmienić zdanie .

Chociaż istnieje również szczególny przypadek, który należy wziąć pod uwagę. To dev. jest zmęczony tworzeniem aplikacji i powoli chce ją porzucić (ma inne rzeczy do zrobienia), więc powoli rezygnuje z propozycji funkcji. Prócz przekonania go do wydania kodu, w tym przypadku praktycznie nic nie możesz zrobić, nawet w odniesieniu do powyższego.

Szczególnie projekty typu open source są przyjazne dla nagród lub finansowania rozwoju określonej funkcji, nawet jeśli nowa funkcja nie dotarła do oficjalnych wydań.

Ponadto tak, jednym z pomysłów związanych z publikowaniem oprogramowania typu open source jest, aby każdy miał prawo i obowiązek wnieść własny wkład.

W przypadku zamkniętego źródła najlepszym zasobem jest zebranie statystycznie ważnej grupy z bazy użytkowników, która chce rozwiązań takich jak te, które chcesz.

Z mojego doświadczenia wynika, że ​​taka odpowiedź jest zwykle udzielana, jeśli żądanie użytkownika nie pasuje do celu projektu. Zdarza się, gdy ludzie myślą, że zaimplementujesz wszystko, co ci proponują, i jeszcze więcej - za darmo, open source i wspaniałą i szczęśliwą przyszłość.

„Prześlij łatkę” jest stosunkowo niegrzeczną odpowiedzią (należy jej oczywiście unikać. Szczególnie w tej zwięzłej i ostrej formie. Istnieje wiele sposobów wyrażenia z grubsza tej samej wiadomości - na przykład „zaproś” użytkowników do pomocy, ponieważ ty nie masz czasu na samodzielne wdrożenie). Ale w tej chwili jest to wyraźny wskaźnik „przestań marnować mój czas”. W związku z tym niewiele można z tym zrobić, nie ma też odpowiedzi „kanonicznej”.

Najlepszą odpowiedzią, jaką mogę wymyślić, jest przedstawienie łatki . Zakładając, że łatka działa, przynajmniej udowodniłeś, że pomysł nie jest całkowicie nierealny. Zazwyczaj oznacza to, że osoby odpowiedzialne za projekt ponownie rozważą propozycję.

„Prześlij łatkę” jest uzasadnionym pomysłem na pomysły, które nie pasują do celów projektu. Prawdopodobnie na dłuższą metę lepiej jest po prostu powiedzieć, że pomysł jest do kitu lub próbujesz wykorzystać projekt do czegoś, co wykracza daleko poza zamierzony zakres, ale „hej, jeśli uważasz, że to, o co pytasz, jest tak trywialne, dlaczego nie” t spróbujesz dopasować go do naszej istniejącej bazy kodu ”jest czasem odpowiedni.

Jeśli jest niewielki i naprawdę przydatny dla zamierzonych użytkowników projektu, po prostu prześlij raport o błędzie, jasno opisz problem, podaj kroki do odtworzenia, wskaż, że używasz bieżącej kompilacji nocnej, i zostaw to.

To, co może wydawać się drobną, prostą zmianą, która pomogłoby tonom użytkowników, może być ogromnym bólem w dupie, którego nikt by nie użył poza tobą. To najlepszy przypadek dla „prześlij łatkę”.

Możliwe jest również, że natknąłeś się na przypadek takiego jak notoryczny opiekun glibc, który wydaje się mieć jednotorowe zdanie, że jego system jest wszechświatem, jego interpretacja specyfikacji jest słowem boga, i to wszystko, niezależnie od tego, ile osób wolałoby inaczej.

Sugerowałbym utworzenie projektu wdrożenia tej funkcji na stronach takich jak RentACoder / ELance / itp. I opublikowanie o tym na forum oryginalnego projektu open source. Każdy z programistów projektów open source, w tym autor, ma teraz motywację finansową do rozważenia twojego żądania.

Zarejestrowałem się tylko po to, by odpowiedzieć na to pytanie.

Czy istnieje potrzeba retorty? ta odpowiedź jest zwykle używana, gdy programista wie o problemie, ale nie uważa go za ważny.

Dam ci przykład na żywo. ubuntu zrezygnowało z obsługi systray (ale można obejść tę sytuację, umieszczając aplikację na białej liście) i dodało nowe wskaźniki aplikacji. niektóre aplikacje, takie jak Jupiter, korzystały z obsługi systray, więc programista poinformował o pracy zamiast obsługi wskaźnika aplikacji, więc poprosiłem programistę o dodanie dodatku wskaźnik aplikacji, odpowiedź brzmiała: „Prześlij nam łatki”. pytając o powód, dla którego postanowili tego nie wdrażać. było to

Nie jestem zainteresowany spędzaniem czasu na budowaniu wsparcia dla libra1ry, którego nigdy nie użyję tylko dlatego, że żąda tego ktoś, kto ma dużo pieniędzy, umieszczając na czarnej liście moje aplikacje do poprawnego działania w dystrybucji Linuksa tylko dlatego, że może.

Gdyby to był prawdziwy problem techniczny, prawdopodobnie podjąłbym działania, ale jest to wyłącznie manewr polityczny, więc nie, nie sądzę.

Nie, dodam go do białej listy

Słusznie. programista ma powód, aby nie implementować funkcji, ale jest gotowy zaakceptować łatki. to nie jest tak naprawdę niegrzeczne i obraźliwe, więc nie było potrzeby retorty.

Podsumowując: kanoniczna retorta polegałaby na przesłaniu łatki, ale jeśli nie, nie ma potrzeby retorty

Rozpocznij nagrodę za wybraną funkcję.

Lub wyjdź i kup produkt, który twierdzi, że robi dokładnie to, czego chcesz i nadużywaj jego personelu pomocniczego, gdy odkryjesz, że marketing nie spełnia twoich oczekiwań.

Najlepsze, co mogę wymyślić, to „ssać”.

Niestety, to oczywiście nie jest bardzo pomocne, ale myślę, że to tylko jedna z niefortunnych sytuacji, w których użytkownik jest całkowicie wkręcony. Brutalnie szczery apel do sumienia dewelopera to ostatni wysiłek.

Możesz spróbować zaoferować ( kaszel ) „darowizny”, aby rozwiązać Twój problem, ale obawiam się, że taka praktyka, jeśli zostanie zastosowana, doprowadzi do naprawdę złej utraty integralności w branży, ponieważ poprawki błędów nigdy nie powinny być opłacalne, ponieważ „Darmowe” lub komercyjne oprogramowanie.