Softurile open (mai ales care nu au versiuni supported) evoluează într-un mod dubios. Cineva s-a apucat să scrie OpenSSL, alții l-au luat de bun, l-au integrat cum s-a putut, pe urmă s-au mai adăugat features, s-au făcut patch-uri etc. Dacă în proiect nu ai un dictator gen Linus (care să stea să integreze/verifice/rejecteze prostii/stea să se certe cu lumea), reguli stricte de coding/integrare/API design sau o corporație care să contribuie masiv (și care să aibă reguli clare și să impună un ritm, vezi Eclipse+IBM) ce iese e o varză petecită de cine apucă în timpul liber (sună bine să programezi la 3 dimineața, pare că și dă rezultate, dar nu-s neapărat rezultatele dorite). Iar contribuitorii la open source sunt de obicei atrași din două motive: ori au nevoie de ceva special, ori îi interesează un algoritm/problemă. În ambele cazuri o dezvoltă pentru ei (așa cum le trebuie lor sau cum sunt obișnuiți) și pe urmă o publică, fără să se chinuie cu lucrurile plictisitoare (documentație, teste, integrare cu restul componentelor, curățarea codului de tâmpenii). Dacă n-ai pe cineva cu mild OCD în proiect, care să stea toată ziua să facă curat dar să și înțeleagă codul, cam asta se întâmplă. După care dai de unu' cu personalitate, care ține cu dinții de codul lui și de fiecare dată când cineva îi modifică partea implementată de el, vine și o reface înapoi așa cum a făcut-o el. Urmează certurile clasice de forum, de tipul "îmi iau jucăriile și plec", adică "îmi fac branch-ul meu, să fiu eu șeful".
Partea nasoală e că e foarte complicat să aduci un astfel de soft pe "calea cea bună". Pentru că a fost integrat de foarte multă lume în diferite proiecte, și ei se așteaptă să meargă în continuare așa cum a mers până acum. În teorie ce se face e dezvoltarea unui wrapper care să păstreze API-ul curent așa cum e (astfel încât nu bușești softurile care o folosesc), după care te apuci să aduci codul din spate la ceva frumos și pufos. Însă dezvoltarea unui wrapper de genul ăsta e grea (trebuie să ai o imagine foarte clară a softului și a interacțiunilor dintre componente), se ajunge la un fel de emulator al bibliotecii - iar în multe cazuri trebuie să emulezi inclusiv known bugs. După ce termini versiunea nouă, cu un API perfect gândit, excelent implementat, te trezești că lumea n-are chef să își schimbe codul care folosește API-ul vechi, așa că trebuie de fapt să întreții atât versiunea nouă cât și wrapper-ul pentru versiunea veche. Legat de asta vezi istoria Python: versiunea 3 a fost scoasă în 2008, dar lumea n-are chef de ea, pentru că ar trebui modificate câteva apeluri de funcții în cod (și pentru care există tool-uri automate de portare), așa că încă se folosește intens Python 2.7 (ultima versiune 2.x, scoasă în 2010 și în extended support acum), pentru care există ofertă mai vastă de biblioteci.
Am folosit multe softuri/biblioteci open source în care hălci din funcționalitățile expuse nu erau implementate deloc, fără să scrie undeva asta. Ex: bibliotecă pentru deschis/rulat Excel (POI de la Apache foundation, foarte folosită de altfel) în care cam 2/3 din funcțiile Excel-ului nu erau implementate - dar nu dădea eroare sau warning sau ceva atunci când rulai un Excel cu acele funcții neimplementate, ci pur și simplu rezultatul funcției era vid sau întorcea valoarea nemodificată a parametrului. Aflai de problemă doar când te uitai în surse și vedeai "todo"-urile. N-ai cu cine să discuți, dacă-ți trebuie funcțiile, te apuci să le implementezi (și, pentru că nu era planificată problema asta, o faci repede și "pentru tine", adică funcțiile care-ți trebuie), și publici modificările sau mai degrabă nu (în unele proiecte e destul de dubios modul de înregistrare ca și contribuitor, noroc cu github care a făcut ceva mai ușoară colaborarea).