"Açık kaynak, bir düzeltme eki gönder" şeklinde kanonik iman nedir? [kapalı]

Bir üründe, özellikle açık kaynakta bazı özellikler önerme tehlikesi, “neden yapmıyorsunuz?” Cevabını almanızdır.

Bu geçerli ve değişikliği kendiniz yapabilmeniz harika. Ancak, programcılar kullanıcıların diğer programcılar olsalar bile, programcıların kullanıcıların sesini dinlemesiyle ürünlerin sıklıkla geliştiğini biliyoruz. Ve bu değişiklikleri yapmanın etkili bir yolu, halihazırda projede çalışan ve fikri uygulayan birisini içerebilir.

Yazılım geliştirme problemlerine atıfta bulunmak için kullanılan bazı genel terimler vardır. örneğin Bisiklete binme . Esasen cevap veren ortak bir terim var mı: "Evet, dünyadaki hemen hemen her şeyi değiştirebileceğimi biliyorum - kapalı kaynak bile. İşe alabilirim ve gidip bu kodu yazabilirim. Ama bu durumda ben sadece yapıyorum Aslında bu değişikliği kolayca yapmak için zaten uygun olan başka bir kodlayıcı için yararlı olabilecek bir gözlem - ya da genel olarak olasılıkları tartışmak. ”

[ps (birkaç gün içinde) - "yama gönderme" nin sık sık espri anlayışı ile söylendiğini ve uygun esprili bir cevap aradığımı belirtmeliydim.]

Bu zor bir nokta: kullanıcı bir ürün için doğrudan veya dolaylı olarak ödeme yapmadığından, bir özelliğin uygulanmasını isteyemez. Sanki ürün sipariş eden bir paydaş ya da doğrudan bir müşteri değilsiniz, hatta bir ticari ürünün son kullanıcısı bile değilsiniz.

Bu söyleniyor, "bir yama gönder" geçerli bir cevap değil. Bu nazik değil. Doğru değil. Açık kaynaklı bir ürün için bile. "Bir yama gönder" kısa versiyonudur:

"Ürünümüzü beğenip beğenmemeniz umrumda değil. İsterseniz gidin ve değiştirin, ancak müşteri isteklerinizle bizi rahatsız etmeyin."

Yama göndermeye ne dersin?

O kadar kolay değil. Yapmak için:

• Açık kaynak projesinde kullanılan dilleri bilmeniz gerekir.

• Kaynak kodunu, sürüm kontrolünden değiştirebilmeniz için yükleyebilmeniz gerekir.

• Yüklü yapı bağımlılıklarının tüm doğru sürümlerine sahip olmalısınız (hem çalışma zamanı kitaplıkları hem de derleme araçları dahil).

• Bazı durumlarda çok açık olmayan bu kaynak kodunu derleyebilmeniz gerekir . Özellikle, büyük bir projenin derlenmesi ve 482 hata ve binlerce uyarı göstermesi birkaç saat sürdüğünde, gidip bu hataların kaynağını aramak için cesaretli olabilirsiniz.

• Projenin nasıl yapıldığını , kod kodlama stilinin ne olduğunu, varsa, birim testlerinin nasıl yapılacağını, vb. Çok iyi anlamanız gerekir . Eğer proje iyi bir dokümantasyona sahip değilse (genellikle açık kaynaklı projeler için bu geçerlidir) ), gerçekten zor olabilir.

• Kendinizi projeye ve projeye aktif olarak katılan geliştiricilerin alışkanlıklarına adapte etmeniz gerekir. Örneğin, günlük .NET Framework 4 kullanıyorsanız, ancak proje .NET Framework 2.0 kullanıyorsa, LINQ, Kod Sözleşmeleri ve çerçevenin en son sürümlerinin diğer binlerce yeni özelliğini kullanamazsınız.

• Düzeltme ekiniz kabul edilmelidir (değişikliği yalnızca kendiniz için yapmazsanız, toplulukla paylaşma niyeti olmadan).

Niyetiniz projeye aktif olarak katılmaksa, o zaman tüm bunları yapabilir ve zamanınızı harcayabilirsiniz. Öte yandan, sadece can sıkıcı küçük bir hata veya eksik, basit bir özellik varsa, projeyi incelemek günler, haftalar veya aylar geçiriyorsa, o zaman işi birkaç dakika içinde kendiniz yapmak makul olmaz.

