Rola OpenSource w branży IT jest nieoceniona. To potężny filar, na którym zbudowane jest komercyjne oprogramowanie. Ogromna ilość produktów bazuje na przygotowanych przez  społeczność developerów modułów, które są dostępne do swobodnego użytkowania i modyfikowania według własnych potrzeb. Społeczność branży IT zazwyczaj czysto altruistycznie udostępnia swoją własność intelektualną, aby przyczynić się do szybszego i sprawniejszego budowania nowych projektów. 

 

OpenSource nie oznacza jedynie oprogramowania wolnego od kosztów licencji. Przede wszystkim pozwala dostosowywać możliwości programu, w celu najlepszego dopasowania do aktualnych potrzeb projektu/klienta. Cały aktualny świat polega na otwartym oprogramowaniu. W tym artykule skupimy się na jego roli w ekosystemie Salesforce.

Połączenia między modułami

Wiele projektów wykazuje zależności między sobą oraz oprogramowaniem Open Source, mimo że na pierwszy rzut oka tego nie widać. Można to w ciekawy sposób zwizualizować, na przykład używając narzędzia do obrazowania zależności między modułami node.js. Na pierwszy rzut oka może się wydawać, że podczas budowania projektu korzystamy tylko z jednego modułu, ale dogłębna analiza zależności pokazuje, jak bardzo połączone i uzależnione od siebie są różne moduły.

(Niby jeden moduł – express.js, a korzysta z 58 innych modułów 🙂)

 

OpenSource w ekosystemie Salesforce

Platforma Salesforce nie jest wyjątkiem i przez 20 lat czerpała (jak zresztą wszyscy) z dobrodziejstw wolnego oprogramowania. Ponadto, SFDC sam przyczynia się do rozwoju społeczności, udostępniając kody źródłowe frameworków używanych do budowy platformy (Aura, LWC). Są one dostępne na platformie GitHub, która jest domyślnym systemem kontroli wersji, używanym do tworzenia i utrzymywania OpenSource. Wynika to głównie z prezentowanego przez nią mocnego nacisku na szeroką społeczność, niekoniecznie profesjonalnie związaną z IT.

 

Przejdźmy jednak do konkretnych przypadków utylizacji platformy Salesforce oraz jej możliwości, pozwalających na ułatwienie pracy oraz ustandaryzowanie jej wśród społeczności developerów i administratorów.

Lightning Design System 

https://github.com/salesforce-ux/design-system

Lightning Design System to publiczny projekt autorstwa Salesforce. Dzięki niemu każdy jest w stanie “zajrzeć pod maskę” i własnoręcznie sprawdzić SLDS. GitHub projektu to także idealne miejsce do zgłaszania bugów znalezionych podczas pracy z frameworkiem lub (jeśli czujesz się na siłach) zostania pełnoprawnym współtwórcą i własnoręcznego rozwiązywania błędów we frameworku.

 

Lightweight Trigger framework 

https://github.com/kevinohara80/sfdc-trigger-framework

Biorąc pod uwagę liczbę ocen tego repozytorium, jest to najpopularniejszy projekt open source zbudowany z użyciem Apexa i hostowany na GitHubie. Lightweight Trigger framework to świetna próba ustandaryzowania metod budowania automatyzacji logiki i zachęcenia do stosowania dobrych praktyk podczas tworzenia triggerów na obiektach. Głównym założeniem tego frameworka jest minimalizm. Zastosowano w nim minimalny zestaw klas i metod, które w odróżnieniu od kompleksowych patternów na pewno przydadzą się w każdym orgu.

 

Unofficial SF Flow Components 

https://github.com/alexed1/LightningFlowComponents

Jeden z moich ulubionych projektów. Unofficial SF Flow Components to ogromna biblioteka gotowych komponentów o bardzo intuicyjnych nazwach i przeróżnych zastosowaniach — głównie do wykorzystania podczas budowania Flow. Przykładowo, GetRandomNumber to metoda wywoływana przez flow i zwracająca losowy numer. Gdyby nie ta biblioteka, na spełnienie wyżej wspomnianego wymagania we Flow trzeba by było poświęcić czas równy wypiciu małej kawy. Jestem przekonany, że każdy znajdzie tu rozwiązanie, które zaoszczędzi mu chociaż chwilę klikania. Warto nadmienić, że jest to projekt grupy https://unofficialsf.com/, która ma na koncie już kilka podobnych narzędzi.

Współtworzenie projektów Open Source

Współtworzenie projektów Open Source jest świetnym sposobem na zebranie pierwszego doświadczenia z ekosystemem Salesforce, pracą w grupie i narzędziami wykorzystywanymi do developmentu.

Każdy z wyżej wymienionych projektów zachęca do udzielania się, aby społeczność mogła jeszcze bardziej korzystać z oferowanych rozwiązań. Pracę nad projektami można zacząć od zgłaszania bugów wyłapanych podczas używania biblioteki, co jest istotnym wkładem w jej rozwój. Ponadto, możesz skupić się na naprawie błędów i tworzeniu nowych funkcji biblioteki, co zapewni jeszcze więcej korzyści dla społeczności. 

Gdzie szukać informacji na temat stanu projektu?

Większość projektów ma na swojej stronie startowej w GitHub informacje jaki jest aktualny stan projektu, kierunek rozwoju na najbliższą przyszłość oraz w jaki sposób możesz dołożyć swoją cegiełkę w rozwój biblioteki. Jeśli zaczynasz swoją przygodę z Salesforce to ten “staż” jest naprawdę rozwijający, pozwala uchwycić szerszy obraz ekosystemu i poznać bolączki, które zmusiły użytkowników do stworzenia oprogramowania rozwiązującego ten problem dla całej społeczności. 

 

Informacji na temat aktualnej pracy można szukać w repozytorium projektu, w plikach wdrażających README i CONTRIBUTIONS, a także bezpośrednio w zakładce Issues, gdzie często można spotkać porcję świeżych ticketów do zamknięcia.

 

Tak osoby utrzymujące projekt zachęcają do rozwoju biblioteki
https://github.com/alexed1/LightningFlowComponents