devopsy.kinsta.cloud

Tag: compensation

Survey Finds Compensation Drives Better Open Source Software Security Behavior

A survey of 400 maintainers of open-source software projects suggests IT organizations should be paying a lot more attention to the degree to which the stewards of these projects are compensated before downloading software components.

Conducted by Tidelift, a provider of a platform that is used to compensate maintainers of open-source software projects, the survey finds that paid maintainers of open-source software projects are 55% more likely to implement critical security and maintenance practices than unpaid maintainers.

The top security practices implemented by paid maintainers include two-factor authentication (76% compared to 68% for unpaid maintainers), static code analysis (75% vs. 59%), providing fixes and recommendations for vulnerabilities (70% vs. 54%), security disclosure plan (66% vs. 43%), secrets management (58% vs. 39%), and signed release and published artifact provenance (50% vs. 28%).
The top maintenance practices implemented by paid maintainers include a formal policy around backward compatibility (59% compared to 39% for unpaid maintainers), reproducible and verifiable build process (58% vs. 50%), code peer review process with multiple reviewers (53% vs. 27%), and a defined dependency management process (50% vs. 33%).

In addition, paid maintainers are also 55% more likely to implement security practices such as the OpenSSF Scorecard and the NIST Secure Software Development Framework (SSDF). However, only a total of roughly 40% of respondents said they were even aware of these frameworks.

Overall, the survey finds that 60% of respondents are unpaid for their efforts, with 44% acknowledging they would appreciate getting paid for their efforts. Only 16% wanted no compensation.

A quarter of maintainers (25%) report receiving income from donation programs, while for 24% of maintainers, their open-source maintenance work is paid for as part of their salary because it is an explicit part of their job responsibilities. Another 19% of maintainers report receiving income from Tidelift. Only a very small percentage of maintainers report receiving income from other sources, including 5% reporting direct payments or donations from companies other than their employer and another 5% reporting direct payments or donations from individuals.

Only 3% report that they have received income from open-source foundations and only 1% receive direct payments or donations from governments or other public entities.

Not surprisingly, about half of maintainers said they are not compensated enough, while 48% said they are unappreciated for doing thankless work. A full 43% said they add stress to their daily lives and well over half 60% have quit or considered quitting their maintenance work.

Maintainers are now, on average, spending 11% of their time and effort on security work and two-thirds (66%) of maintainers report that they are now less trusting of pull requests from non-maintainers in the wake of the XZ Utils hack.

A Toll on the Open-Source Community

Tidelift CEO Donald Fischer said for better and worse efforts to insert malware into software components that are used in downstream applications are taking a toll on the open-source software community. However, despite that level of added stress, most maintainers are skeptical of artificial intelligence (AI) tools. Two-thirds (64%) of maintainers would be less likely to review and accept contributions they knew were created using AI-based coding tools. The overall maintainer perception of the impact of AI-based coding tools on their work leaned negative, with almost half (45%) of maintainers predicting that these tools will have a somewhat negative (22%) or extremely negative (23%) impact on their work.

It’s not clear to what degree the open-source software community might be on the cusp of crisis if there are no longer enough maintainers willing to participate in software development initiatives. However, the one certain thing is there needs to be more incentives and financial rewards for taking on tasks that fewer are willing to simply do when so many others are benefiting from their efforts so much more.

September 27, 2024
7 Steps to DevOps Hiring Success

As many of us in the DevOps scene know, most companies are hiring, or, at least, trying to do so. The required skills and job descriptions can change entirely from company to company. As a broad overview, most teams are looking for a candidate from either an operations and infrastructure background or someone from a software engineering and development background, then combined with key skills relating to continuous integration, configuration management, continuous delivery/deployment and cloud infrastructure. Currently in high-demand is knowledge of container orchestration.

In the ideal world, the two backgrounds will meet somewhere in the middle to form Dev and Ops, but in most cases, there is a lean toward one side or the other while maintaining sufficient skills to understand the needs and demands of their counterparts to work collaboratively and achieve the end goal of continuous delivery/deployment. Every company is different and there isn’t necessarily a right or wrong here. It all depends on your infrastructure, tech stack, other team members’ skills and the individual goals you hope to achieve by hiring this individual.

Focus Your Hiring

Now, given the various routes to becoming a DevOps practitioner, how do hiring managers focus their search and selection process to ensure that they’re hitting the mark?

Decide on the Background

Assess the strengths of your existing team. Do you already have some amazing software engineers but you’re lacking the infrastructure knowledge? Aim to close these gaps in skills. You may have been given the budget to hire for DevOps, but you don’t have to spend weeks/months searching for the best software engineer who happens to use Docker and Kubernetes because they are the current hot trends in this space. Find the person who will provide the most value in your environment and go from there.

Contractor or Permanent Employee?

