In che modo il ruolo del product owner può andare contro l'idea di open source o lavorare per esso?

Per me, non sembra che il ruolo di un product owner vada contro l'idea di open source.

Le idee del software open source sono libere di apprendere, migliorare, cambiare e distribuire nei modi migliori possibili che risolvono i problemi del mondo reale. Si tratta di collaborazione per creare un prodotto disponibile al pubblico e utilizzabile, con un grande senso di trasparenza e visibilità.

La domanda che hai collegato per discutere di un product owner nel senso di Scrum - un individuo che rappresenta la voce del cliente / utente per il team di sviluppo. Questa è una persona che garantisce che il prodotto sia prezioso creando (o, in alcuni casi, trasformandolo in una forma utilizzabile) e dando priorità ai requisiti e ai rapporti sui difetti.

Esistono diverse strutture per l'esecuzione di progetti open source, proprio come ci sono diverse metodologie di sviluppo e strutture di team nelle aziende che sviluppano software commerciale. Non conosco nessun team open source che abbia un ruolo di "proprietario del prodotto", ma in alcuni casi posso considerarlo utile.

Il ruolo del proprietario del prodotto sarebbe probabilmente più utile in un progetto in cui il team di sviluppo è disgiunto (completamente o parzialmente) dagli utenti del software. Guardando pacchetti software open source, cose come GNUmed , Koha , e Tux Paint si distinguono - il target di riferimento sono le persone con background molto diversi rispetto agli sviluppatori di software (anche se alcuni utenti dei pacchetti potrebbero avere esperienza nello sviluppo di software) e spesso hanno esigenze o requisiti particolari che devono essere capiti. Qualcuno o alcune persone in un ruolo simile al proprietario del prodotto sarebbero utili per garantire che il prodotto sia utile per il pubblico di destinazione.

Se qualcosa avesse una discussione più dettagliata e autorevole su questo, sospetterei che sarebbe gli scritti di Eric S. Raymond . Sembra qualcosa che potrebbe essere discusso in La cattedrale e Il bazar, o un saggio simile di Raymond. Tuttavia, è passato un po 'di tempo da quando ho letto questi lavori, quindi non posso citare nulla in particolare.

Il concetto di Benevolent Dictator for Life è simile. Alcuni progetti Open Source hanno creatori che non sono necessariamente coinvolti direttamente in ogni cambiamento ma hanno un veto esplicito o implicito su qualsiasi cosa accada con quel software o linguaggio. Esempi includono Larry Wall of Perl, Guido Van Roussom di Python e Linus Torvalds per Linux.

Non è un ruolo tradizionale nei progetti open source, in quanto il Product Owner è tipicamente un responsabile per il successo di un progetto di:

• guida lo sforzo di sviluppo trasmettendo la sua visione al team,
• delineare il lavoro nel misum backlog,
• e prioritizzazione in base al valore aziendale.

Nelle comunità open source queste responsabilità sono generalmente condivise tra membri senior o assegnate a gestori di pacchetti e così via, a seconda della metodologia (o della mancanza) del progetto. Ma non vi è alcun motivo per cui un progetto open source non possa adottare Scrum e nominare un Product Owner.

In genere, se gli autori originali del progetto sono ancora attivi, possono avere un po 'più di voce in operazioni e processi che rientrano nelle responsabilità del proprietario del prodotto. Un termine comune per loro è Benevolent Dictator for Life , che sebbene sia di lingua e casual, è riservato ai fondatori del progetto con un buona parte di partecipazione attiva e iniziative e responsabilità di leadership.

Come per Mozilla, un ruolo correlato sarebbe Proprietario del modulo :

A "module owner" is the person to whom leadership of a module's work has been delegated. The responsibilities of module ownership might include, in the case of a code module: improving code quality, implementing revisions and innovations as appropriate, coordinating development with that of the rest of the codebase, developing and maintaining a shared understanding of where the module is headed, developing APIs where appropriate, documenting as much as possible, responding appropriately to code contributions, design suggestions and stated needs of the community, and creating an environment where competent newcomers are welcomed and included.

Ma il ruolo è molto più simile a Scrum Master rispetto a Product Owner.

Di recente ero curioso di questa domanda. Anche se non ho letto molto sull'argomento. A mio parere, il concetto di proprietario del prodotto è tanto importante per l'open source quanto altri tipi di progetti perché il proprietario del prodotto è ciò che imposta la priorità (ad esempio, decide quali caratteristiche sono importanti e quali possono essere ritardate o eliminate).

