Dwie dekady Open Source – 90% otwartości w nowo powstałych aplikacjach

Jak zdobyć doświadczenie w IT, nie mając doświadczenia

Ogłoszenia o pracę w branży IT mogą wydawać się bardzo dziwne. Czasami wręcz niezrozumiałe. Obok licznych nazw technologii, z których wiele może nam nic nie mówić, często pojawia się też wymaganie posiadania kilku lat doświadczenia. Czymże jednak jest to doświadczenie? Czy odnosi się ono do tego, ile lat korzystamy z danej technologii? A może do tego, ile lat używamy danej technologii komercyjnie? No i wreszcie, czy chodzi o każdą z wymienionych technologii czy tylko o dowolną wybraną z nich?

W tym artykule spróbuję przybliżyć nieco, jak należy rozumieć “doświadczenie” w kontekście ogłoszeń o pracę w branży IT. Mimo iż wielu pracodawców wymaga takiego doświadczenia, nie znaczy to, że nie dostaniemy żadnej pracy w branży, jeśli wcześniej nie pracowaliśmy w branży. Technologia informacyjna nie lubi problemów nieskończenie rekurencyjnych, możemy więc założyć, że istnieje prostsze rozwiązanie.

Prawdę powiedziawszy, doświadczenie w pracy w branży nie odnosi się zwykle tylko do umiejętności technicznych. Technologia zmienia się na tyle szybko, że wielu z popularnych dzisiaj rozwiązań nie było na świecie 5 lat temu, więc szukanie ekspertów z “5-letnim doświadczeniem z technologią X” byłoby niewykonalne (co nie znaczy, że nie trafiają się takie ogłoszenia). By lepiej zrozumieć stawiane przed nami wymagania, przyjrzyjmy się, jak wygląda i na czym polega praca programisty.

Dzień z życia programisty

Wydawać by się mogło, że podstawą pracy programisty jest tworzenie kodu. To założenie jest częściowo słuszne. Lepszym byłoby jednak stwierdzenie, że programiści rozwiązują problemy, tworzą opisy tych rozwiązań (algorytmy), a następnie zapisują je jako kod zrozumiały dla maszyny. Dlaczego to rozróżnienie jest ważne? Sama umiejętność pisania kodu, czyli znajomość jednego lub więcej języków programowania, nie oznacza że potrafimy samodzielnie rozwiązywać problemy. Podobnie jak znajomość liter nie czyni z nas jeszcze poetów.

Żeby rozwiązywać problemy, programista musi najpierw je poznać. Skąd się biorą problemy i jak możemy je poznać? Zwykle problemy pochodzą od klienta. Klientem może być firma zewnętrzna, nasz szef, koleżanki i koledzy, a czasami klientem możemy być my sami. Rozważmy przykład napisania programu, który wyświetla wszystkie transakcje na naszej karcie kredytowej z danego dnia. Ten program prezentuje kilka problemów. Musimy ściągnąć listę transakcji z naszego banku. By tego dokonać, musimy się najpierw uwierzytelnić. Po ściągnięciu listy musimy rozdzielić odpowiednie rekordy (jak opis, kwota i data), a następnie posegregować je według daty. Gdy tego dokonamy musimy wybrać tylko te rekordy, które odpowiadają interesującemu nas dniu, a następnie zaprezentować je użytkownikowi.

Każdy z powyższych problemów może składać się z mniejszych. Wspólnie tworzą one zbiór zadań do wykonania. Te zadania przechowywane są w odpowiednim systemie zarządzania zadaniami. Opiekun projektu w konsultacji z zespołem projektowym przygotowuje zbiór zadań, a następnie są one rozdzielane między programistów. Zanim przystąpimy do pisania kodu, musimy więc najpierw nauczyć się korzystać z systemu zarządzania zadaniami, a także wziąć udział w planowaniu zadań (przy czym to ostatnie nie zawsze ma miejsce).

