Każdy zespół infrastrukturalny korzystający z open source prędzej czy później staje przed tym samym wyborem. Gdy coś się psuje albo brakuje funkcji, można to załatać lokalnie i iść dalej — albo naprawić upstream.
Lokalne łatki wydają się szybsze. Nie są. Każdą trzeba utrzymywać, rebase’ować i testować przy każdym wydaniu, aż aktualizacja staje się osobnym projektem, a wdrożenie po cichu zamienia się w fork, którego nikt nie chce utrzymywać.
Nie utrzymujemy prywatnych forków dla naszych klientów. Naprawiamy rzeczy tam, gdzie powinny być naprawione.
Co to oznacza w praktyce
Poprawki domyślnie trafiają upstream. Gdy znajdujemy błąd, zgłaszamy go, piszemy poprawkę i przeprowadzamy ją przez review w projekcie upstream. Jeśli potrzebujesz poprawki przed kolejnym wydaniem, utrzymujemy ją tymczasowo — zawsze z linkiem do zmiany upstream i tylko do czasu jej scalenia.
Nowe funkcje projektujemy ze społecznością. Jeśli potrzebujesz czegoś nowego, pracujemy z projektem nad rozwiązaniem, które zostanie przyjęte i będzie utrzymywane, zamiast doklejać je z zewnątrz.
Korzystamy z narzędzi społeczności. Wdrożenia, zarządzanie cyklem życia i CI opieramy na tych samych otwartych narzędziach, których używają i które testują same projekty. Żadnej zamkniętej warstwy między tobą a oprogramowaniem.
Oddajemy czas, nie tylko kod. Code review, utrzymanie CI, dokumentacja i praca przy wydaniach utrzymują open source w dobrej kondycji. Poświęcamy czas na to wszystko, bo projekty, na których polegają nasi klienci, tego potrzebują.
Dlaczego to dobre dla ciebie
- Aktualizacje pozostają rutyną. Brak stosu łatek do rebase’owania oznacza, że nowe wydanie to aktualizacja, a nie migracja.
- Twoje poprawki utrzymuje społeczność. Po scaleniu poprawka jest testowana przy każdej zmianie, przez wszystkich.
- Nigdy nie jesteś uzależniony. Wszystko, co budujemy, działa na oprogramowaniu upstream, w twoich repozytoriach. Możesz to utrzymywać bez nas.
- Masz wpływ. Praca upstream daje ci głos w tym, dokąd zmierzają projekty, na których polegasz.