DevOps - everything

[This material is a translation of a series of tweets by Michael DeKhan, one of the creators of the popular Ansible automation engine - approx. ]



So, opsmop has the same problem with the adoption and involvement schedule as vespene_io , and I also see no reason to continue. I stubbornly believe in the idea itself, but I think that the whole world of open source IT has burned out, and I'm tired of trying to interest people.



To those who say that this was a product not getting into the market, or that I should wait a little longer - with all due respect, you are wrong. I know about this area much more than anyone except five people in the world :-) The reasons for this are interesting ...



Essentially (1) an agile chart means that no one has time to work, (2) DevOps couldn’t work as intended. Both that and that took time for a gradual manifestation, and causing harm. Honestly, about 12 years old.



DevOps [-approach - approx. Transl . ] should have become like a hybrid of development and administration [ dev elopment / op eration s - approx. translation], but instead, people make everyday tools, and developers do a lot of what administrators are used to. And administrators become * even more * system administrators than they were at least in the middle of this period [at 12 years old - approx. Transl.]



The key to the success of open source is when the audience of users and developers (those who can contribute) strongly intersect, and are also involved and inspired.



In our case, a lot of discussions indicate that everyone is busy, no one has time, and yet ... everyone is more and more interested in solutions such as “little code / no code”. This does not apply to open source in general, but only to the IT administration segment.



Looking back at licensing discussions (Mongo, Redis, Confluent) - they were right, protecting themselves from “cloudy” abuses, but this also says something else: in order to start doing this, they had to face a decreasing value in interacting with the community.



True, not all the proposed improvements are always good, but the interaction and experience with people is a big positive. But they seem to slow down everywhere . You would probably think that if someone wrote one of those pieces on GitHub that receive the most requests for improvement, then people would like to try his new pieces and share ideas, but there are only 60 participants on my forum, and only 10 of them came in last week. Each project is cloned only twice a day, and then, most likely - automatically.



I see strong movement in other areas, such as the JavaScript ecosystem. I have a lot of enthusiasm for open source and sharing ideas. I talked a lot with people who have serious configuration management issues. But, in the end, the interaction fails.



Open source programs fuel interaction. And, basically, here is my diagnosis - large-scale burnout. It came slowly, and we did not notice it. Agile and DevOps - Burnout. In my opinion, in some areas we are technologically poorer than we were six years ago. Why?



We are tired, and just let everything go as it goes. We use the same as others. We launch clouds on top of our fucking clouds for no reason, and we are much more interested in technical fashion than in what makes us productive. We endure software with thousands of bugs.



We basically let our manager software become a joke. Instead of insisting on mastery of the space-rocket level, we simply screw on even more layers on top. And no one has the strength to say no. IT software has gone too far from any semblance of engineering.



I want to help fight this, but in the end, engagement and brainstorming are my fuel. If there is no involvement, and I can’t fix this involvement, I won’t get anything from it. So I turned out to be the very canary - to a greater or lesser extent.



I still love to write software, but I'm going to try to create projects that are interesting to me personally, and quite noticeably turn my back on helping leadership. That means stuff like my project for a music sequencer. Because I believe that people don’t give a damn about a hobby ...



I hope that here engagement will be expressed in large numbers. Well, if not, you can still use it to file cool tunes. Perhaps I will dive into some interesting things about data analysis, because they also interest me.



How can we fix open source for IT in general and in general? Take a look at what DevOps should be ... he should be just as much a developer, just as much an administrator. Fight the agile that eats your schedule. Try new things, think up, study options and do not try to be someone else.



Block Twitter “developer advocates." We love talking about representation, but think about what technology can mean “buy local.” Support small projects and ISVs [independent software vendors - approx. ]. Interact. Most of us feed on interaction more than anything else.



The future, in which we simply consume software released by one of the four brands, seems to me rather dull, especially if there is not enough code in this future. To survive this union, we need diversity. And in order to come to him, we must reject the ossification of practices.



We do very few things in the best way, but basically the way everyone does it. Most software that everyone wants to use is crap. Well, what's the catch, well, really? Give up mediocrity and do as you see fit.



Regarding that thing about depression / burnout - take care of your skills. Enjoy the performance. Create bulletproof items. Share written scripts. Blogging. Anything. Communicate and share even more. Perhaps, little by little, we can change that.



But next time, when the conversation comes to a paradigm shift like “agile” or “devops”, started by someone who has neither written nor built anything significant, be polite, but don’t be fooled by the fact that they are trying to make you laugh.



We should appreciate the engineering work — what we create, special, relevant things, not shitty sayings or repeating mantras about processes. The first ones are an indicator of our value and how much we are improving.



We made the movements that did this to us, and we still do. Acceptance of ossification [practitioner - approx. Transl. ] and spit on the quality of software that we all support, just have to stop. IT is engineering, so treat them accordingly.



If this is difficult for me , imagine what it is like for someone without a platform. For me, OSS was a great way to get to know a lot of people, and a lot of joy, and ... if I can’t do it today - oh ...



All kinds of cool help regarding the OSS movement that we enjoyed at RedHat in 2006 is something that I just don't believe today. The movement was not erroneous, just something moved in the culture, and killed him.



I cannot help thinking that it was not because Red Hat was sold not for the distribution, but (according to an IBM announcement) for the Kubernetes and OpenStack distributions. Did they run into this too? What does every large company with an OSS project think about engagement, but cannot say?



Of course, they would most likely say something else, but I wonder what they think. And I think that they all think that freemium is a good download model, but real code and collaboration mean nothing more, because people are not involved.



(to everyone who puts a “plus” for this, hmm ... thanks?)