Chociaż mogłoby się wydawać, że naszym jednym partnerem będzie maszyna, okazuje się, że wchodzimy w interakcje także z innymi członkami zespołu projektowego. Praca programisty to zwykle praca zespołowa. Stworzenie odpowiedniego kawałka kodu nie jest oczywiście końcem pracy. Wręcz przeciwnie, kod który działa na naszym komputerze, to tylko początek dłuższego procesu wydawniczego. Musimy najpierw przetestować, czy stworzony przez nas kod rzeczywiście spełnia wymagania opisane w zadaniu.

Następnie musimy upewnić się, że nie zepsuliśmy istniejących wcześniej funkcji. Jeśli oba warunki zostały spełnione, możemy podzielić się naszym kodem z innymi. W tym celu sprawdzamy czy kod działa także bez problemu na innych maszynach. Różnice w konfiguracji pomiędzy dwoma komputerami bardzo często są przyczyną problemów. Naszym obowiązkiem jest udowodnić, że program wykonuje się poprawnie nie tylko u nas, ale przede wszystkim tam, gdzie docelowo będzie uruchamiany (np. na serwerze lub na komputerze klienta).

Gdy nasz kod trafi wreszcie do wspólnej puli, pozostaje tylko przeprowadzić wydanie i potencjalnie wdrożenie. Kolejny krok, czyli demonstracja wykonanej pracy przed klientem, nie jest powszechną praktyką, ale również warto o nim pamiętać. Jeśli w tym momencie czujesz już nadmierne obciążenie obowiązkami, mam dobrą wiadomość. Wiele z tych kroków jest w pełni bądź częściowo zautomatyzowanych i potrafi zajmować łącznie mniej niż godzinę. Warto dodać, że kod tworzony przez programistów pracujących w firmie nie jest własnością ani zespołu projektowego, ani pojedynczych programistów. Stanowi własność firmy i w związku z tym powinien spełniać pewne określone standardy. Ich celem jest zapewnienie, by każdy pracownik, niekoniecznie związany z danym projektem, był w stanie zrozumieć co robi dany projekt oraz dokonać w nim zmian. Do tego celu tworzy się zarówno dokumentację techniczną, jak i reguły dotyczące np. sposobów formatowania kodu, nazewnictwa funkcji i zmiennych, czy sposobów komunikacji w zespole.

Doświadczenie w rozwiązywaniu problemów

Teraz, gdy widzimy szerszy obraz pracy programisty, lepiej możemy zrozumieć, czym może być wspomniane na początku doświadczenie. Może więc ono zawierać:

doświadczenie w korzystaniu z technologii w rzeczywistych projektach,

doświadczenie w korzystaniu z systemów zarządzania zadaniami,

doświadczenie w pracy zespołowej,

umiejętność rozwiązywania problemów,

dobre zarządzanię własnym czasem,

zrozumiała komunikacja i okazanie empatii klientowi i reszcie zespołu,

umiejętność czytania i pisania dokumentacji technicznej,

stosowanie się do obowiązujących reguł.

Wiele z tych umiejętności nie jest cechą wyjątkową branży IT, dlatego można ją zdobyć także w innych dziedzinach. Jak jednak nauczyć się tych, które nie występują nigdzie indziej? Poniżej przedstawię kilka przykładów, które mogą pomóc zaznajomić się z branżą i zdobyć odpowiednie doświadczenie.

Praktyki i staże

Jedna z popularniejszych metod zdobywania doświadczenia to wzięcie udziału w praktykach lub stażach. Wiele firm oferuje taką formę zatrudnienia. Informacji o dostępności praktyk zwykle możemy szukać na uczelniach technicznych, natomiast w przypadku staży – w Urzędach Pracy, na stronach organizacji pozarządowych zajmujących się promocją i wsparciem w zatrudnianiu młodych ludzi, a także na portalach z ogłoszeniami o pracę, niektóre firmy bowiem organizują taką formę kształcenia przyszłych pracowników na własną rękę.