Öyleyse "açık kaynak, bir yama gönder" e kanonik bir iman var mı? Sanmıyorum Ya kaba olmayan birine açıklarsın ya da onunla konuşmayı kesersin.

Kanonik imbik bir yama göndermektir.

Bu, geliştiricilerin makul herhangi bir zaman diliminde bir şeyler yapmayı başaramayacaklarını düşündükleri standart cevaptır, ancak defalarca gündeme gelmiştir.

Tekrar tekrar gündeme geldiğinde en haksızlık olur, ancak en son sözü edilen kişi bunu bilmez ve hemen “bunun için yamalar alıyoruz” u alır. Bu durumda, bakıcı tartışmadan bıkmış ancak kullanıcı bunun yeni bir konu olduğunu düşünüyor. Her neyse, büyük olasılıkla hemen "düzeltme ekleri" alıyorsanız, kişisel olarak almamalısınız, ancak konuyla ilgili daha fazla ayrıntı için arşivleri ve hata izleyiciyi okumak isteyebilirsiniz.

Kendinizi tekrar tekrar talep ediyorsanız, "düzeltme ekleri alma" potansiyel olarak nispeten kibar bir fırçalama, yani daha az kibar alternatifler olması amaçlanmıştır ...

Ve elbette hiç kimseye açıklama yapmadan "yamalar" diyecek kaba bakım sahipleri var, ama bunun bir azınlık olduğunu söyleyebilirim.

Çok fazla kullanıcılı bir açık kaynak projesini sürdürdüyseniz, bakıcıların ulaşabileceğinden 100 kat daha fazla istek olduğunu ve bu isteklerin çoğunun istek sahibi için önemli olduğunu, ancak aşırı zor olacağını bileceksiniz. veya birçok başka kullanıcıyı rahatsız eder veya yalnızca proje ve kod temeli hakkında genel bir anlayışla görülebilen başka bir kusuru vardır. Ya da bazen sadece yargılama çağrıları vardır ve tekrar tekrar tartışmak çok zaman alır.

Açık kaynaklı olmayan çoğu şirket, geliştiricilere hiçbir şekilde erişmenize izin vermez ve yalnızca müşteri desteğinden sessiz bir muamele veya kibar ancak sahte bir hikaye edinirsiniz. Bu nedenle, açık kaynak kodunda en azından bazı seçenekleriniz var (özelliği kodlaması için birine ödeme yapın, vb.) Ve geliştiriciler kaba olsalar da en azından düz cevaplar verirler. Her zamanki gibi "hayır" demeyi tercih ederim, yol haritamızda ... [2 yıl sonra] ... hala yol haritamızda "bir çok satıcıdan aldığım türden bir şey ...

Yani bir retort olduğunu sanmıyorum. Belki de açık kaynaklı bakım uzmanı gerçekten çok meşguldür, belki de bir pisliktir, ama her iki durumda da, zor bir işi vardır ve son söz sahibi bir tartışmaya girmenin hiçbir yere gitmemesi muhtemeldir. Yapabileceğiniz en iyi şey bir şekilde katkıda bulunmak ve yapıcı olmaya çalışmaktır.

Belki kod değildir, ancak muhtemelen yapabileceğiniz birçok analiz ve kullanıcı senaryosu belgelendirme vardır. GNOME'un pencere yöneticisini sürdürürken, çoğu zaman insanların tüm kullanıcıları göz önünde bulundurarak küresel olarak bir sorunu analiz etmeleri ve sorunları, artılarını ve eksilerini ve küresel bir perspektiften ne olacağını gerçekten yazmaları yararlı olurdu .

(Bunun yerine, olağan olan şey, önemli olan tek kişisiydiler ve takaslar yokmuş gibi alevlenmeye başlamaktı. Ve bu harikaydı ve bir veri noktasıydı ve çoğu zaman kibar kalmayı ya da eninde sonunda problemlerini çözmeyi başardım .. Alev almak daha hızlı bir şey yapmaz, sadece konuyla ilgili duyguları karıştırır ve herkesin zamanını boşa harcar.)

Bu cevabı almanızın nedeni, bakıcıların gerizekalı olmaları değil, onları sizin için özelliğiniz üzerinde çalıştıkları değer teklifi konusunda yeterince ikna etmemiş olmanızdır .