Many hiring managers will automatically start searching for a full-time permanent employee when their needs may suggest that they have other options. Sometimes a contractor is your best bet or maybe contract-hire. If you’re aiming to design, implement and build a new DevOps environment, why not find a senior person who has done this a number of times already? Try hiring a senior contractor and bring on a junior full-time hire in parallel; this way, you’ll be able to retain the external contractor knowledge by having them work alongside the junior hire. Contractors can be expensive, but the knowledge they bring can be invaluable, especially if the work can be completed over a shorter time frame. Again, this is just another point of view and you might be best off with a full-time hire to grow the team.

CTRL F is not the Solution

Focus on their understanding of DevOps and CI/CD-related processes over specific tools. I believe the best approach is to focus on finding someone who understands the methodologies over the tools. Does your candidate understand the concept of continuous integration or the concept of continuous delivery? That’s more important than asking whether your candidate uses Jenkins versus Bamboo versus TeamCity and so on. Try not to get caught up in the exact tool chain. The focus should be on the candidates’ ability to solve problems. Are they obsessed with increasing efficiency, saving time, automating manual processes and constantly searching for flaws in the system? They might be the person you were looking for, but you missed them because you didn’t see the word “Puppet” on the resume.

Work Closely with your Internal Talent Acquisition Team and/or an External Recruiter

Be clear and precise with what you’re looking for and have an ongoing, open communication with recruiters. They can and will help you if used effectively. The job of these recruiters is to save you time by sourcing candidates while you’re focusing on your day-to-day role. Work closely with them and deliver in the same way that you would expect them to deliver for you. If you say you will review a candidate by X time, do it. If they say they’ll have a candidate in your inbox by Y time, make sure they do it, too. Start by setting up an initial call to talk through your requirement, lay out a timeline in which you expect candidates by a specific time and explain your process in terms of when you will interview, how many interview rounds and how soon after you will be able to make a final decision on whether to offer or reject the candidates. If you can get this relationship working well, you’ll save lots of time. And make sure your internal teams are focused on supporting your process, not blocking it.

$$$

Decide how much you want to pay. It’s not all about the money, but you can waste a lot of your and other people’s time if you don’t lock down the ballpark salary or hourly rate that you can afford. If your budget doesn’t stretch as far as your competitors’, you need to consider what else can help sell the opportunity. Flexible working hours and remote working options are some great ways to do this. Most companies have snacks, beer and cool offices nowadays, so focus on the real value such as the innovative work your team is doing and how awesome your game-changing product might be.

Drop the Ego

You may have an amazing company and/or product, but you also have some hot competition. Everyone is hiring in this space and candidates have a lot of the buying power. It is no longer as simple as saying, “We are hiring” and the awesome candidates come flowing in. You need to sell your opportunities. Maintaining a reputation as a great place to work is also important. A poor hiring process, such as interviewing without giving feedback, can contribute to bad rumors being spread across the industry. It only takes a few minutes to leave a sour review on Glassdoor.

A Smooth Process is a Successful One

“Let’s get every single person within the company to do a one-hour interview with the new DevOps person we are hiring!” No, let’s not do that. Two or three stages should be sufficient. You have managers and directors for a reason. Trust your instinct and use your experience to make decisions on who will fit into your organization. Some of the most successful companies can do one phone screen followed by an in-person meeting. During the in-person interview, spend a morning or afternoon allowing the candidate to meet the relevant leaders and senior members of their direct team, then take them for lunch, dinner or drinks where you can see how they are on a social level. If you can’t have a simple conversation with them, then you probably won’t enjoy working with them. If the thumbs are up, make the hire and don’t wait around. A good candidate will usually have numerous offers on the table at the same time.

If all goes well, you should be inviting your shiny new employee or contractor into the office in the next few weeks and hopefully many more throughout the year.

About the Author / Conor Delanbanque

Conor Delanbanque has been recruiting and leading recruitment teams in the DevOps space for the past few years. As well as being exclusively responsible for growing some of the most innovative DevOps & SRE teams in the US and Europe as an external consultant and recruiting partner, Conor also founded the Future of DevOps Thought Leaders Debate, sponsors DockerNYC Meetup on a regular basis and co-hosts ServerlessNYC. You can tweet him at @ConorDevOps, find him on LinkedIn or at events, expos and writing articles on devopsy.kinsta.cloud.

June 21, 2017
The War with Human Nature

What is the difference between “leading” edge and “bleeding” edge? Being the first human being to advocate change.

It is a virtual war with human nature to accept change. For all the innovation introduced into our society, most of it is a product of invention over evolution. Don’t get me wrong: Once we find something that works, we inherently work tirelessly to make it better, thus evolving it over time. But the genesis of the “new” is easier to accept as creation—a new idea, a new innovation of our own—than a change in direction, a forced acceptance of the ideas or creations that were “not invented here.”

