Open source - tworzenie zespołu w celach edukacyjnych, Nauka pracy w zespole, tworząc projekt Open Source Opcje

[Frozen]

Witam.
Mam takie pytanie, co sądzicie o tworzeniu zespołów, które pisałby w PHP skrypty Open Source, przede wszystkim w celach edukacyjnych? (czyli niekoniecznie tworzymy nowe rewelacyjne rozwiązanie które zmieni świat, ale np. CMS'a)
Czy pracowaliście już w takich projektach? Czy zaczynaliście tak swoją karierę programistycznai?

Pytam bo ciekawi mnie jak to jest, gdy zaczyna się pracę dla jakiejś firmy. Wiadomo, każdy przy nauce PHP coś tam "kodzi", ale pracy w zespole trzeba się chyba nauczyć? Systemy kontroli wersji itp. Tym bardziej gdy jest różny poziom umiejętności. Jak to jest , gdy firma przyjmuje pracownika, musi najpierw poświęcić trochę czasu na "wprowadzenie" go do swojej działalności i na odpowiednie wyedukowanie? Jak wyglądał wasz start? Czy np. studia są dobrym wyznacznikiem typu: ok teraz już umiem moge szukać pracodawcy? A może najlepszą drogą jest podejmowanie bardzo prostych zleceń? Czy wtedy też dobrze od razu budowaćjakiś zespół?

Może są tu osoby na forum, które chciałby podjąć się działania w takim zespole, żeby nauczyć się czegoś nowego?
A może są i takie które by chciały pomóc jako "mentorzy" takich projektów.

Pozdrawiam Fozen

P.S. przeszukiwałem forum, i nie znalazłem chociażby wzmianki na ten temat, jeżeli ktoś by podał jakieś tematy, które tego dotyczą byłbym bardzo wdzięczny.

Ten post edytował Frozen 10.03.2009, 20:11:23

[Zyx]

Frozen, projektów open-source powstaje na pęczki, ale bardzo mało przetrzymuje próbę czasu. Z własnego doświadczenia powiem Ci, że w Polsce dość ciężko jest coś takiego zorganizować, ponieważ większość osób zdecydowanie bardziej woli brać, niż dawać, a jeśli już dawać, to raczej coś niewielkiego, co nie wymaga miesięcy kodowania - i to kwitnie, np. w postaci blogów. Większy projekt wymaga znacznie większych nakładów pracy, a mało kto jest w stanie porzucić wszystko, szczególnie w sytuacji gdy musi najpierw zarobić na swoje utrzymanie. Nie wiem, czy słyszałeś - pod koniec 2004 roku ruszał z wielką pompą polski projekt "Open Power Board", zebrało się ok. 15 osób, było mnóstwo gadaniny, czy robić tak czy inaczej, ale gdy przyszło co do czego, na początku 2005 roku skład się niemal natychmiast wykruszył - Cysiaczek ma rację i się z nim w pełni zgadzam. W przypadku open-source, gdzie raczej nie można na początku liczyć na kokosy (a często w ogóle nie można na nie liczyć), zaczynanie od zespołu to marsz ku klęsce. Wyjdzie dużo gadania i zero konkretów, może czasem przetrwa jakiś fragmencik, gdy ktoś będzie miał wystarczająco dużo samozaparcia, by go rozwijać.

Na projekt open-source składa się sam projekt, jak i też cała infrastruktura wokół niego. Jeśli któryś z tych elementów potraktujesz po macoszemu, może być ciężko, aczkolwiek dużo zależy też od Twojego samozaparcia. Z odpowiednią determinacją autora, projekt potrafi przetrwać najgorsze kryzysy, bez niej pierwszy lepszy kryzys załatwi nawet nieźle prosperujący projekt. Najlepiej mieć już coś do pokazania, bo bez tego raczej nie zainteresujesz ludzi. Gdy uda Ci się stworzyć coś, co zainteresuje potencjalnego programistę, musisz też mieć infrastrukturę, dzięki której będzie mógł on dowiedzieć się o istnieniu Twojego projektu oraz nauczyć się z niego korzystać. Jeżeli projekt się ludziom spodoba, zjawią się sami i sami z siebie zaczną Ci pomagać w jego rozwoju. Akurat prowadzę od paru lat projekt open-source, będący w długiej linii pochodną śp. OpenPB i powiem Ci, że obsługa zarówno kodu, jak i zaplecza, pochłania dość sporo czasu i wymaga wszechstronnych umiejętności:
- programistycznych
- projektowych
- organizacyjnych
- komunikacyjnych
- obsługi wykorzystywanych narzędzi
- pisarskich (przecież trzeba napisać zrozumiałą dla odbiorcy dokumentację, jakieś tutoriale)
Jest też wiele naprawdę niesamowitych kwestii, jakie trzeba rozważyć, o których mnóstwo osób nie ma zielonego pojęcia, a które mogą zaważyć na dalszych losach całości. Przykładem jest to, w jakim języku robić infrastrukturę - polski czy angielski. Wybierając polski, masz 100% gwarancję, że zagranicy nie zawojujesz, nieliczni Polacy będą zadowoleni, a większość i tak nie będzie z tego wszystkiego korzystać, bo nie jest do czegoś takiego przyzwyczajona (niby skąd, skoro wszystkie bardziej znane projekty robione są po angielsku?). Wybierając angielski, masz 100% gwarancji, że znajdzie się przynajmniej jeden Polak narzekający na lewo i prawo, jaki to on jest poszkodowany, bo musi pisać po angielsku, a on nie zna tego języka, natomiast do reszty będziesz musiał stosować niesamowite zabiegi, by przekonać ich, że naprawdę nic się nie stanie, jeśli zrobią jakiś błąd gramatyczny, pomylą sobie słowa (oczywiście do pewnego stopnia)... na niesamowity opór materii możesz się natknąć nawt próbując ludzi nakłonić do zgłaszania błędów w bugtrackerze zamiast na forum. Kiedyś pisałem o tym na swoim blogu: http://www.zyxist.com/pokaz.php/spolecznosci_programistyczne