Stosunki deweloperów z projektami i jak to wygląda z zewnątrz
Jakiś czas temu pisałem o tym, że firefox nie jest zbyt przyjazny deweloperom, tzn. można tam narzucać decyzje niezależnie od tego, czy się to szeregowym deweloperom podoba, czy też nie. Podejście słuszne z punktu widzenia produktu (użytkowników), ale już średnio, jeśli chodzi o samych deweloperów.
Z kolei w tekście o zasadach działania pld tłumaczyłem, że, w przeciwieństwie do pld, debian może sobie pozwolić na narzucanie swoim deweloperom obowiązków i wyciąganie konsekwencji w przypadku nie wywiązywania się z nich.
W linuksie też jest coś podobnego - jeśli haker chce mieć swoje zmiany w jądrze, to on sam musi o to zadbać, Linus go na kolanach błagał o nic nie będzie.
Właśnie zrozumiałem jaki jest (bardzo oczywisty) powód wszystkich powyższych sytuacji (oraz niezliczonej ilości podobnych) - istnieje pewien punkt przełomowy w każdym projekcie, po przekroczeniu którego to deweloperom bardziej zależy na uczestnictwie w projekcie, niż projektowi na posiadaniu tychże deweloperów. Określenie tego punktu jest zasadniczo karkołomnym zadaniem, bo wpływa na to bardzo wiele czynników. Np. w przypadku projektu xfree, jeszcze zanim powstało x.org, to wszystkim dookoła zależało na tym, by mieć wpływ na projekt. Obecnie to xfree chciałoby mieć deweloperów, ale za późno, bo ci sobie znaleźli coś lepszego. Linux na początku był czymś do użytku własnego i pomoc, jaką otrzymywał Linus od innych, powodowała, że zależało mu na każdym nowym deweloperze (i użytkowniku, bo ci mu przysyłali dolary :). Obecnie pewnie dalej mu zależy, ale w skali makro, a nie na każdym pojedyńczym człowieku. X.org przez samo swoje powstanie odpowiedział na spore zapotrzebowanie na tego typu projekt, więc nie musiał na początku swojego istnienia zabiegać o deweloperów. Debian, o ile mi wiadomo, miał podobną sytuację. Linux osiągnął punkt przełomowy bardzo szybko (bo zapotrzebowanie było od dawien dawna, a hurda nigdzie na horyzoncie). Ale już niezliczona ilość małych projekcików jest w sytuacji odwrotnej - to ich twórcom (chociaż przeważnie tylko jednemu twórcy) zależy na tym, by znaleźli się ludzie do pomocy. PLD, choć zasadniczo jest dosyć spore, też jest w takiej sytuacji - w dystrybucji zawsze jest coś do zrobienia i znający się na rzeczy ludzie są zawsze potrzebni (zwłaszcza porównując nasz zespół z tym od fedory, ale o tym pisałem wczoraj).
I jeszcze jedna rzecz - od obecnego wydania, w Linux+ jest dział aktualności pldowych (analogicznie do paru innych dystrybucji, jakie tam są). Znajduje się tam spora ilość informacji, na które ja nigdy nie zwróciłem uwagi (i nie miałbym pojęcia, że kogoś mogą one zainteresować; tylko dowód na to, że, żeby coś relacjonować, to trzeba być osobą z zewnątrz) oraz między innymi... hmmm... 'naiwne' podsumowania niektórych kwestii. "Wraz ze zbliżającym się wydaniem PLD Ac deweloperzy PLD zdecydowali się przenieść rozmowy z listy devel-pl na devel-en". Nie, nie zdecydowali się, jest to bardziej złożona kwestia i tego typu stwierdzenie jest bezpodstawne. Analogicznie w artykule o nagłówkach jądrowych - "Prawdpopodobnie, praca Mariusza nie będzie już niedługo potrzebna. Zaczyna się proces porządkowania plików nagłówkowych". To też jest mocno bezpodstawne twierdzenie (drugie zdanie, pierwsze jest warunkowe :), bo gadanie o "no to bierzemy się do porządkowania!" jest pewnie obecne na lkmlu od co najmniej paru lat i jeśli ostatnia dyskusja nadal nie przyniesie żadnych efektów (a najwyraźniej nie przynosi), to będę już z czystym sumieniem święcie przekonany, że, żeby coś z tym ruszyć, to sam musiałbym się za to zabrać. Albo - "Na szczęście, Linus w końcu wyznaczył katalogi, w których mają się one znaleźć. Wyraził też otwartość na wszelkie łatki robiące porządek w plikach nagłówkowych jądra. To też nie jest do końca poprawne, bo Linus wyraźnie stwierdził, że jeśli łatki mają tylko robić porządek, to można je słać na /dev/drzewo. Żeby łatka została zaakceptowana, to musi rzeczywiście poprawiać jakiś problem.
Oczywiście nikogo tutaj nie krytykuję (hehe, obaj autorzy powyższych stwierdzeń będą to czytać, więc ten disclaimer musiałem umieścić :), zastanawia mnie tylko, z czego te niedopowiedzenia wynikają. Z tego, że w gazecie niespecjalistycznej niektóre tematy trzeba skracać, eliminując niuanse, które, choć kluczowe dla sprawy, byłyby i tak niezrozumiałe dla czytelników? (a poza tym by się nie zmieściły w gazecie :). A może z tego, że, jeśli nie jest się bezpośrednio zaangażowany w dany temat, to się niuansów po prostu nie zauważa (wada 'zewnętrzności' reporterów)? Albo z wszystkich tych powodów po trochu?
Mniejsza o to. Z ciekawych informacji o pld, jest info o firmie RAKS, która z pld zaczęła korzystać. I arekmowa informacja o tym, że mu by się przydały USB Pen Drive 256mb oraz PPC G4 z CDROMem, żeby podorabiać do nich wsparcie z pld. Oczywiście jest link do strony ze szczegółami, tyle tylko, że strona jest na starym pld-linux.org, którego już nie ma. Więc nawet, jeśli znalazłby się ktoś chętny, to i tak okazja przepadła. Czyli może jednak pilnowanie PR i bezpośredni dostęp do gazet o zasięgu ogólnopolskim mogą być przydatne nawet takiemu zatwardziale niemarekingowalnemu projektowi, jakim jest pld?
22 I 2005 o 15:00:33
Mój pendrive 256MB działa lepiej niż pod windowsami xp i nie wymagał żadnych zmian w konfiguracji (czysty udev + hotplug).
22 I 2005 o 15:06:05
Tu chodziło chyba o wsparcie do rcscriptsów, żeby można się było bootować z pendrive'a.
22 I 2005 o 15:06:40
PR każdemu projektowi się przydaje i co do tego nie ma wątpliwości.
22 I 2005 o 15:07:50
mmazur: a czymś to się rózni od bootowania ze zwykłego dysku (poza koniecznymi zapewne zmianami w geninitrd)?
22 I 2005 o 15:10:20
Zielonego pojęcia nie mam. Arka się pytaj o szczegóły.
22 I 2005 o 15:12:46
Gwoli ścisłości -- firma, do której strony odnośnik zamieściłeś, nie nazywa się RAKS, tylko MSM, RAKS to ich sztandarowy produkt. Pracowałem tam parę lat temu, fajnie było...
22 I 2005 o 15:13:43
Pewne stwierdzenia w przytoczonym artykule są oparte na przypuszczeniach i nie do końca zakonczonych dyskusjach. Tak to jest jak materiały trzeba oddać na dwa miesiące przed drukiem. Nieraz plułem sobie w brodę, że tydzień po wysłaniu wszystkiego Linus stwierdzał ,,a w zasadzie to nie'' albo ,,miałem na mysli coś innego, ale wy wszyscy mnie nie zrozumieliście''.
W momencie pisania dyskusja wydawała się zbliżać do jasnego zakończenia - ,,od przyszłego tygodnia przy okazji robienia zmian będziemy przenosić nagłówki gdzie indziej''. Życie pokazało inaczej.
Z drugiej strony cieszę się, jak dobrze wyczuje co z dyskutowanych rzeczy znajdzie się w jądrze i w momencie gdy L+ pojawia się w sklepach dana rzecz jest już w jądrze. Tak bylo np. z kernel events, debugfs, ATA-over-Ethernet.
22 I 2005 o 15:13:54
"Oczywiście jest link do strony ze szczegółami, tyle tylko, że strona jest na starym pld-linux.org"
Bo co to za pomysł w cholerę wywalać starą stronę i zaczynać wszystko od nowa? Jakakolwiek by ona nie była, to jednak była i należało ją ulepszać, a nie psuć. Ciekawe ile jeszcze ważnych linków teraz wskazuje w nicość... A dobrej strony nie będziemy mieli nigdy, jeśli przy każdym problemie będziemy zaczynać od nowa.
22 I 2005 o 15:15:23
Spoko, to, co będzie teraz robiło za główną stronę, będzie już na stałe i będzie tak zrobione, żeby się (a) łatwo tego używało i (b) jak najbardziej przypominało resztę infrastruktury. A backup całości i postawienie gdzie indziej, to jest po prostu kwestia użycia tara :)
22 I 2005 o 15:18:03
A tak, cykl wydawniczy linux+ jest po prostu zajebisty, jak w grudniu miałem pytania odnośnie materiałów do marcowego wydania :)
22 I 2005 o 16:37:04
Ja mialem pisac dla L+ niusy o PLD ale sie wycofalem heh.
22 I 2005 o 18:54:46
Niestety z artami gazetowymi jest taki problem ze lutowy numer byl zamykany przed grudniem, kiedy to strona dziala calkiem dobrze.
24 I 2005 o 18:39:24
Te wątki o tworzeniu nowych rzeczy na miejsce starych (strona, cała organizacja PLD) przywodzą mi na myśl historię Intela i jego serii x86.
Czytałem kiedyś o tym artykuł i wynikało z niego, że projektanci Intela z chęcią pozbyli by się wstecznej kompatybilności i zestawu zbędnych komend przez co mogli by zrobić o wiele lepszy i być może tańszy procesor, ale... nie mogą. Intel stał się ofiarą własnego sukcesu, klienci są pewni produktów z lini x86, powstało na tą platformę mnóstwo programów, a tworzenie czegoś nowego jest zbyt ryzykowne.
I co zrobił Intel? Poszedł z prądem, nadal opiera się na "starej" technologii, ale dodaje do niej coraz to nową funkcjonalność. I przy tym zmienia nieco strukturę na bardziej uporządkowaną zachowując nadal wstęczną kompatybilność.
Przed chwilą miałem nawet pomysł, żeby zasugerować stworzenie projektu *obok* PLD, a potem przeniesie tam ludzi, którzy będą zainteresowani, ale od razu odrzuciłem ten pomysł (piszę to tylko po to, żeby ktoś nie powtórzył tego błędu :-) ).
Powodem do jego odrzucenie był artykuł o refactoringu (http://blog.ianbicking.org/rewriting-and-refactoring.html)
. Autor opisuje jak to dzięki zmianie już istniejącego kodu zaoszczędził czas i możliwe nowe błędy. Natomiast tobie pomogłoby to w końcu dowiedzieniu się jak to wszystko działa i dlaczego.
Moja rada: bądź jak skapująca kropla, powoli drąż dziurę w skale, a w końcu otrzymasz spodziewane efekty :-)
24 I 2005 o 18:41:51
Mój biedny umysł płata mi figle, mam wrażenie, że już to pisałem, mam nadzieję, że to tylko błąd systemu, a nie fakt ;-)
24 I 2005 o 18:42:24
Microsoft też jest niewolnikiem swojego sukcesu dzięki kompatybilności w dół.
Do niedawna był też niewolnikiem x86 ale nowy-stary kernel ich ratuje.
24 I 2005 o 18:44:38
PS - idea stworzenia projektu "obok" nie jest mi obca i sam ją kiedyś zastosowałem z sukcesem, choć do tego trzeba uporu i szczęścia.
Po prostu, bywają projekty których poprawianie/przemeblowanie zajmuje więcej czasu niż stworzenie ich od początku.
24 I 2005 o 18:45:52
nbw: ale to nic nie zmienia, podałem tylko przykład z pewnością, nie oni pierwsi i nie ostatni, chodzi o wymiar ogólny. Ale jeśli microsoft stał się tak potężną organizacją mimo tego problemu, to czemu by nie PLD (w sensie rozrosło się, a nie opanowało świat :-) )...
24 I 2005 o 18:46:58
nbw.PS: tyż prawda :-)
24 I 2005 o 19:03:02
Intel zrobił wreszcie to, co chciał. Nazywa się to to ia64.