In the workplace, most employees are looking for personal security, for a feeling derived from consistency and predictability in the day-to-day work activities. Anything that threatens an employee’s ability to continue to secure compensation becomes something that inherently meets our resistance. The No. 1 culprit: you guessed it … “change.” As long as what I do remains the same, over time I will get better and better at it. Practice makes perfect. But when something “new” is introduced in the actions I am supposed to perform, there is a risk that my value, my expertise, will be reset to zero and perhaps I will not be valued as I once was. This threat to my compensation is real; therefore, my resistance to it is equally real.

Programmers Found Guilty

You would think that engineers and those working in the software industry would be exempt from this phenomenon. But most are not. Finding an ex-Cobol, ex-Clipper, ex-Windows, current mobile Apple iOS programmer is like finding a unicorn in Central Park. Most successful Cobol programmers are still Cobol programmers, looking for jobs in mainframe shops, content to see the new generation of programmers not competing for their declining job markets. The early generation of programmers minted after the adoption of the PC computer tend to know less about Cobol and RPG-3 and more about PC-based programming languages such as GW-Basic and Pascal (at least the older ones). Programmers minted after the Windows graphical adoption know more about that generation of coding languages, and so on, and so on.

The basics of coding have remained the same since the advent of this discipline. We create a list of instructions, in sequential order, that the computer must execute to produce a desired result. There are nuances to this, and an explosion of capability in this, but the basic principles remain much the same. Yet, programmers well-versed in a particular language are shy about learning a new one, unless the platform is similar, the features are similar (albeit improved) and the belief is high that they will be successful in the new language quickly. There is no reason why a Cobol programmer could not be successful creating mobile apps. Or, for that matter, a mobile app developer could try his hand at Cobol. But it seems neither do, at least not very often.

What happens instead is that each programmer begins to establish his/her own ecosystem of support: simulation models that imitate the platform responses, highly evolved text entry tools that auto-format code and check for omissions such as missing parenthesis and scripted tools that perform the mundane tasks we need to build (or construct) new versions of code or deploy a build into a new environment. This same ecosystem of support will exist for database, network and middleware engineers as well. The tools will be decidedly different, but the reasoning for them tends to be identical: to make things easier to do.

Looking for a Magic Bullet

There is no cure for breaking down the resistance to change, except constant exposure to it. However, forcing employees to face perceived threats to their value—and their compensation—will, at a minimum, produce exorbitant stress at work—or, worse, an employee turnover rate that would rival donuts next to a police station. The goal is to introduce change that will ultimately increase the value of an employee, as well as potentially increase the compensation they worry about. This is where the DevOps value proposition must be created for each impacted audience. A generic value statement is not enough, nor is a mandate by top company executives. You cannot “force” people to adopt something new, anything new.

Creating the right value proposition must be specific to the audience you seek to adopt the “new” system, tooling or process. DevOps is a continuum of all three (people, process, technology). So for the database team, for example, changing out the ecosystem it has evolved into a new set of tools and processes, may seem like a hard sell at first. The advocate of DevOps (whether the exec teams or the service teams delivering it) must be able to articulate the value proposition clearly to the database teams.

“Why” should they move to a newer ecosystem? A stubborn engineer can always point out the holes in your tool and the beauty of his own. He/she will likely have evolved his/her own support ecosystem to a state of near utopia … but only for himself. Usually the processes and tooling engineers use to make their own lives better do not scale to others in the department. And God forbid some other engineer updates “their” scripts or makes changes to “their” process. While this is wonderful for the engineer who creates it, it is miserable for anyone else attempting to use it.

Constructing a Value Proposition

The value statement must trade prima donna utopia for scale. Using common DevOps tooling, it is possible to support many more task requests than most individually constructed ecosystems can handle in a given day. And believe me, those task request increases in volume are coming. For example, an Ops engineer may be able to handle provisioning five systems a day with his own tooling, but when requests come in to provision 50 or 100, he is dead in the water. Having the Ops engineer help manage the deployment template or framework allows users to self-serve on provisioning requests and keeps him from having to do everything for everybody. His job is different but every bit as important.

The value statement must trade current skills proficiency for next-generation, market-valued skills. In effect, a database guy is valuable, but a DevOps database guy is considerably more valuable, or a “big data” database guy, or a IoT database guy … pick your poison. Whatever you are today, whatever skill set you have, the jobs that pay more money are the jobs that fewer people know how to do. At some point, a lack of DevOps proficiency will relegate an engineer to the pages of history. On the other hand, adopting and embracing DevOps will allow engineers to get the training they so desperately need to keep their career “fresh.”

Finally, the value statement must trade today’s earnings for tomorrow’s increase in earnings. Companies that embrace DevOps are going to either save extreme amounts of overhead by staff reduction remaining at the same level of innovation productivity. Or, they are going to increase innovation productivity levels radically, making them leaders in their respective space by meeting customer demand much faster with higher quality (the path most taken). Either option should translate into higher compensation for employees who embrace DevOps. If companies do nothing to increase employee comp, choosing only to increase profits, competing firms will be happy to poach them and pay them more instead. This forces more costs in recruiting, training and employee turnover when it happens again.