En iyi yanıt, özelliklerinizi bir bütün olarak toplumlarına değerleme hakkında bir diyalog başlatmak , onları fikirlerini değiştirmeye ikna edip edemeyeceğinizi görmek. Belki haklıdırlar ve kendi toplumlarının ihtiyaçları hakkında sizden daha fazla şey biliyorlar - ama sonra tekrar, belki de değil.

Bu özellik sadece sizin için değerliyse ve topluma hiçbir değeri olmayan veya hiç değeri olmayan biriyse, paranın mükemmel bir motive edici olduğunu, tutumlarının şikayet edilmediğini düşünüyorum.

"Açık kaynak, bir düzeltme eki gönder" şeklinde kanonik iman nedir?

Herhangi bir fark yaratabilecek makul bir imkansızlık yoktur. Gönüllüleri yapmaya niyetli olmayan bir şeyi yapmaya ikna etmeye çalışmak zamanınızı boşa harcar ya da daha kötüsüdür.

Seçenekleriniz:

• Yanıtın önerdiğini yapın; yani özelliği uygulayın ve bir yama olarak gönderin. Buna "bir şeyleri geri vermek" denir.

• Bu özelliği gerçek para karşılığında sizin için uygulamak isteyen birini bulun. Projenin kendisi (örneğin sponsorluğa karşılık olarak), proje ile ilişkili bir kişi veya bazı rasgele "işe alınacak kodlayıcı" olabilir.

• Alternatif bir ürün bulun.

"Yararlı" bir öneride bulunduğunuzda bu cevabı aldıysanız, onun yerinde olsaydınız nasıl cevap verebileceğinizi düşünün. Örneğin, önerinin değersiz / iyi düşünülmüş / anlaşılır / vb. Olduğunu düşündüğünüz, ancak uzun süren bir tartışmaya girecek zamanınız veya sabrınız olmadığını düşündüğünüzde SİZ nasıl yanıt verirsiniz?

Uzun süredir devam eden bir açık kaynaklı işletim sistemi projesine katıldım ve en sinir bozucu şeylerden biri "fıstık galerisine" oturan ve sizi "daha iyi" şeyler yapmayla ilgili bir dizi öneriyle karartmış olan insanlar:

• eksik, anlaşılmaz veya düpedüz saçma,
• nesnel düşük başarı şansı olan denenmemiş fikirler,
• uygulamak için büyük miktarda çaba gerektirecek ve / veya
• Projenin belirtilen hedeflerine aykırıdır.

Çoğu zaman en iyi yanıt, kişiyi projeye dahil olmak için sivri bir şekilde zorlamaktır ... ve umarız da "koymak veya susmak" için ipuçlarını aldıklarını ummaktır. Ne yazık ki, en sinir bozucu olanlar bile bir ipucu almaz.

Elbette, bu tür insanlara verilen diğer cevap hiç cevap vermemek ya da onları tamamen görmezden gelmektir.

Siz ve söz konusu programcının eşit olması durumunda cevap makul olacaktır; üstelik, dil ve işaret ettiğiniz bu özel şeyle ilgili diğer her şey hakkında aynı şeyi biliyorduysanız.

Eşit değilsiniz (ya da muhtemelen sadece yapmış olacaktınız), bu yüzden uygun bir retort öneririm:

“Mümkün olduğu kadar hızlı ve iyi bir şekilde yapmam mümkün değil, bu yüzden ilk başta bana yardım etmenizi istedim. Lütfen!”

"İnsanın uzun zamandır harcadığı ve gerçekten iyi olduğu bu şey o kadar basit ki," sokaktan içeri girip herkes kadar iyi bir iş yapabilir. Ben "can.

Kanonik imar, projeyi doldurmak içindir.

"Bir düzeltme eki göndermenin" kanonik cevabı şudur:

"Gerekli becerilere, tecrübeye veya zamana sahip değilim, bu yüzden lütfen bana bira kutularını benim için yapabilecek adama nereye göndereceğinizi söyler misiniz?"

Kapsamlı bir test durumu gönderin .

“Eğer yaparsan, ekleyeceğim” “hayır” dan çok daha iyidir.

İşi bir nedenden ötürü yapamıyorsanız, proje sahibine özel olarak durumu açıklayın.