Zarówno staże, jak i praktyki, służą ułatwieniu zdobycia pierwszego doświadczenia w branży. Są między nimi jednak pewne różnice. Praktyki skierowane są głównie do studentów i mogą być płatne lub bezpłatne. Czas trwania praktyk, jak i zakres obowiązków, nie są odgórnie ustalone. Staże zazwyczaj kierowane są do osób, które formalną edukację mają już za sobą i szukają miejsca, w którym mogą zrobić pierwszy krok na (często nowej) ścieżce kariery i nie mają limitów wiekowych. Te współfinansowane przez Urzędy Pracy wyróżniają się tym, że po zakończeniu okresu nauki, stażysta musi zostać zatrudniony na minimum trzy miesiące. W przypadku innych organizatorów nie ma już takich zasad, niemniej jednak często po to właśnie firmy je organizują, by zatrudnić dobrze rokującego młodego (stażem, nie wiekiem) pracownika.

Z wynagrodzeniem na stażu bywa różnie, przeważnie jest to raczej symboliczna kwota, ale pamiętajmy, że tak właściwie ktoś nam płaci za to, żebyśmy się uczyli (a więc generowali dodatkowe koszty). Podczas poszukiwania praktyk bądź staży, które pozwolą nam zdobyć doświadczenie, warto jest szukać firm, które pozwolą nam pracować w zespole. Jak wyjaśniłem we wstępie, to właśnie umiejętność współpracy, komunikacji i używania narzędzi wspierających komunikację jest tym, czego nie nauczymy się czytając książki, artykuły, bądź oglądając kursy wideo. Pomimo tego, że praca w zespole jest ważna, nie możemy jednak zapominać o wątku technicznym. Dobór praktyk czy stażu powinien nam umożliwić również rozwój i naukę w wybranych technologiach, w których chcielibyśmy się specjalizować lub które chcielibyśmy poznać.

Projekty i społeczność Open Source

Temat udzielania się w projektach i społeczności Open Source jest tematem bardzo szerokim. Można mu spokojnie poświęcić osobny artykuł. Taka działalność bowiem może nam pomóc na każdym etapie kariery, nie tylko na początku, gdy chcemy dopiero poznać branżę.

W tym artykule skupimy się tylko na jednym z aspektów, mianowicie jak Open Source może nam pomóc zdobyć doświadczenie w interesujących nas technologiach, w pracy zespołowej oraz w użyciu narzędzi wspierających taką pracę. Zanim do tego dojdziemy, wyjaśnijmy sobie najpierw, czym jest Open Source. Mimo iż wiele osób mogło słyszeć ten termin, nie każdy zdaje sobie sprawę z jego pełnego znaczenia. W wolnym tłumaczeniu “Open Source” znaczy tyle co “Otwarte Źródło”. Otwarte, czyli dostępne dla każdego (do czytania lub modyfikacji). Źródło zaś odnosi się do kodu źródłowego, czyli instrukcji zapisanych w określonym języku programowania.

Kod źródłowy zwykle kompilowany jest do kodu maszynowego i w takiej formie dystrybuowany. Dlatego nie jesteśmy w stanie zmieniać zachowania wielu programów, z których korzystamy na co dzień. Mamy dostęp do kodu maszynowego, a nie do łatwego w modyfikacji kodu źródłowego. Mimo iż wiele programów funkcjonuje wyłącznie w formie zamkniętej, jest też mnóstwo popularnych projektów które tworzone są przez społeczność. Społeczność, ponieważ w projektach Open Source każdy z nas może być współautorem.

Do popularnych programów Open Source należą system operacyjny Android, przeglądarka internetowa Mozilla Firefox, odtwarzacz multimediów VLC, czy edytor graficzny GIMP. Na udzielanie się w projektach Open Source możemy patrzeć jak na wolontariat. Pomimo iż istnieje wiele sposobów zarabiania na Open Source (jako dodatkowy dochód lub jako jego główne źródło), większość osób nie traktuje takiej pracy jako zarobkowej. Motywacją jest zwykle możliwość rozwoju lub stworzenia czegoś korzystnego dla większego grona odbiorców.

