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.

Zarejestruj się na sourceforge.net, potem rozejrzyj w "Help wanted" i dołącz do jakiegoś zespołu.
Będziesz miał nauke wszystkiego: kodowania, cvs-a, pracy w zespole, trac-a.

Ewentualnie na innych serwisach, typu code.google.com.

Oczywiście problemem może być znalezienie odpowiedniego projektu. Z jednej strony możesz szukać dopiero raczkującego projektu, w którym mógłbyś uczestniczyć od początku. Ryzyko w takim projekcie jest takie, że projekt może upaść jeszcze zanim powstanie pierwsza wersja. Ponadto, jeżeli nie będzie w nim doświadczonych osób, to nie będziesz mógł liczyć na to, że ktoś Ci wskaże Twoje błędy.

Z kolei bardziej zaawansowany projekt może Cię z początku przerazić złożonością. Ale z drugiej strony w takim projekcie może być bogatsza bugzilla - możesz szukać drobnych błędów do poprawy, lub featurów do zaimplementowania. Przy drobnych rzeczach będziesz miał okazję poznawać architekturę programu.

Ja na Twoim miejscu bym szukał w miarę zaawansowanego projektu, ale pisanego w PHP 5 - czyli nowocześnie, bez zaszłości PHP 4.

A co do Twojego pomysłu - idea jest dobra, ale problem może być z realizacją... Ciężko będzie znaleźć osobę, która mogłaby być mentorem.

Nie zaczynaj od budowy zespołu, tylko od określenia, co chcesz zrobić. Na sourceforge jest masa syfu (przynajmniej była, jak ja tam zaglądałem), więc to nie jest dobry pomysł.
Dobrym pomysłem jest napisanie własnego frameworka - otworzy Ci oczy na problemy związane z przepływem informacji, pomoże zrozumieć wzorce projektowe.
Z doświadczenia wiem, że teoria i praktyka są od siebie daleko. Zazwyczaj w pracy piszesz w jakimś frameworku, który narzuca styl kodowania i dużo rzeczy robi za Ciebie. Praca polega wówczas na dodawaniu akcji, szablonów oraz na refaktoryzacji kodu do poziomu jak najmniejszego burdelu. Nie ma miejsca na finezyjne konstrukcje i piękny kod. Musi działać.
Jednak bez wiedzy i bez znajomości terminologii nie masz szans na zrozumienie dyskusji. Na przykład: "W tej tabeli bez nested sets, robimy drzewko depesza". Wiadomo o co chodzi.

Powinieneś umieć:

- PHP i OOP (technicznie perfect - nie ma miejsca na pytania "co mi daje public/private/protected", czy na pytania w stylu "a co jeśli w obiekcie nie będzie metody 'getLogin()' ?")
- Wzorce projektowe (nawet w samej teorii, zebyś rozumiał zdanie "fabryka zwraca nam menu, po którym możemy iterować. Sprawdzamy, czy węzeł jest liściem. Jeśli tak to... ")
- SVN (na poziomie pozwalającym na update, commit i rozwiązywanie lokalnych konfliktów)
- TRAC
- IDE (eclipse, netbeans, zend studio)

Pozdrawiam

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

Prawie całkowicie się zgadzam z poprzednikami ale chciałem dodać, że nie sprawdza się to w 100%, tylko poprostu często. Są jednak projekty Open Source, które są rozbudowane i rozwijają się w dobrym kierunku, chociażby metasploit, czy tam frameworki, sklepy itd.

Hehe, nie miałem na myśli absolutnie, że każdy projekt OS zmierza ku klęsce . Raczej, że jest to dość trudne/czasochłonne/pracochłonne zadanie i wymaga dużej dawki determinacji, gdyż "nic się samo nie zrobi", a w Polsce dochodzą do tego kolejne przeszkody. W sumie jest to ciekawy temat na artykuł - może niebawem uda mi się trochę czasu wygospodarować na jego napisanie, a w międzyczasie (i nie tylko) zainteresowanym zagadnieniem rozwoju projektów open-source polecam klasykę tematu, czyli słynny esej Erica Raymonda pt. The Cathedral and the Bazaar (pl. Katedra i bazar).

Czyli nici z tego projektu Open Power Board?

Lol, przecież OpenPB już od dłuższego czasu jest anulowany. OPT i reszta to teraz zupełnie inna bajka .

OpenPB umarło, ale zrodziło się z tego dzięki Zyx Open Power Template. Czyli nie była z tego projektu kompletna klapa (OPB) - OPT są na światowym poziomie