Kullanmak istediğiniz açık kaynaklı bir projeye bir şekilde katkıda bulunmak istemiyorsanız, bunun yerine ticari destek veya başka bir ticari ürün aramalısınız.

"Yanıtınız için teşekkürler."

Çünkü:

• Sıfır fiyata, talep (özellik istekleri) arzı (söz konusu özelliklerin uygulanması için mevcut kodlayıcılar) aşıyor.
• Ücretsiz sağlanan herhangi bir şey için uğraşmak IMHO sınıfından yoksundur.
• Bu FOSS'un asıl amacı: taş çorbaya besin eklemek için kendi sebzelerini ve etlerini getiren insanlar. Bir şeye katkıda bulunamazsam, o zaman hiç yiyebileceğim için şükretmeliyim ve daha iyi yemek yemediğim için şikayet etmemeliyim.

Hiçbir şey söylemek zorunda değilsin. Geliştiricilerin yanıt verdikleri gerçek, sorunun zaten mevcut olduğunu ve bu durumun (en azından bazı) kullanıcılar için acı çekmesine neden olduğunu bildiklerinin yeterince göstergesidir.

Günün sonunda, söyleyeceğiniz hiçbir şey, istemiyorsa geliştiriciyi sizin için çalışmaya ikna edecektir.

İyi bir açık kaynaklı projede, kullanıcıların hatalar / özellikler gönderebilecekleri ve diğerleri üzerinde oy kullanabilecekleri bir hata / özellik istek sistemi bulunacak ve böylece bakımcılar toplum için bir bütün olarak neyin önemli olduğunu belirleyebileceklerdir. Ancak, özelliğinizi gerçekleştirmenin en hızlı yolu, bunun için bir düzeltme eki göndermektir. Dönem ... bunun için bir yol yok.

Şahsen, "Bu bilinen bir meseledir, ancak ne yazık ki, yakında herhangi bir zamanda ele alınacak bir konu değil. Geliştiriciler başka meseleler üzerinde çalışıyor. Şu anda ETA yok."

"Bir düzeltme eki gönder" yanıtı çok kaba bir durum olduğu için çok kaba:

1. Programın tüm kullanıcıları programcıdır veya tüm hata muhabirleri programcıdır.
2. Tüm programcılar programın dilini biliyorlar.
3. Tüm programcılar, her türlü problemi, her türlü programın sahip olabileceği hakkında bilirler.
4. Tüm programcılar açık kaynak kodlu bir proje üzerinde çalışmak için boş zamanları vardır.

"Yama gönder" yanıtını yapanın, tüm bunları bildiğini varsaysak bile, bu basitçe, "zamanımın X saati, zamanınızın kalktığı saatlerin büyüklüğünden daha değerlidir. sorunu hızlandırmak ve düzeltmek için ".

Genel olarak, bir sorun hakkında bir soru sorduğumda bir geliştiriciden kaba bir yanıt aldığımda, hata aldığım veya gönderdiğimde, bu programı kullanmayı bırakıyorum. Artık uTorrent kullanmıyorum (açık kaynak değil, fakat konu hala geçerli), çünkü "destek" forumlarına verdiğim yanıtlar çok kaba. Bug Raporları forumunda yaşadığım bir sorunu gönderdim. İplik hemen benzer bir konu hakkında başka bir ipliğe bir bağlantı ile kilitlendi, fakat ipliğin içindeki farklı bir konu (tabii ki aynı zamanda kilitliydi). Bu arada, Genel Tartışma forumunda, soruna geçici bir çözüm bulunup bulunmadığını soran bir konu açtım. O parçayı kurtarıp geri dönüp ilk parçamın kilitlendiğini görmem gerektiğinde, Genel'deki parçam kilitlendi ve forum hesabım yıkıcı davranış nedeniyle yasaklandı. UTorrent'i kaldırdım ve o zamandan beri geri dönmedim.

Sadece "bir düzeltme eki gönder" yanıtını vermek kaba IMO'dur, ancak yine de ... ciddi bir şey için açık kaynak kodlu yazılım kullanıyorsanız, ihtiyaç duyulduğunda buna dikkat etmeye hazır olmalısınız.

Aşağıdakiler, Jeremias Maerki'nin (Apache FOP şöhretinden) yazdığı bir yazıya dayanmaktadır :

