Convincendo il cliente a restituire il lavoro open source

2

(Non sono sicuro che esistesse un sito di scambio di stack rilevante per questo, ne ho visto alcuni relativi all'open source nelle aziende e ho pensato che fosse simile, ma abbastanza diverso da giustificare una nuova domanda).

Abbiamo un cliente che stiamo per ritirare per un po 'di lavoro. Abbiamo terminato l'esplorazione per il loro prodotto e siamo giunti alla conclusione che avremo bisogno di usare una particolare libreria open-source.

Questa libreria è in sviluppo attivo e l'autore sta prendendo dei contributi, tuttavia ci sono alcune funzionalità di cui abbiamo bisogno che non sono ancora state create (e che non sono di immediata importanza per l'autore). Abbiamo pensato che sarà possibile per noi costruirli direttamente nella biblioteca, e ci piacerebbe se potessimo contribuire con i nostri cambiamenti al progetto. (Abbiamo cercato di essere attivi in Open Sourcing nel nostro lavoro quando non lo abbiamo sviluppato per un particolare cliente).

Tuttavia, riteniamo che potrebbe essere difficile cercare di convincere il cliente che una porzione ragionevole del lavoro che ci stanno pagando sarà data via gratuitamente a chiunque lo desideri. È anche improbabile che saremo in grado di utilizzare nuovamente questa libreria per il futuro lavoro del cliente, quindi non possiamo permetterci di prendere i costi per noi stessi.

Vale la pena sollevare questa possibilità con il cliente e se sì, come? O dovremmo semplicemente dare al cliente la nostra versione privata con le nostre modifiche?

    
posta SCB 28.07.2016 - 08:28
fonte

3 risposte

7

Se il progetto OS è in sviluppo attivo e si crea un fork con le proprie modifiche personalizzate, non è possibile eseguire l'aggiornamento a versioni future del ramo principale. A seconda del progetto, questo potrebbe essere un grosso problema o un non problema, ma cosa succede se bug e problemi di sicurezza vengono scoperti e risolti nel ramo principale della libreria? Se è necessario apportare comunque le modifiche personalizzate, il contributo è una vittoria netta per la manutenibilità.

Se il cliente non è immediatamente interessato all'OSS, dovresti evitare gli argomenti ideologici ("contribuire alla comunità" e così via), ma solo informare il cliente che in ogni caso devi fare lo sviluppo e contribuire nuovamente renderà più facile la manutenzione in futuro.

    
risposta data 28.07.2016 - 10:32
fonte
1

we feel that it could be difficult trying to convince the client that a reasonable portion of the work they're paying us for will be given away for free to anyone else who wants it

Lo stai già facendo, è solo che la maggior parte del codice è già stata pre-scritta.

Questo è il punto qui, ottengono tutto ciò che funziona gratuitamente, ma dovranno pagare un po 'di più per il lavoro extra per soddisfare le loro esigenze. Potresti usare una nuova libreria, ma il costo sarebbe doppio mentre re-implementi tutto nella lib di OSS.

Sii aperto e onesto su questa roba con il cliente, quando spieghi che ottengono la maggior parte del lavoro fatto gratuitamente e stanno pagando solo bit extra specifici per loro, saranno felici. È più probabile che tu debba spiegare perché l'OSS è buono, e perché non è virale e trasformerà l'intera azienda in polvere virtuale. Dopo tutto il clamore dei media da parte delle aziende che vogliono uccidere l'OSS per vendere più roba proprietaria, questo potrebbe essere un grande invito.

    
risposta data 28.07.2016 - 09:38
fonte
-1

Da quanto hai detto, non avrei sollevato questo problema con il cliente.

Chiarificazione - E non contribuire con le modifiche al codice al progetto come non le possiedi e non hai ottenuto l'autorizzazione dal client

Nella mia esperienza, i non programmatori possono avere una visione negativa dei prodotti open source e possono essere pienamente giustificati.

In questo caso, invece di ascoltare "in sviluppo attivo da un singolo sviluppatore", potrebbero sentire "un progetto incompiuto fatto da un adolescente sconosciuto nella loro camera da letto" e mettere in dubbio la scelta della biblioteca. Forse sollevando domande scomode sul supporto futuro.

Non fraintendermi, userò comunque la libreria, la inserirò sotto "Software di terze parti" ecc. ma non è qualcosa che agita la faccia dei clienti.

Se si trattava di un progetto ben noto, potrebbe valere la pena di continuare con i diritti di qdos e di vantarsi, ma in tal caso dovresti assumerti il costo tu stesso piuttosto che fatturarlo al cliente.

Un'altra alternativa potrebbe essere se è possibile neogitare la proprietà del codice. Sembra che tu possa avere le tue librerie che usi in progetti che presumibilmente autorizzi i client a usare come parte del loro codice. A mio avviso, aggiungere funzionalità a questi per supportare un progetto sarebbe ancora un lavoro fatturabile. Quindi se la libreria può essere inclusa in questo gruppo, sei libero di continuare a tornare al progetto

    
risposta data 28.07.2016 - 09:37
fonte

Leggi altre domande sui tag