Il problema che nessuno risolveva #
Vi racconto una cosa. Usavo Twenty CRM da un po’ — per chi non lo conosce, è un CRM open source bellissimo, moderno, con una community attiva. Funziona benissimo da browser. Ma io sono un mobile developer. E il mio lavoro lo faccio in giro: tra un meeting e l’altro, in aeroporto, dal cliente. E ogni volta che dovevo controllare un contatto o aggiornare una nota, dovevo aprire il browser, fare login, aspettare il caricamento… e se ero in metropolitana con mezzo tacchetto di segnale, buona fortuna.
Cercavo un’app mobile nativa per Twenty CRM. Non esisteva. Cercavo alternative. Niente di decente. A quel punto mi sono detto: mi sà che me la devo fare da solo.
Da progetto personale a open source #
Le prime settimane di sviluppo le ho passate in modalità classica: codice chiuso, repository privato, nessuno vede niente finchè non è pronto. Il tipico approccio dello sviluppatore che ha paura che qualcuno veda il suo codice spaghetti.
Ma poi è successo qualcosa. Stavo usando Twenty CRM, che è open source. Stavo usando Flutter, che è open source. Stavo usando Riverpod, GraphQL Flutter, Freezed… tutto open source. Il mio progetto viveva letteralmente sulle spalle di decine di sviluppatori che avevano deciso di condividere il loro lavoro gratuitamente.
E io cosa facevo? Tenevo il mio codice chiuso. Mi è sembrata un’ipocrisia.
La scelta della licenza: GPL-3.0 #
Quando ho deciso di rendere il progetto open source, la prima domanda è stata: quale licenza? Ho valutato le opzioni:
- MIT — Troppo permissiva per i miei gusti. Qualcuno potrebbe prendere il codice, chiuderlo, e venderlo come suo. No grazie.
- Apache 2.0 — Simile a MIT ma con protezione brevetti. Meglio, ma ancora troppo permissiva.
- GPL-3.0 — Copyleft forte. Se qualcuno modifica il codice e lo distribuisce, deve rilasciare le modifiche con la stessa licenza. Questo è quello che volevo.
La GPL-3.0 protegge il progetto in modo che rimanga sempre open source. Se qualcuno vuole contribuire, perfetto. Se qualcuno vuole forkare e migliorare, perfetto. Ma non può prendere il mio lavoro e chiuderlo. Mi sembra equo.
Cosa significa in pratica per TwentyMobile #
TwentyMobile è un client mobile per Twenty CRM costruito con Flutter. Quello che fa è semplice da spiegare ma non banale da implementare:
- Gestione contatti e aziende con ricerca veloce, dettagli completi, e aggiornamenti ottimistici
- Note e note vocali per catturare informazioni al volo
- Task con notifiche per non dimenticare mai un follow-up
- Scanner biglietti da visita con OCR integrato
- Workflow manuali per eseguire automazioni direttamente dal telefono
Il tutto si collega alla vostra istanza self-hosted di Twenty CRM. Zero dati raccolti, zero cloud proprietario, tutto viaggia direttamente tra il vostro telefono e il vostro server.
Le paure di rendere il codice pubblico #
Ve lo dico onestamente: prima di premere quel pulsante “Make public” su GitHub, ho avuto un momento di panico. I pensieri tipici:
“Il codice non è perfetto” — E quando mai lo è? Ho rilasciato con delle cose che mi fanno ancora storcere il naso. Il TwentyConnector è un file da 52KB. Cinquantaduemila byte di codice GraphQL in un singolo file. Lo so, è troppo grosso. Ma funziona. E il refactoring arriverà. Nel frattempo, il mondo può vedere come ho risolto certi problemi, e magari qualcuno trova un modo migliore.
“Qualcuno copierà tutto” — Con la GPL-3.0, può copiare. Ma deve mantenere la licenza e rilasciare le modifiche. E sinceramente, se qualcuno prende il mio codice e lo migliora, tanto meglio per tutti.
“Chi contribuirà mai?” — Questa è stata la sorpresa più grande. Dall’integrazione con agenti AI come Jules, ho già ricevuto PR automatiche per fix di sicurezza, ottimizzazioni di performance, e pulizia del codice. Non è la community tradizionale fatta di persone, ma è una community che funziona.
L’effetto collaterale che non mi aspettavo #
Rendere il progetto open source mi ha costretto a scrivere codice migliore. Non perchè qualcuno lo stesse effettivamente leggendo — almeno non subito — ma perchè sapevo che qualcuno poteva leggerlo.
Ho iniziato a commentare di più. A strutturare meglio i commit. A scrivere un README decente. A documentare l’architettura. Robe che avrei dovuto fare comunque, ma che la pigrizia dello sviluppatore solitario tende a far saltare.
E poi c’è il vantaggio del portfolio. Quando qualcuno mi chiede “ma tu cosa sai fare?”, gli mando il link a GitHub. Parlano i fatti, non il curriculum.
Consigli per chi ci sta pensando #
Se avete un progetto personale e state valutando se renderlo open source, ecco cosa vi dico dalla mia esperienza:
-
Non aspettate la perfezione. Il codice perfetto non esiste. Rilasciate quando funziona, migliorate dopo. La community (umana o AI) vi aiuterà.
-
Scegliete la licenza con cura. Non è un dettaglio burocratico. La licenza definisce cosa gli altri possono fare con il vostro lavoro. Informatevi prima di scegliere.
-
Scrivete un buon README. È la prima cosa che le persone vedono. Se il README è scarso, nessuno guarderà il codice.
-
Preparatevi alle issue strane. Su qualsiasi progetto open source prima o poi arriverà qualcuno che apre una issue tipo “non funziona” senza dare nessun contesto. Fa parte del gioco.
-
Usate CI/CD da subito. Test automatici, build automatiche, linting. Se il progetto è open source, queste cose non sono opzionali.
E adesso? #
TwentyMobile è su GitHub, su Google Play e sull’App Store. Il progetto è attivo, le feature continuano ad arrivare, e il codice è lì per chiunque voglia dare un’occhiata, contribuire, o semplicemente imparare qualcosa.
Se volete saperne di più sul progetto, passate dal sito ufficiale. E se vi va di contribuire, le PR sono aperte. Anche quelle degli agenti AI sono benvenute, a quanto pare.
La prossima volta vi racconto nel dettaglio come è costruita l’app dal punto di vista tecnico. Spoiler: Flutter, DDD, Connector Pattern, e un bel po’ di GraphQL.