Bir şey sizin için işe yaramazsa, birkaç seçeneğiniz vardır:

• Bu açık kaynak: kendin düzeltebilirsin.
• Kendiniz düzeltemezseniz, birileri boş vakti gelene ve uygulamanın eğlenceli olduğunu düşünene kadar bekleyebilirsiniz.
• Bu olmazsa, sizin için yapacak birini bulabilir veya işe alabilirsiniz.

Bence "bir düzeltme eki gönder" yanıtının çok geçerli bir tam sürümü.

Bunu her gördüğümde hemen alternatif bir ürün aramaya başladım. Bana göre bu, bakıcıların kullanıcılarını umursamadıkları (projeniz her yerde kullanılıyorsa kötüdür) veya projeye ilgisinin azaldığı tehlikeli bir işarettir. Bunların her ikisi de genellikle projenin yakında öleceği veya geliştiricilerin projeyi ilerletmeyi reddettiği için durgunluktan kurtulacağı anlamına gelir

(Bu tür bir yanıtla gördüğünüz ilk hata raporunun çalıştırdığınızı söylememediğimi unutmayın. Genel bir eğilime bakmak zorundasınız. Hata raporlarının çoğu bu tür bir yanıtla bitiyorsa, bu tavsiyeye uyun. sadece birkaçı, o zaman bunlar büyük olasılıkla bir projenin hedeflerine uymayan veya son derece spesifik olan özellik talepleridir)

@MainMa'nın dediği gibi, yepyeni bir projeye katkıda bulunmaya başlamak çok zor. Çoğu geliştirici bunu aylarca / yıllardır projede çalıştıkları için anlamıyorlar ve bu onlara mantıklı geliyor. Bu bazen dürüst bir hata olabilir.

Bazen özgür yazılımın bira kadar özgür olabileceğini, konuşma kadar özgür olabileceğini ya da ödediğinizin karşılığını alabildiğine şaka yapıyorum.

Şakala derken (çok fazla OSS kullanan bir şirket için çalışıyorum) ama orada bir gerçek olduğunu düşünüyorum - ticari seviyede destek istiyorsanız, o zaman ya ticari yazılımı uygun bir destek anlaşmasıyla kullanmanız ya da size bu düzeyde destek sağlayan açık kaynaklı yazılım çözümü (genellikle bunu sağlamak için para ödenen biriyle ancak üzerinde çalışmak için geliştirme kaynağını çalıştıran veya görevlendiren kuruluşunuz aracılığıyla).

"Bir yama gönder" çılgına dönüyor, ancak OSS hakkında bir şeyi vurguluyor ve belki de OSS'nin her durumda herkes için doğru olmadığı, en azından bunun için sağlam bir destek çerçevesine sahip olduğunuzdan emin olmadan bir hatırlatma olmalı. kurum içi, ya da topluluk aracılığıyla ödenen).

Birada olduğu gibi özgür olan ancak konuşmadaki gibi olmayan açık yazılımları düşünürüz (açık olmayan ücretsiz). Belki de bu biz konuşmada serbest ama yazılım düşünmesi gereken bir durumdur değil bira gibi.

Bakımlı bir alternatife geçin.

Bakımlı ve açık kaynaklı projelerle ilgili tecrübelerime göre, iyi tanımlanmış bir hata raporu veya özellik isteği oluşturursanız, uygulama şansı çok yüksektir.

"Bir seferde sadece bir şey üzerinde çalışabilirim, ama aynı anda birçok şey hakkında şikayet edebilirim. Her iki fonksiyonun da yararlı olduğunu düşünüyorum." - ycombinator'de akkartik .

Bir proje üzerinde çalışırken, bültenleri ve desteği sağlayan, söylenmeyen, ima edilen, dev ve kullanıcı arasında destek sözleşmesinin ortaya çıktığını düşünüyorum. Geliştirici, talep üzerine özellik ekleme de dahil olmak üzere, kullanıcıları için kod tabanını destekleme sorumluluğunu üstlendi.