A Human Strategy that Works

Your strategy for training employees to embrace change should be particular to the kind of work they do, and reflect the things that will matter to them. If you need help crafting a strategy let me know, I am looking at the moment 🙂 . Not every team will be as critical to the overall success of DevOps as perhaps your engineers are, but the value proposition should adjust for this fact. Keep in mind, if the change is less, then the resistance will be less as well. Your accounting, HR and legal teams, for example, may not feel the impact of DevOps as rapidly or as severely (in terms of change); thus, their resistance may be less, but it is likely more than zero.

DevOps is about people, process and technology. It is in that order, with a heavy emphasis on people and a relatively light impact from tooling. And it will succeed or fail based on the embrace of people, process and technology. Process and technology do not care about change. People do. Since people are the largest priority or component of DevOps, it is their fears that must be addressed and their value that must be enumerated to succeed.

To continue the conversation, feel free to contact me.

May 20, 2016
To Be Continuous Podcast: Open Source Economics

Welcome to To Be Continuous, a show about continuous delivery and software development, hosted by Heavybit members Paul Biggar, founder of CircleCI and Edith Harbaugh, CEO of LaunchDarkly.

In this episode of To Be Continuous, Edith and Paul are joined by Sean Byrnes, CEO of Outlier.ai, and Nadia Eghbal. The group discusses open-source economics and examines several potential evolutions of adding money to the open-source equation.