Udzielanie się w społeczności Open Source jest korzystne nawet wtedy, gdy dopiero uczymy się umiejętności technicznych, takich jak testowanie, czy programowanie w określonym języku. Projekty często potrzebują także wsparcia w innych dziedzinach, jak pisanie dokumentacji, tłumaczenia, przygotowywanie grafik czy marketing. Krótko mówiąc, jeszcze zanim zaczniemy zdobywać umiejętności z branży IT, możemy wykorzystać swoje obecne zdolności, by wspomóc projekty Open Source. Takie projekty w dużej mierze funkcjonują jak analogiczne projekty komercyjne. Praca odbywa się w zespołach projektowych, opiekunowie projektu wraz z innymi członkami zespołu przygotowują zadania oraz korzystają z podobnych narzędzi co komercyjne firmy.

Co więcej, ponieważ projekty Open Source tworzone są w sposób otwarty i publiczny, mają do nich wgląd także rekruterzy. Coraz powszechniejszym zjawiskiem jest otrzymywanie ofert pracy tylko i wyłącznie w oparciu o nasze osiągnięcia w pracy z Open Source. W odróżnieniu od CV czy profilu LinkedIn, które możemy mocno koloryzować, nasz wkład widoczny publicznie na platformach takich, jak GitHub, GitLab, czy BitBucket pokazuje nasze praktyczne umiejętności. Nic dziwnego w tym, że mnóstwo programistów starannie pielęgnuje portfolio, zapełniając je projektami Open Source. Dzięki temu rozwijają się osobiście, a ponadto mogą przedstawiać swoje osiągnięcia potencjalnym pracodawcom.

Udział w warsztatach i hackathonach

Ostatnim sposobem zdobywania doświadczenia, jakiemu się przyjrzymy, jest udział w warsztatach i hackathonach. Warsztaty to nic innego jak zorganizowane spotkania, zwykle trwające kilka godzin, których celem jest stworzenie działającego produktu, wykorzystując praktyczną wiedzę. Warsztaty zwykle są prowadzone przez doświadczoną osobę, mają określony temat, a często także określony przebieg.

Czymże jednak są hackathony? To określenie powstało jako zbitka wyrazowa “hacking” i “marathon”. Oznacza więc ono hackowanie bez przerwy przez dłuższy czas. Zwyczajowo hackathony trwają od kilku godzin do kilku dni (z przerwami lub w ekstremalnych odmianach bez przerw). Jeśli w głowie pojawiają nam się teraz podejrzanie wyglądający ludzie próbujący włamać się do czyjejś skrzynki pocztowej i wykraść dane, trzeba wyjaśnić jeszcze jedną rzecz. W żargonie używanym przez programistów “hackowanie” oznacza po prostu rozwiązywanie ciekawych problemów, zwykle w sposób kreatywny, a często również zaskakujący. Bardziej ogólnie można tym mianem określić także dowolne działania programistyczne, niezwiązane bezpośrednio z pracą zarobkową. Stąd często spotyka się określenie “hackerzy Open Source” (czyli osoby udzielające się w projektach hobbistycznie).

W przeciwieństwie do warsztatów, które posiadają strukturę i prowadzącego, hackathony zwykle pozbawione są konkretnego planu. Mają określony temat przewodni, jednak dobór zespołów, wybór technologii, czy określenie zakresu projektu pasującego do tematu, zależą już tylko i wyłącznie od wyobraźni uczestników. Zarówno warsztaty, jak i hackathony, są nie tylko świetnym sposobem do nauki i zdobywania doświadczenia. Ponieważ w obu przypadkach wytwarzamy funkcjonujący produkt, możemy go następnie wykorzystać do rozszerzenia naszego portfolio.

W tym miejscu dwa tematy niejako łączą się, gdyż efekt naszych warsztatów lub hackathonu staje się jednocześnie naszym wkładem w społeczność Open Source w momencie, gdy publikujemy jego źródła. Warsztaty i hackathony pozwalają nam rozwinąć zdolności zarówno techniczne, jak i interpersonalne. Są więc dobrą podstawą do budowy doświadczenia. W odróżnieniu jednak od poprzednich sposobów, brakuje im możliwości obserwowania długoterminowej dynamiki pracy w zespole. Po kilku godzinach (lub dniach) zespoły rozchodzą się i najprawdopodobniej nie będą już w najbliższym czasie pracowały w zbliżonym składzie. W życiu zawodowym natomiast rzadko kiedy po wydaniu jednej wersji produktu zabieramy się za kolejne wyzwania. Warto więc traktować je jako wartościowy dodatek, ale nie jedyne źródło zdobywania doświadczenia.