"Bir yama gönder" temel olarak kullanıcılara parmak veriyor, bence. Bu bağlamsaldır - bazen uygulamak için çok fazla çaba harcar, bazen mevcut projeyi mahveder veya göz kamaştırıcı bir creaturitis veya başka bir çok nedenden herhangi birine neden olabilir. Ancak, nihayetinde, "canını sıkmıyor, yapmıyorsun" diyor. Aklımda, bir düzeyde, o söylenmeyen sözleşmenin ihlali.

Yapılması gereken birkaç yol var.

• Özellik teklifi ve oylama. ama bu zaman alır.

• Yamayı yapmak için ihtiyaç duyan bir şirket tarafından işe alın. Açıkçası bu en iyi çözüm, ancak yükseltmek istediğiniz açık kaynaklı yazılımı yapan adamla işbirliğine hazır olun.

• Özelliğin neden ilk olarak uygulanmadığını bulmak da önemlidir. Çoğu zaman bu özellik yazılım projesinin dışında kalıyor: ekip bu özelliği istemiyor, gerekli hissetmiyor veya sadece bir şey yapmanın iyi bir yol olmadığını düşünüyor. Bu durumda sadece projeyi doldurmalı ve kendiniz yapmalısınız.

• İstediğinizi yapan özel bir yazılım kullanın.

• OOP yazılımının çoğu zaman bir özelliği bütünleştirme sürecini kolaylaştırdığını unutmayın.

• Bir e-posta listesinde, irc'de veya bir forumda sızlanmak sadece programcıları sinirlendirecek ve OSS yandaşlarına cephane verecek.

Olacak Söyleyebileceğin şey yok yapmak onu bunu. Sonuçta, neden o yapmalı? Bir kullanıcının istekleri yüzünden mi? Bir sebep yeterince iyi değil.

Ancak , makul sayıda kullanıcı toplayabilir ve rasyonel nedenler (“istiyorum” derken mantıklı bir neden değildir.) Bu özelliğin neden yararlı olabileceği, genel olarak ve siz ve diğerlerinin sayısı fikrini değiştirebilir .

Bununla birlikte, dikkate alınması gereken özel bir durum da vardır. Bu bir dev. yavaş yavaş onu terk etmek isteyen (yapacak başka şeyler var), ve bu yüzden, o, isteklerini yavaş yavaş terk ediyor. Ayrıca, kodu serbest bırakması için onu ikna etmeye çalışmak dışında, bu durumda, yukarıdakilere göre bile yapabileceğiniz hiçbir şey yoktur.

Özellikle açık kaynaklı projeler, yeni özellik resmi bültenlere sunmasa bile, belirli bir özelliğin gelişiminin finanse edilmesi veya finanse edilmesi için elverişlidir.

Artı, evet, açık kaynak yayınlamanın arkasındaki fikirlerden biri, herkesin ve herkesin kendi katkılarını yapma hakkına ve sorumluluğuna sahip olmasıdır.

Kapalı kaynak ile, en iyi kaynağınız, istediğiniz gibi çözümler isteyen kullanıcı tabanından istatistiksel olarak önemli bir grup toplamaktır.

Tecrübelerime göre, bu cevap genellikle kullanıcı talebi projenin amacına uygun değilse verilir. İnsanlar size sundukları her şeyi ve biraz daha fazlasını - ücretsiz, açık kaynak ve harika ve mutlu bir gelecek için uygulayacağınızı düşünüyorlar.