Anche i team open source devono disporre di un backlog che gestiscono e questo backlog deve avere la priorità in base all'importanza.

Tuttavia, mentre il concetto di "product owner" è importante, probabilmente potrebbe essere fatto da più di una persona poiché nell'open source quasi tutti sono volontari, quindi è possibile che il tempo debba essere suddiviso tra più persone.

Quindi ci sono alcune opzioni:

1. Se il progetto open source ha uno o pochi principali clienti / utenti primari. La persona del proprietario del prodotto o un gruppo di persone dovrebbe lavorare per mantenere relazioni attive e sane con questi utenti in modo che possano tornare al resto del team di progetto open source e comunicare le esigenze di tali utenti finali.

2. Se il progetto open-source viene utilizzato da un vasto pubblico ed è difficile avere un senso generale di quali funzioni sono importanti parlando con pochi selezionare, un'altra opzione sarebbe probabilmente quella di impostare una richiesta di funzionalità pubblica / segnalazione di bug sito web. Poi monitoralo e vedi che tipo di funzionalità / correzioni di bug le persone chiedono di più. Anche in questo caso, la persona / gruppo proprietario del prodotto (chiunque volontario) dovrà setacciare tali rapporti e adeguare di conseguenza il backlog.

Il termine product owner è un po 'ambiguo. L'interpretazione ovvia (ma solitamente errata) sarebbe "qualcuno che ha la proprietà legale del prodotto, del codice e delle risorse correlate". L'interpretazione meno ovvia ma più corretta (nei circoli di sviluppo del software) è "la persona che ha la responsabilità di prendere decisioni definitive sul prodotto".

Il primo significato è chiaramente in contrasto con molti prodotti open source poiché i singoli contributori spesso mantengono i diritti sul codice che essi contribuiscono. In questi casi, un singolo prodotto potrebbe avere centinaia o migliaia di "proprietari" che "possiedono" una piccola parte del codice che produce il prodotto finale. Alcuni progetti chiedono ai contributori di assegnare i loro diritti a un'organizzazione (come la FSF) in modo che il codice possa essere meglio protetto, ma anche in quel caso l'organizzazione che "possiede" i diritti del codice di solito non è il "proprietario del prodotto" in il senso del decision maker dello sviluppo del software.

Il secondo significato, che dalla tua domanda è chiaramente quello che intendi, potrebbe a volte sembrare essere in contrasto con il solito processo open source, che è spesso visto come democratico. Un vantaggio spesso dichiarato del software open source è che se un prodotto non ha una funzionalità che si desidera, è possibile aggiungere tale funzionalità e quindi fornire il codice al progetto a beneficio di tutti gli altri. Sebbene funzioni in questo modo per la maggior parte del tempo, ci si sbaglia a pensare che non ci sia qualcuno che ha la responsabilità di rivedere i contributi e decidere quali accettare e quali rifiutare. Solo perché ti capita molto tempo non significa che non ci sia un dittatore. Quella persona è il proprietario del prodotto e la maggior parte dei progetti ne ha uno.

Supponendo che stiamo parlando del movimento "Free / Libre Open Source Software" (FLOSS), il concetto di proprietà del software è completamente incompatibile. Una delle idee chiave di FLOSS è che il software, proprio come le opere letterarie, artistiche e musicali, non può essere di proprietà di nessuno. Una volta scritto il software, deve essere reso disponibile a chiunque, con solo restrizioni minime (se presenti).

All'interno delle comunità, le opinioni divergono sulle restrizioni che possono essere applicate al software per renderlo massimamente "libero", ma nessuno di loro è compatibile con un concetto di proprietà. La proprietà implica che il proprietario ha il diritto di impedire ad altri di utilizzare il software; FLOSS richiede che non esistano restrizioni del genere.

La cosa più vicina al proprietario di un progetto, nel Software Libero, sarebbe il lead del progetto o il manutentore del progetto. Spesso, questa persona è anche l'autore originale e pubblica la versione "ufficiale", decidendo quali modifiche sono incluse e quali no. Tuttavia, anche per i progetti più rigidamente organizzati, il proprietario del progetto non ha un potere "assoluto" - chiunque è libero di imporre il progetto, modificarlo in qualsiasi modo e ridistribuire il risultato, e se il manutentore del progetto assume un strong impatto decisioni, la comunità tende a migrare in massa verso un fork saner, che diventa il nuovo standard.