Zakończenie

Jak widać, praca w branży IT to znacznie więcej niż tylko rytmiczne uderzanie w klawiaturę. Mnogość procesów, narzędzi czy rytuałów może wydawać się onieśmielająca. W rzeczywistości są one znacznie mniej straszne. Prawdą jest natomiast, że wymagają oswojenia i częstej praktyki. Jeśli zależy nam na znalezieniu pierwszej pracy jako programista, warto już wcześniej zacząć zdobywać doświadczenie i z bliska poznawać branżę. Najlepiej, jeśli temu poznawaniu towarzyszy także budowanie portfolio rzeczywistych projektów.

Aplikacje natywne Kotlin - mobitouch

Kotlin to statycznie typowany język programowania ogólnego przeznaczenia na licencji open-source, który stawia na wieloplatformowość. Idealnie nadaje się do tworzenia natywnych aplikacji Androida – mobilnych, webowych i desktopowych, pozwalając deweloperom na używanie reguł programowania funkcyjnego oraz programowania obiektowego. To jeden z najnowszych, bo rozwijany od 2011 roku język, za rozwojem którego stoi JetBrains, rozpoznawalna w branży firma programistyczna i społeczność open-source. Nazwa języka została zainspirowana wyspą leżącą w pobliżu St. Petersburga.

Kotlin, określony przez Google jako preferowany język do tworzenia aplikacji na Androida, szybko zyskał szerokie grono fanów wśród deweloperów. Ci wśród jego zalet wymieniają możliwość tworzenia czytelnego i łatwego w użyciu kodu oraz jego wydajność. Nie bez znacznie jest też pełna kompatybilność ze wszystkimi frameworkami opartymi o Javę – aplikacje napisane w tym języku można swobodnie przenosić na Kotlin zachowując działanie napisanego kodu.

Dwie dekady Open Source – 90% otwartości w nowo powstałych aplikacjach

W lutym tego roku obchodziliśmy 20-lecie powstania ruchu Open Source. Jak przez ten czas wolne oprogramowanie wpłynęło na kształtujący się rynek IT? Ile Open Source'a jest w nowo powstających aplikacjach? Odpowiedzi na te i wiele innych pytań przygotowaliśmy w tym raporcie.

Wolne oprogramowanie istnieje od momentu, w którym powstały pierwsze komputery. Programiści od samego początku dzielili się bowiem kodem źródłowym tworzonych przez siebie programów. Jednak oficjalna nazwa Open Source narodziła się właśnie 20 lat temu, w 1998 roku, kiedy firma Netscape, współpracująca z Ericem Raymondem, udostępniła publicznie kod źródłowy stworzonej przez siebie przeglądarki internetowej – Netscape Navigator (zwanej także Netscape Communicator). Wydarzenie to było impulsem do zorganizowania spotkania The Open Source Initiative (OSI), które uważa się za symboliczne narodziny ruchu Open Source. Spotkanie to zapoczątkowało także istnienie amerykańskiej organizacji pożytku publicznego – Open Source Initiative – założonej przez Erica Raymonda oraz Bruce'a Perensa w celu promocji Otwartego Oprogramowania. Organizacja przyczyniła się do publikacji Definicji otwartego źródła (ang. Open Source Definition). Jest ona powszechnie używana w celu określenia, czy licencję danego programu można uznać za Open Source. Podstawą jej utworzenia były Wytyczne Debiana dotyczące Wolnego Oprogramowania zaadaptowane przez współtwórcę OSI, Bruce'a Perensa.

90% Open Source w aplikacjach

Obecnie Open Source wiedzie prym na rynku technologicznym i wyznacza kierunek jego rozwoju. Doskonale obrazuje to analiza przeprowadzona przez firmę analityczną Forrester The Forrester Wave™: Software Composition Analysis. Według specjalistów nowo powstałe aplikacje zawierają od 80% do nawet 90% kodu pochodzącego z otwartych źródeł. Zatem tylko 10%, a maksymalnie 20% to nowy kod napisany przez deweloperów. Dostępne publicznie komponenty oparte o otwarty kod źródłowy znacznie przyspieszają i usprawniają proces tworzenia aplikacji, jak i co równie ważne zmniejszają koszy ich produkcji. Dzięki temu w łatwy sposób można zaspokoić popyt na aplikacje wewnątrz organizacji, jak i potrzeby zewnętrznych klientów.