'Bir yama gönder' nispeten kaba bir tepkidir (ve elbette kaçınılması gerekir. Özellikle de bu özlü ve keskin biçimde. Kabaca aynı mesajı ifade etmenin pek çok yolu vardır - örneğin, kullanıcıları yardım etmeye davet edin ' kendi başınıza uygulamak için zamanınız yok). Ancak, açık bir şekilde 'zamanımı boşa harcamayı bırakma' göstergesidir. Dolayısıyla, bu konuda yapabileceğiniz pek bir şey yok, ne de 'kanonik' yanıt yok.

Aklıma gelen en iyi cevap aslında bir yama sunmak . Yamalarının işe yaradığını varsayarsak, en azından fikrin tamamen gerçekçi olmadığını ispatladınız. Genellikle bu, projeden sorumlu kişilerin teklifi yeniden değerlendireceği anlamına gelir.

"bir yama gönder", projenin amaçlarına uygun olmayan fikirler için meşru bir fırçalamadır. Uzun vadede, sadece fikrin berbat olduğunu söylemek ya da projeyi amaçlandığı kapsamın çok dışında bir şey için kullanmaya çalışmak muhtemelen daha iyidir, ancak "hey, sorduğunuz şeyin önemsiz olduğunu düşünüyorsanız, neden yapmayın?" t Mevcut kod tabanımıza sığdırmaya çalışırsanız "bazen uygun olur.

Küçük ve projenin amaçlanan kullanıcıları için gerçekten kullanılıyorsa, o zaman sadece hata raporunu gönderin, sorunu net bir şekilde tanımlayın, çoğaltmak için adımlar atın, geçerli gece derlemesini kullandığınızı belirtin ve bu konuda bırakın.

Tonlarca kullanıcıya yardımcı olacak küçük, basit bir değişiklik gibi görünen şey aslında sizden başka kimsenin kullanmayacağı büyük bir acı olabilir. "Bir yama gönder" için en iyi durum budur.

Aynı zamanda, sisteminin evren olduğu tek bir görüşe sahip gibi görünen üncü glibc koruyucusu gibi bir davaya girmiş olmanız, özellikleri yorumlaması tanrının sözü ve bunun için olanın hepsi ne olursa olsun mümkündür. Kaç kişinin aksi takdirde tercih edeceğini.

Özelliği RentACoder / ELance / etc gibi sitelere uygulamak için bir proje oluşturmanızı ve orijinal açık kaynaklı proje forumunda yayınlamanızı öneririm. Yazar da dahil olmak üzere açık kaynaklı projelerdeki programcılardan herhangi birinin şu anda isteğinizi dikkate almak için finansal bir teşviği var.

Aslında sadece bu soruyu cevaplamak için kaydoldum.

Bir imbik için ihtiyaç var mı? Bu yanıt genellikle geliştirici konuyu bildiğinde kullanılır ancak önemli olmadığını düşünür.

Sana canlı bir örnek vereceğim. Ubuntu, systray desteğini düşürdü (ancak bir uygulamayı beyaz listeleyerek işe yarayabilir) ve yeni uygulama göstergeleri ekledi. Jüpiter gibi bazı uygulamalar systray desteğine güveniyordu, bu yüzden geliştirici, uygulama göstergesi desteği eklemek yerine geçici çözümden bahsetti. Bu yüzden geliştiriciden, uygulama göstergesini desteklemesi için cevabın "Bize yamaları gönder" olduğunu sordum . Sebebini sormak için bunu yapmamayı seçtiler. bu vardı

Asla kullanmayacağım bir kütüphaneye, zamanımın desteğini harcamakla hiç ilgilenmiyorum çünkü çok parası olan bir kişi, uygulamalarımın Linux dağıtımında düzgün çalışabilme yeteneğini kara listeye alarak istediğini yapabiliyor.

Gerçek bir teknik problem olsaydı, muhtemelen harekete geçerdim ama bu tamamen politik bir manevradı, bu yüzden sanmıyorum.

Hayır, sadece beyaz listeye alacağım

Yeterince adil. geliştiricinin bir özelliği uygulamak için bir nedeni yoktur ancak yamaları kabul etmeye isteklidir. Bu gerçekten kaba ve saldırgan değil, bu yüzden retorta gerek yoktu.

Sonuç: kanonik retort yamayı göndermek olacaktır, ancak yapamazsanız bir retorta gerek yoktur

İstediğiniz özellik için bir ödül başlatın.

Ya da dışarı çıkın ve ne istediğinizi yaptığınızı iddia eden ürünü satın alın ve pazarlamanın beklentilerinize uymadığını fark ettiğinizde destek personelini kötüye kullanın.

En iyi düşünebildiğim "emmek".

Maalesef bu kesinlikle çok yardımcı olmuyor ama bence kullanıcının tamamen battığı talihsiz durumlardan sadece biri. Geliştiricinin vicdanına vahşice dürüst bir çağrı son bir hendek çabasıdır.

Sorununuzu gidermek için "bağışlar" teklif etmeyi ( öksürük ) deneyebilirsiniz , ancak ortak bir uygulama yapıldığında böyle bir uygulamanın sektörde gerçekten kötü bir bütünlük kaybına neden olacağından korkuyorum, zira hata düzeltmeleri hiçbir zaman kârlı olmamalıdır. "Ücretsiz" veya ticari yazılım.