[soundcloud url=”https://api.soundcloud.com/tracks/257873002?secret_token=s-fHPo1″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

Edith: So, Nadia what do you like best about open source?

Nadia: I like that open source is where I feel I spend time with a lot of creative people. It’s sort of like creative talent at its best. And it feeds directly back into the rest of startups and technology and everything else that I love.

But it seems like everything starts with open source. Which makes it really magical.

Edith: So Sean, what do you like best about open source?

Sean: It’s the community. I enjoy learning from other people. I enjoy being able to find people I would never connect with that I have interests in common with. And a community that helps, because I consider open source to extend beyond just writing lines of code to sharing ideas, and sharing concepts and sharing solutions to problems, and while I might not always use those same solutions, I’m always inspired for new ways to solve other problems.

Paul: So that’s super interesting, because nobody said that they like how it supports their Silicon Valley startup through sharecropping. Or … nobody said, I like how I get paid to work.

Edith: Well, Paul, that comes later in the episode, but this would be a great time for our guests to introduce themselves.

Nadia: I’m Nadia Eghbal. I’ve been writing recently and thinking a lot about how to support open source infrastructure.

Originally, I have background in nonprofits and impact investing and working with foundations but most recently I was a founder of a startup and then I went into venture capital. And have sort of seen the system from all different sides and would love to marry together all those different interests and topics in which seems to happen in open source.

Sean: Hey, I’m Sean Byrnes. I’ve been writing software most of my life. I’ve also been a founder of companies and an investor. I would not consider myself an expert on open source and I don’t wanna claim that pedestal but I have, am, the maintainer of some open source libraries which seem to be pretty popular and I have contributed to others and I think that I’ve been lucky enough to know a lot of open source developers in my life which is, by no means, a majority of them but enough that I feel part of the community, at least.

Paul: So, one of the topics that we were discussing just before the show started, is this idea of how open source developers get paid. Or, if open source developers should get paid.

Nadia, sounds like you’ve been talking about this for a while or thinking about this for a while. Can you kick us off?

Nadia: Yeah, actually, have a new thought on this topic from Michael Rogers whose, who runs Node.js Foundation. And he said recently, I think, on the last post I had written that everybody gets paid for open source. And I think that’s a really great way to start thinking about it vs. saying that nobody gets paid. Because in the end we’re contributing time to open source, right and in the end, somebody is paying you to have the time to work on open source.

Whether it’s your employer and then you can work on open source full-time at your job. Or you’re full-time employed and that gives you the bandwidth to be able to work on open source on the weekends or whatever.

So when I think about paying people to work on open source, I think people sort of like, bristle at the idea because they think that money is not involved in open source at all. And what I really liked about Michael’s point is that, in the end, money is actually really closely tied to open source and we’re just not talking about it.

Sean: I get it. It’s interesting because my point of view is that it’s actually more nuanced, I agree with you 100 percent but I think that it’s very nuanced and that a lot of people do get paid for open source, it’s not even that we aspire to wanting them to get paid, right. ‘Cause there’s lots of kinds of open source. It’s funny ’cause on Medium, Nadia and I had an exchange.

I kind of quantified it into the four categories of open source the way I see them. Which is by no means the universal standard but at least, how I see the world there, there are places where open source is part of your, a corporate product. It’s part of a whole.

Like, LaunchDarkly. Edith’s company, has open source SDKs. It’s not because they’re doing anything grand, it reduced their sales friction if their customers can see the code before they integrate it into their app, right. So that’s one kind of open source.

A second is what I call corporate open source, where there’s an open source project but there’s a company that sells services and products and stuff around it, right. So Confluence does that for Kafka. And Databricks does that for Spark. And MySQL was, I think, one of the first companies to really make a good model out of it. Red Hat, you could argue, had mixed success but that’s another kind where there’s a company whose corporate goal and sales is towards this project.

There’s the third kind which I call, kinda like corporate marketing, which is you take a project out of a company and you roll it out like LinkedIn did with Kafka, where they’re actually, the company’s maintaining it they just make it available. So Google, the Angular and Facebook work react. And again there, I think, that it’s. You could argue why companies do this, some of ’em do it for recruiting, some of ’em do it for marketing. Some of ’em do it for because they’re very nice people.

I think that the fourth category is where it’s a little bit weirder, where it’s like, what I call the community where somebody started a project. Maybe it’s an individual, maybe a few people, to solve a problem. And a lot of the most important open source products today started that way. Even Linux started that way, right. And it grew, and it got bigger, and eventually, then it became unclear because other people were using that project to build other companies and build other products, and make more money.

And I think in that fourth category is where I think it’s less, because the first three categories is usually pretty clear who’s getting paid to do what and where the money’s coming from, but in the fourth category it gets very muddied and very quickly. Because if I start something, and the metaphor I like to use is, the open source library that I wrote was something called Likely.js which is a recommend ender system for no JS where you can, like Amazon product recommendations. And I know that there are people in the world that are using that as part of companies. And those companies are obviously making money because it to recommend products, right. And so, the question is, you know, so in that world, do they owe me anything for creating that which is underlying their products? And then, in turn, what do I owe the projects that I build Likely on top of? And then where does the flow of economics in that world go?

Paul: So I have an interesting view on that. Years ago, I got involved in this project called PHC, which is a compiler for PHP. And there was a couple of guys who had start this and I joined a year later. And when they started it, they made it GPL. When I joined, I argued, we should change from being GPL to BSD because if someone comes along and uses that technology to build something that’s cool, I would rather that happen than not now happen and it might be that if was GPL that it wouldn’t happen. And so that, essentially, in sort of the kinda related to Likely.js you decided by the license.

Whether or not you were going to make it publicly available or if you didn’t want people to build business on it, you could’ve made it GPL or AGPL or something along those lines and you could’ve restricted it in any way that you wanted and you chose not to. And there’s something implicit in that, that communicates to people who are building their companies on it, etc., as to what your intent was.

Sean: No, that’s true. Although there’s a nuance in there which is that, even the GPL suffers from this, what Richard Solomon still complains about today which is, you could still use Likely.js on a server.

Paul: Right, right, right. Well, so AGPL would work around that.

Sean: Sure, and there’s other licenses that I could choose, but the majority of licenses out there today but even then, let me argue counter side, not because I agree with it just because, hey, let’s argue because—why not! You know, as an individual developer, I don’t have the time resources to go pursue people. I’m not gonna go sue somebody. Really? No, come on, like it’s not gonna happen. So, I think, you’re right only in the act of releasing it as open source on GitHub. I was making a decision that it’s possible for people to use this in ways that may, either A, I don’t intend, they could’ve used on Silk Road to recommend drugs for all I know, seriously, right.

Or, to make money on it in ways that I am not gonna benefit from. And I made that decision knowing full well the impact of that. And I would actually argue most developers do that. The question is whether or not there’s remorse later on when it turns out, wait, I really wish I hadn’t made that decision, I can go back in time.

Paul: Well, I think this is a common thing that people create a thing and then they say, well, if this is popular, I could sort of keep it or I could, there’s value here. I could keep it to myself or I could keep the value to myself. Or try to profit from it in some way. But they make, what is essentially, a marketing decision. I’m just gonna release this, I’m gonna see what happens to it. I’m gonna see if it spreads and then if it spreads, I can then make a decision as to, as to what, how possibly I can make money out of this. Or I can get value out of this. But at that point, obviously, the cat is out of the bag in terms of people actually using the software.

Nadia: Yeah, I mean, I think it’s actually should start from the principle, like you said, of it’s really great when people, you give something away and then people can use for whatever they want. Whether it’s for a hobby project. Whether it’s for illegal drugs or whatever, you know. Businesses, whatever, that’s like, kinda one of the coolest things about open source is that you can use it for whatever you want and that’s kinda what you signed up for right.

If you didn’t wanna do that, then don’t license it that way. I don’t know, I wouldn’t frame, at least the problems that I’m seeing and that I’m interested in, is not really about seller’s remorse, I guess of, “Oh, I made this thing and now it’s really popular and how can I make money off of it.”

But I think it’s more really about investing back into the infrastructure that we’re all using and that requires some sort of maintenance and upkeep. And that’s why I like the term infrastructure and I’m trying to use it in that sense of things that don’t have a business model or business attached to it. Like you, literally, could not charge for Python. It’s just not gonna happen. Or the packaging associated with it or whatever, but still like millions of people are using it. It’s touched billions of people. And you literally have like one person working on a library or a project, that doesn’t seem, that seems like it’s in everyone’s best interest to make sure that it works properly.

Edith: Well I think Nadia made a really good point that a lot of the fun of creation is the creation. And the hard work is all the maintenance and the support and the documentation after. So like, Sean, you basically got the fun.

Sean: Oh, totally. Well I mean, if you even think back to the original “The Cathedral and the Bazaar” essay from years ago, that was one of the fundamental topics of, you know Eric was inheriting, I think it was called Pop Mail from somebody else.

He had gotten tired of maintaining it and so he wanted somebody to take it over and he found Eric and Eric took it over. I mean, that’s, you know, I think, yes, as engineers we like creating and we like creating things in our free time and we don’t like maintaining them as much and maintenance feels more like work.

And so, I agree with Nadia’s point that if everybody is driving economic value from it somebody has to be willing to step forward to support it. I think the problem is that I also, it’s funny that you have a background in nonprofits because I also have worked for nonprofits and I see the similar lament in nonprofit companies.

Which is that—not nonprofit companies, nonprofit organizations, where the person who starts it usually really wants to solve this problem, they’re usually really good at that. They’re not good at the fundraising

And in this case, the nonprofits, it’s like raising grant money or getting donations. But they have a good mission and they have a good organization to go do it. And they have this lament which is why can they not get more support to solve the problem they see in the way that they wanna solve it.

And I see the same around maintainers of open source projects and I think the challenge is going to be that I wonder if it is even possible for the general economy to support them, to do what they wanna do, the way they wanna do it. Or if they are gonna have to start doing it the way the general—

Paul: Right, because they have other options. They could start a consulting company. Get hired by a category two company or something like that. To build around it and support themselves that way and then their job doesn’t, then their job isn’t what they wanted their job to be which is making cool software. Their job is, you know, doing maintenance contracts for a big soul-less enterprise.

Edith: You say that like it’s, I mean, soul-less enterprises, I mean …

Paul: I’m a big fan of soul-less enterprises. But I’m just looking to sort of put the—

Sean: They have a lot of money. We have to sell them.

Paul: And if any soul-less enterprise would like to buy CircleCI they should contact me for enterprise pricing.

Sean: Just mention the code OSS for 10 percent more.

Edith: And by the way, thank you for wearing your LaunchDarkly t-shirt today, Paul.

Paul: Always. So, Nadia and Sean had this conversation on Twitter a week ago which led to them being on the show. And one of the Tweets that got involved was from a Jacobian who’s one of the senior Python kind of people. And what he said is, OSS developers deserve to be paid. SV, Silicon Valley, has made massive profits by exploiting free labor. This needs to end.

And I think that there is this, this feeling in open source by, at least by a lot of people who end up on the maintenance side of things that, there is a sort of a sharecropping going on here. And that’s something needs to happen about that.

Edith: I think Nadia actually put this extremely well in the essay; like cool, I wish I had written that essay, it was brilliant.

Nadia: Aww.

Edith: But just like, what’s really fed this is the explosion of GitHub and it’s really easy now to start an open source project.

Nadia: Yeah, I feel like right now is just a time when we’re so used to thinking of open source in a certain way and things have kind of gone along as they have for so long that we haven’t necessarily noticed or taken a step back that the past five years look completely different than the past 30 years. And stuff is just not the same anymore. And in part, I think it should be framed as a really good thing because it means that open source kind of won, in a way.

Companies want things to be open source. They wanna learn how to open source their own projects. They wanna understand the whole thing. Everybody is defaulting to open source and that’s a really positive thing and the question is more of, not like, oh, we’re exploiting people and that really sucks but how can we help support that underlying layer that has helped make everything so great. It obviously needs some sort of reinvestment back into it.

Edith: Yeah, I mean, one of the most fascinating thing about “The Cathedral and the Bazaar,” which was written 30 years ago, is that they referred to Linus Torvalds as this charming guy. Yeah, I know, and you’re like wow, here’s this charming, personable guy who like persuaded people through sheer force of will to work on his project.

Sean: Yeah.

Edith: I mean, to go back to Sean’s example about a nonprofit and everybody in the studio right now is like, whoa, that’s not …

Nadia: Not at all.

Edith: By anybody’s perception now, and I don’t know whether that’s just the grind down of having to keep maintaining a project or …

Sean: First, I’d like to thank, I don’t know if his name is actually Jacobian, whatever it is, thank him for his service and work on Python ’cause I think, no matter what we agree on here, we can all agree that the people doing this are doing a service for the general community.

Nadia: Definitely.

For more on Continuous Delivery and to hear other Heavybit podcasts, copy this link into your favorite podcast player. We’ll have show-specific RSS and iTunes subscription options soon. You can also follow To Be Continuous on Twitter at @continuouscast.

April 13, 2016
Changing Compensation Before it Kills Success

Have you ever seen the sign, “Will work for food”? If you deconstruct the premise a bit, we all work for the rewards systems that interests us. We “trade” our labor (ideally, focus our passion), for a set of acknowledgements that range from survival to pride. And ultimately it is our employer (whether the boss or the board of directors) who decides what our rewards systems will be. That is the common sense part. But when something such as DevOps enters the picture, it alters traditional thinking throughout an organization, and the ripple effects should (and eventually will) reach the HR department.

The most immediate effect of DevOps on HR occurs around talent acquisition. Finding a qualified DevOps engineer that it is possible to afford—and the company can retain—becomes the unicorn of recruiting departments from one coast to the other. The alternative is creating or adopting a training curriculum that can move a traditional programmer or engineer into a fully qualified DevOps engineer. Of course, advice varies on exactly what that is, and if it’s successful, your organization becomes a feeding ground for every other competitor to poach your folks right after training.

Because this HR acquisition problem is so great for most organizations, they can overlook some other underlying issues that continue to occur. These problems have always been there, but DevOps brings a spotlight to them that did not exist prior to its implementation. As stated earlier, we “do” what we are “paid” to do. In organizations that innovate in the software discipline, we have always “paid” that entire division to innovate. Prior to DevOps, the pace of that innovation, was slow and manageable. Once DevOps begins to take hold, the pace of innovation begins to enter the 400mph superhighway, where traditional control mechanisms no longer work.

In itself, the success of the controls over change—transitioning to a high rate of speed—will be determined by how we implement DevOps. It is the other half of DevOps that needs some focus. While our Dev organization is cranking out change exactly as we have always paid them to do, our Ops organization traditionally has been paid for exactly the opposite characteristic. We pay our Ops organization for stability. We want the trains to run, on time. We do not want a 2 a.m. phone call from an angry CEO—or, much worse, an angry customer—because our operations have “broken.” And, of course, the No. 1 culprit for causing breakage in operations is … [drum roll, please] … “change.”

In the yesteryear of Waterfall construction and manual delivery, our Ops teams had time to digest what change was coming, prepare for it, adjust to it and get it implemented smoothly (or at least pretend to). In the current day of Agile construction and DevOps delivery, I might have moved six new builds into production in the time it has taken you to read this article. Ops has no time anymore to digest and prepare for change, so if the quality of that change is not significantly better than it used to be, the angry-phone-call potential goes up exponentially. And yes, there are technical remedies to ensure quality (I will reserve discussing those for another time).

But the tradition of how we compensate remains in place. We comp Dev to innovate, and we comp Ops to remain stable. This makes not only silo thinking, but also mortal enemies during the adoption of DevOps into an organization. All of a sudden, each views the other as potentially causing harm to their ability to continue earning compensation. And they are right to see it that way, as HR has yet to alter the models to create partnerships instead of combatants.

To fix this, the compensation models must be adjusted to pay Ops teams to get involved in the software development lifecyle (SDLC) process from the upfront. The Ops teams should have extensive visibility into the testing cycle of new changes and how that works, and become the organization always asking Dev how it can “prove” its change works. The Ops teams must become the in-process auditors of the Dev teams. This keeps the Ops teams from being compensated for conditions that only exist at the end of the SDLC process, where they feel “dumped-on” by more rapid change delivery. The new comp model for Ops must focus on the number of changes successfully introduced into the production environment (i.e., the quantity of change that works), not just the stability they traditionally maintain.

The Dev team, on the other hand, must begin to be compensated only for after-action success. Dev teams must look at their code after delivery to production—and only if the code is validated (i.e., it works), is adopted by its intended customers (a completely different angle) and performs within expected timing parameters (i.e., it scales well). This becomes the criterion that is the foundation of the Dev team’s measurement of success. This puts an Ops set of glasses on the programmer instead of making him blind to those business issues. The Ops teams become the key advisors to the Dev teams on how to prove quality. And the joint discussions lead to a more sensible monitoring strategy, which is needed across the board.

There’s Compensation, and Then There’s the Bonus

Changing the point of view for the compensation is only a start. Next up: Begin to alter bonus compensation to a more lean model. Instead of large annual bonuses, where the basis for achievements often are colored by my boss’s mood over the last six weeks, organizations should increase the frequency of bonus payouts to match the duration of epic completions—or, if possible, of sprints. The idea is to tie meaningful bonus payouts to the length of time it takes to produce only successful change. If the change works, the company offers additional bonus comp; if not, then the team must improve to secure the next bonus opportunity.

Tie the bonus duration (whether to epics or sprints) to meaningful business impacts. In this way, each contributing employee understands “why” the work he or she offers has meaning to the company or its customers. This kind of bonus system allows for extreme flexibility in the priority of what teams work on throughout the year. Bosses can change priorities or shift them to match what executives see on the horizon. Employees are not tied to some list of annual work accomplishments that in a DevOps rapid world they had little shot of achieving unless they did them in a week. Instead, they have real-world goals, tied to real world time frames, where employees see the reward as they succeed at the work.

Organizations can add even more bonus comp this way if over-and-above work is needed. And “if” organizations compensate both Ops and Dev only for successful change (which implies quality in the SDLC and stability in Ops) they create a new rewards system that enables adoption rather than repel it. Beyond finding the talent they need, organizations need innovative methods of retaining them. Substantial rewards in real time might just be one way to do that.

Finally, being able to see the business impact of the change the joint effort of Dev and Ops teams produce allows for better ability to offer “appreciation” ideas as well. A simple “thank you” goes a long way in employee satisfaction, and when the executive and the team member understand “why” they are being appreciated, they go even longer. DevOps is not just a catalyst reserved to the “techies” who practice it; DevOps is instead a new way of thinking about how a company innovates. This kind of infectious thinking can easily spread to tertiary support organizations such as HR and Legal, if you let it.

To continue the conversation, feel free to contact me.

April 12, 2016
3 Tips to Shape Human Behaviors and Achieve Your DevOps Goals

DevOps raises many questions around processes and technologies, but it is important to remember that people are the essential piece that makes DevOps work. Since my post on Generalists vs. Specialists here on devopsy.kinsta.cloud, I have had many questions about shaping human behaviors, like this one:

Q. How can I help my team build up the attitudes and behaviors we need for our DevOps team?

In an industry often dominated by technical advancements, flashy applications and an ever-changing “next big thing,” it’s probably not surprising that the human aspects behind them usually fly under the radar. That is changing with DevOps, but there is a need for prescriptive advice on how to encourage a ‘DevOps attitude.’

This question then is typical of many looking for specific steps to help shape the human element of DevOps. So here are three approaches to help you encourage DevOps behaviors to be successful.

1. Connect Individual Job Duties to Higher-level Business Processes and Goals

In traditional environments, staff are often only concerned with their silo, not the overall process. They may fulfil their duties within their silos – writing code, testing release, maintaining stability – without ensuring the whole process contributes to the ultimate business goal, which is really the whole point.

By contrast, DevOps treats the SDLC as a value chain in which discrete activities (designing, coding, testing, etc.) occur in a complementary fashion to add value to the final deliverable – a production application. Traditional value chains have taught us that optimizing at the individual activity level can only get you so far – true evolution happens when you optimize at a higher, end-to-end process level.

I have posted before about encouraging a ‘big picture’ view of enterprise DevOps, but sometimes this is not enough. To take this a step further, you should directly connect the job duties of each team and each individual to the business goals, and hold them accountable to hit these goals.

2. Update Compensation Plans so They Align with Your DevOps Strategy

Speaking of accountability, one of the best ways to shape staff behaviors is to align rewards with desired end-to-end goals. Tying compensation to the entire team’s ability to accelerate delivery of high quality services, each individual will bear responsibility for all aspects of the SDLC. Not only does this provide ample incentive to embrace change, but it also gives staff a clear direction and specific goals.

This contrasts with a silo-based approach with, for example, a developer rewarded only for release speed, so they pump out code as fast as they can, regardless of defects; or an operations silo rewarded solely for stability, which encourages them to delay release in case new code breaks something.

Of course, pay is not the only compensation that motivates great dev and ops teams. So don’t forget other rewards, like training, conference tickets, new projects, team activities, or new responsibilities.

3. Technologies and Tools Will Help DevOps Staff Excel

When trying to model behaviors, it is important to remember that technology can help. For example, if your goal in adopting DevOps is to compress software delivery to meet a shorter timeline, you can’t just expect people to work harder, faster, and/or longer; you’ll need to help them with shared technologies that let your people work together better and smarter, not just harder.

For example, service virtualization relieves the need to build up physical test environments for every new code release, so dev and QA can build better code, test more, and improve quality. Release automation relieves of the need to manually release new code into production, so development and operations can focus on improving code quality and architecting for scale. Plus, both teams end up going faster, with fewer errors cause by human intervention.

Beyond specific tool selection, make sure your entire DevOps team is trained on their use, so they can all contribute by working smarter and better to achieve the company’s goals across their silos. This cross-skilling and shared responsibility helps to ensure the collaboration, communication, and integration of people that is an essential part of a DevOps approach.

December 2, 2014