Capisco perfettamente.[1] Mi piace davvero Discourse e ho scritto questo post perché voglio che Discourse continui ad avere successo.
Ho imparato che le comunità non amano i cambiamenti, ma sono molto più aperte ai cambiamenti se sentono di avere un ruolo attivo. Ci sono innumerevoli modi per dare alle persone un ruolo attivo. Ad esempio, il tutorial potrebbe essere trasformato in post wiki in modo che persone come me possano aggiornarli. Anche l’implementazione del piano ESR aiuta, perché offre la possibilità di non apportare cambiamenti immediatamente.^[Meno utile per gli autori di plugin che vogliono supportare comunità che desiderano rimanere all’avanguardia. Ma sarà fantastico per me, dato che credo di essere l’unica persona che utilizza il mio plugin.) Anche poter scrivere la mia esperienza e farla vedere alle persone che gestiscono il progetto open source aiuta. Soprattutto perché le cose di cui mi sono lamentato sono state risolte in una notte. 
In “Ascoltare gli utenti è considerato dannoso?”,[2] Kathy Sierra scrisse:
La maggior parte di noi si rende conto che i focus group sono notoriamente inefficaci per molte cose, ma continuiamo a presupporre che ascoltare feedback reali da utenti reali sia il modo migliore per guidare nuovi prodotti e servizi, nonché per migliorare ciò che abbiamo. Ma c’è un enorme problema con questo: le persone non necessariamente sanno come chiedere qualcosa che non hanno mai concepito! La maggior parte delle persone fa suggerimenti basati interamente su miglioramenti incrementali, guardando ciò che esiste e pensando a come potrebbe essere migliore. Ma questo è molto diverso dall’avere una visione per qualcosa di profondamente nuovo.
La vera innovazione raramente deriva da ciò che gli utenti dicono direttamente.
Come ho detto, non sono uno sviluppatore frontend. Non capisco davvero perché siano stati apportati questi cambiamenti o come mi porteranno benefici.[3] E va bene se, alla fine, renderanno Discourse migliore.
Tuttavia, può aiutare persone come me a stare dalla parte giusta se riesco a vedere la visione un po’ più chiaramente. Per questo cambiamento, la proposta è:
- un’esperienza di sviluppo molto migliore
- abiliterà grandi miglioramenti delle prestazioni nelle versioni future di Discourse
Sembra buono, immagino? Non ho notato in particolare il punto #1 e il #2 potrebbe significare molte cose. Per me sarebbe stato più efficace qualcosa del genere (e sto proprio inventando):
- Quando abbiamo convertito i plugin ufficiali di Discourse, abbiamo scoperto che abbiamo risparmiato X% di righe di codice. Mettendo il template nello stesso file del JavaScript, il codice è più facile da comprendere e modificare in futuro.
- Abbiamo creato un ramo di test rimuovendo completamente Handlebars e abbiamo scoperto che questa modifica ha reso il caricamento delle pagine X% più veloce. Non solo, abbiamo visto un’ottimizzazione potenziale che potrebbe eliminare [alcuni problemi sollevati dagli utenti].
Un po’ più di dettagli con l’obiettivo di educare i non esperti fa molto per mantenere la fiducia. Potrei non piacere i cambiamenti, ma come posso contestare la risoluzione di problemi reali affrontati da altri utenti?
OpenSSL ha una dinamica simile. Abbiamo una Corporation (circa 15 persone) che vende contratti di supporto e una Fondazione (10 persone, me compreso) che si occupa degli interessi non commerciali. Anche la nostra documentazione è in ritardo. Mentre scrivevo il post originale, ho notato che abbiamo ancora riferimenti a funzionalità rimosse lo scorso mese. Sto lavorando a una PR per risolvere questo problema. Inoltre, abbiamo apportato alcune modifiche che i progetti a valle hanno criticato aspramente. ↩︎
Il suo blog è scomparso da internet, ma esiste un archivio PDF. ↩︎
Non che io conti molto nel grande schema delle cose. Sto parlando di me come rappresentante di altre persone che dipendono da Discourse. Del resto, conosco meglio me stesso di chiunque altro! ↩︎