Jedną z zalet Open Source wskazywaną w badaniach Forrestera jest możliwość dzielenia się wiedzą. Udział w projektach pozwala bowiem na szybkie i efektywne podnoszenie swoich kompetencji i ułatwia zdobywanie nowych umiejętności. Co więcej, każdy programista wystawia w rzeczywisty sposób rezultaty swojej pracy do rzetelnej oceny innych specjalistów. Nad rozwiązaniami opartymi o otwarty kod źródłowy pracują przecież miliony osób na całym świecie. Ich celem jest m. in. weryfikacja poprawności i jakości kodu oraz projektowanie nowych funkcjonalności usprawniających pracę.

Popularność rozwiązań opartych o technologie Open Source pokazuje, że można z powodzeniem działać w branży technologicznej, udostępniając jednocześnie swoje know-how w postaci kodu źródłowego oprogramowania. Dwie dekady temu rynek nie widział w takim podejściu biznesowego uzasadnienia. Dziś z Open Source codziennie korzystają choćby miliony użytkowników smartfonów. Otwarty kod jest silnie obecny także w oprogramowaniu dla biznesu. Wiele firm posiadających własne centra danych, korzysta właśnie z otwartych systemów operacyjnych. Z kolei, jeśli przyjrzymy się najistotniejszym kierunkom rozwoju IT, okaże się, że również one są zdominowane przez otwarte technologie. Wystarczy wymienić rynek konteneryzacji, data science czy uczenia maszynowego. Open Source należy więc postrzegać jako źródło innowacji w sektorze technologicznym – twierdzi Dariusz Świąder, Prezes Zarządu Linux Polska.

90% firm korzysta z rozwiązań Open Source

Z badań Open Source 360 Survey przeprowadzonych przez amerykańską firmę Black Duck na próbie 900 respondentów wynika, że 90% przedsiębiorstw korzysta z otwartoźródłowych rozwiązań. Co więcej, 60% organizacji deklaruje, że w ciągu ostatnich 12 miesięcy zwiększyło skalę użycia produktów Open Source. 63% ankietowanych jest zdania, że korzystanie z otwartych komponentów przyspiesza wdrażanie innowacyjnych technologii, a 61% twierdzi, że poprawiają one jakość powstających nowych rozwiązań.

Statystyki podobnie prezentują się w Polsce. Z badania przeprowadzonego na zlecenie Linux Polska wynika, że 90% firm działających w polskim sektorze technologicznym wykorzystuje systemy operacyjne o otwartym kodzie źródłowym. Natomiast aż 97% badanych przyznało, że tworząc własne rozwiązania IT i aplikacje, korzysta częściowo lub wyłącznie z otwartych technologii – dodaje Dariusz Świąder. Drugie miejsce na podium należy do otwartych baz danych. Ich użytkowanie zadeklarowało 73,5% ankietowanych. Na trzecim miejscu narzędzia do automatyzacji z wynikiem 44,6%. W polskim badaniu głównymi zaletami Open Source wskazywanymi przez 6 na 10 respondentów była elastyczność rozwiązań oraz optymalizacja kosztów.

Open Source królem

Jak widać, Open Source króluje w branży technologicznej, a to jeszcze nie koniec. Rozwój otwartoźródłowych rozwiązań przyspiesza wraz ze wzrostem potrzeb i świadomości przedsiębiorstw dostrzegających ich ogromne korzyści. Nawet firmy kojarzone dotąd wyłącznie z zamkniętym oprogramowaniem otwierają się na otwarte technologie. Doskonałym przykładem jest firma Microsoft, która jeszcze zaledwie kilka lat temu widziała zagrożenie w Open Source, a dziś jest ważnym kontrybutorem produktów opartych o otwarty kod.

Źródła: