Ao tocar um projeto de software livre, você não precisa falar sobre tais questões de caráter filosófico diariamente. Programadores não insistirão que todos os demais em um projeto concordem com suas visões sobre todas as coisas (aqueles que insistirem nisto rapidamente ficarão sem conseguir trabalhar em qualqeur outro projeto). Mas vocÇe precisa estar a par que a questão "livre" versus "código aberto" existe, parte para evitar assuntos que possam ser hostis para alguns dos participantes, e parte porque ententer as motivações dos desenvolvedores é a melhor maneira—em certo sentido, a única maneira— de gerenciar um projeto.
O software livre é uma cultura por escolha. Para tornar-se bem sucedido nela, em primeiro lugar você deve entender por que as pessoas escolhem estar nela. Técnicas coercivas não funcionam. Se as pessoas estão infelizes em um projeto, elas irão simplesmente partir para outro. O software livre é notável até mesmo entre comunidades voluntárias por seu baixíssimo investimento. A maioria das pessoas envolvidas nunca se encontraram com os outros participantes pessoalmente, e simplesmente doam parcelas de seu tempo quando bem entenderem. A conduta normal pelo qual humanos unem-se uns aos outros e formam grupos duradouros em um pequeno canal: a pala escrita, carregada através de cabos eletrônicos. Por causa disso, pode legar um longo tempo para formar um grupo coeso e dedicado. Por outr lado, é bem fácil para um proheto perder um potencial voluntário nos primeiros cinco minutos de adesão. Se o projeto não tem uma boa primeira impressão, recém-chegados raramente dão a ele uma segunda chance.
A transietoriedade, ou melhor, a potencial transietoriedade, de relacionamentos é talvez a tarefa mais assustadora frente um novo projeto. O que irá convencer todas essas pessoas a permanecerem juntas tempo suficiente para produzir algo útil? A resposta para esta questão é complexa o bastante para ocupar o resto deste livro, mas se isso pudesse ser expressado em uma sentença, seria algo assim:
As pessoas deveriam entender que suas conexões com um projeto, e a influência sobre ele, é diretamente proporcional a suas contribuições.
Nenhuma classe de desenvolvedores, ou potenciais desenvolvedores, deveriam sentir-se prejudicados ou discriminados por razões não técnicas. Claramente, projetos com patrocínio corporativo e/ou desenvolvedores assalariados precisam ser especialmente cuidadosos neste ponto, assim como o Capítulo 5, Money discute em detalhes. Claro que isso não significa que se não há patrocínio corporativo então você não tem que se preocupar. O dinheiro é meramente um dos muitos fatores que podem afetar o sucesso de um projeto. Existe também questões sobre qual linguagem adotar, a licença, o processo de desenvolvimento, precisamente qual o tipo de infra-estrutura a montar, como publicar o início do projeto efetivamente, e muito mais. Iniciar um projeto com o pé direito é um tópico do próximo capítulo.