[Este material é uma tradução de uma série de tweets de Michael DeKhan, um dos criadores do popular mecanismo de automação Ansible -
aprox. ]
Portanto, o
opsmop tem o mesmo problema com o cronograma de aceitação e envolvimento do
vespene_io , e também não vejo razão para continuar. Eu teimosamente acredito na idéia em si, mas acho que todo o mundo da TI de código aberto se esgotou e estou cansado de tentar interessar as pessoas.
Para aqueles que dizem que este foi um produto que não estava entrando no mercado ou que eu deveria esperar um pouco mais - com todo o respeito, você está errado. Conheço esta área muito mais do que ninguém, exceto cinco pessoas no mundo :-) As razões para isso são interessantes ...
Essencialmente (1) um gráfico ágil significa que ninguém tem tempo para trabalhar, (2) o DevOps não funcionou como planejado. Isso e aquilo levaram tempo para uma manifestação gradual e causando danos. Honestamente, cerca de 12 anos de idade.
DevOps [abordagem - aprox
. ] deveria ter se tornado um híbrido de desenvolvimento e administração [desenvolvimento / operação
s - aproximadamente tradução], mas, em vez disso, as pessoas criam ferramentas cotidianas e os desenvolvedores fazem muito do que os administradores estão acostumados. E os administradores tornam-se * ainda mais * administradores de sistema do que eram pelo menos no meio desse período [aos 12 anos - aproximadamente Transl.]
A chave para o sucesso do código aberto é quando o público de usuários e desenvolvedores (aqueles que podem contribuir) se cruzam fortemente e também estão envolvidos e inspirados.
No nosso caso, muitas discussões indicam que todos estão ocupados, ninguém tem tempo e, no entanto ... todos estão cada vez mais interessados em soluções como "pequeno código / sem código". Isso não se aplica ao código aberto em geral, mas apenas ao segmento de administração de TI.
Olhando para as discussões sobre licenciamento (Mongo, Redis, Confluent) - eles estavam certos, se defendendo de abusos "nublados", mas isso também diz outra coisa: para começar a fazer isso, eles tiveram que enfrentar um valor
decrescente na interação com a comunidade.
É verdade que nem todas as melhorias propostas são sempre boas, mas a interação e a experiência com as pessoas são um
grande positivo. Mas eles parecem diminuir a velocidade em
todos os
lugares . Você provavelmente pensaria que se alguém escrevesse uma dessas peças no GitHub que recebesse mais pedidos de melhoria, as pessoas gostariam de experimentar as novas peças e compartilhar idéias, mas no meu fórum há apenas 60 participantes e apenas 10 deles chegaram na semana passada. Cada projeto é clonado apenas duas vezes por dia e, provavelmente, automaticamente.
Eu vejo movimentos fortes em outras áreas, como o ecossistema JavaScript. Tenho muito entusiasmo pelo código aberto e pelo compartilhamento de idéias. Conversei bastante com pessoas que têm
sérios problemas de gerenciamento de configuração. Mas, no final, a interação falha.
Programas de código aberto estimulam a interação. E, basicamente, aqui está o meu diagnóstico - burnout em larga escala. Veio devagar e não percebemos. Agile e DevOps - Burnout. Na minha opinião, em algumas áreas somos tecnologicamente
mais pobres do que há seis anos. Porque
Estamos cansados e deixamos tudo correr como está. Usamos o mesmo que os outros. Lançamos nuvens em cima de nossas malditas nuvens sem motivo, e estamos muito mais interessados na moda técnica do que no que nos torna produtivos. Nós suportamos software com milhares de bugs.
Basicamente, deixamos nosso software de gerenciamento se tornar uma piada. Em vez de insistir no domínio do nível dos foguetes espaciais, simplesmente parafusamos ainda mais camadas por cima. E ninguém tem força para dizer não. O software de TI foi longe demais de qualquer aparência de engenharia.
Quero ajudar a combater isso, mas no final, o engajamento e o debate de ideias são o meu combustível. Se não houver envolvimento, e não posso consertar esse envolvimento, não vou conseguir nada com isso. Então eu me tornei o canário - em maior ou menor grau.
Eu ainda amo escrever software, mas vou tentar criar projetos que são interessantes para mim pessoalmente e, visivelmente, dar as costas para ajudar a liderança. Isso significa coisas como o meu projeto para um seqüenciador de música. Porque acredito que as pessoas não dão a mínima para um hobby ...
Espero que aqui o engajamento seja expresso em grandes números. Bem, se não, você ainda pode usá-lo para registrar músicas legais. Talvez eu mergulhe em algumas coisas interessantes sobre análise de dados, porque elas também me interessam.
Como podemos corrigir o código aberto da TI em geral e em geral? Dê uma olhada em quem deve ser o DevOps ... ele deve ser tanto um desenvolvedor quanto um administrador. Lute contra o ágil que devora sua agenda. Tente coisas novas, pense, estude opções e não tente ser outra pessoa.
Bloquear o Twitter "defensores do desenvolvedor". Adoramos conversar sobre representação, mas pense no que a tecnologia pode significar "comprar local". Suporte a pequenos projetos e ISVs [fornecedores independentes de software -
aprox. ] Interagir. A maioria de nós se alimenta de interação mais do que qualquer outra coisa.
O futuro, no qual simplesmente consumimos software lançado por uma das quatro marcas, me parece bastante tedioso, especialmente se não houver código suficiente no futuro. Para sobreviver a essa união, precisamos de diversidade. E, para procurá-lo, devemos rejeitar a ossificação das práticas.
Fazemos muito poucas coisas da melhor maneira, basicamente da maneira como todo mundo faz. A maioria dos softwares que todo mundo quer usar é uma porcaria. Bem, qual é o problema, bem, sério? Desista da mediocridade e faça o que achar melhor.
Com relação a isso sobre depressão / esgotamento - cuide de suas habilidades. Aprecie o desempenho. Crie itens à prova de balas. Compartilhe scripts escritos. Blogging. Qualquer coisa. Comunique e compartilhe ainda mais. Talvez, aos poucos, possamos mudar isso.
Mas da próxima vez, quando a conversa chegar a uma mudança de paradigma como "ágil" ou "devops", iniciada por alguém que não escreveu nem construiu nada de significativo, seja educada, mas não se deixe enganar pelo fato de que eles estão tentando fazer você rir.
Deveríamos apreciar o trabalho de
engenharia - o que criamos, coisas especiais e relevantes, sem dizeres de merda ou repetindo mantras sobre processos. Os primeiros são um indicador do nosso valor e do quanto estamos melhorando.
Fizemos os movimentos que fizeram isso conosco e ainda fazemos. Aceitação da ossificação [praticante
- aprox. Transl. ] e cuspir na qualidade do software que todos apoiamos, basta parar. TI é engenharia, então trate-os de acordo.
Se isso é difícil para
mim , imagine como é para alguém sem plataforma. Para mim, o OSS foi uma ótima maneira de conhecer muitas pessoas, e muita alegria, e ... se
eu não posso fazer isso hoje - oh ...
Todo tipo de ajuda interessante sobre o movimento OSS de que desfrutamos na RedHat em 2006 é algo em que simplesmente não acredito hoje. O movimento não foi errado, apenas algo mudou na cultura e o matou.
Não consigo deixar de pensar que não foi porque a Red Hat foi vendida não para a distribuição, mas (de acordo com um anúncio da IBM) para as distribuições Kubernetes e OpenStack. Eles se depararam com isso também? O que toda grande empresa com um projeto OSS pensa sobre o envolvimento, mas não pode dizer?
Claro, eles provavelmente diriam outra coisa, mas eu me pergunto o que eles pensam. E acho que todos pensam que o freemium é um bom modelo de download, mas código e colaboração reais não significam mais nada, porque as pessoas não estão envolvidas.
(para todo mundo que coloca um "mais" por isso, hum ... obrigado?)