devopsy.kinsta.cloud

Category: DevOps Open Source

  • Majority of Open Source Devs Open to Change Jobs in 2022

    Majority of Open Source Devs Open to Change Jobs in 2022

    Open source is the foundation of most modern software applications. Now more than ever, retaining developers with experience working on and with open source projects is critical to maintaining software development agility. Yet amid the Great Resignation, it can be challenging to keep talent happy—organizations must demonstrate a commitment to employee benefits, mentorship and cutting-edge technologies to remain competitive.

    The EDB Open Source Talent Survey 2022 surveyed over 1,400 developers and DevOps professionals working on open source projects. Below, we’ll highlight the key takeaways about their volume of work, the quality of on-the-job training and top motivators that could influence workers to take a job elsewhere.

    The Great Resignation Persists

    It’s not news that IT is under mounting pressure to deliver new features and applications to meet surging digital demands. As a result, the amount of work has increased across the board. The report found that 67% of respondents said their volume of assigned work has increased in the past 12 months.

    Employer favorability has also declined slightly—28% have a less favorable view of their employer over the last 12 months. Although 46% are satisfied with their current job, 44% are satisfied but would be open to new opportunities. And 10% said they were not satisfied with their current position. Taken together, that means 54% are open to or actively looking for new roles.

    Mentoring: An Enticing Benefit

    So, what are the main drivers that would influence IT workers to change jobs? It’s no surprise that increased pay and benefits are a top reason behind most resignations. However, salary is not the only factor—43% say improved career opportunities influence a job shift, a steep rise from 21% in 2021.

    On-the-job mentorship and training are also becoming more desirable. A little over a third (38%) said that better access to mentorship would make them consider another job opportunity. This was followed by working with more cutting-edge technologies (32%), greater access to training and certifications (30%) and allotting more time for open source projects (19%).

    Interestingly, one-fifth of responders who said they were satisfied with their current employer said their organization introduced a mentoring program in the past year. This indicates that investment in employee career advancement helps increase morale and retain skilled workers.

    Career Advancement And Training

    Out of the above reasons developers are open to switching jobs, one factor in particular is increasingly important: Working with cutting-edge technologies. This figure doubled in the last year, rising from 16% to 32%. Most engineers prefer not to work with cumbersome legacy technologies or manage rising technical debt. And if an organization isn’t evolving its software infrastructure, employee skillsets become stale.

    Working with new open source or cloud-native technologies can help retain workers, but will likely require training. In terms of specific categories, 41% said that training in emerging technologies, like cloud, is a favorable factor in considering another job opportunity.

    From a security perspective, ongoing training is also vital to staying on top of emerging exploits. As a result, 43% said security training is an interesting perk when considering a job shift. These areas are followed by training on core technologies like database and infrastructure (38%) and training on compliance (37%).

    Final Thoughts

    Open source software is pervasive and at the heart of today’s digital innovation. Nearly all applications depend on some form of open source software, but it’s no less prevalent in the DevOps sphere, where open source projects are used in continuous delivery, container orchestration, observability and a multitude of other stages of the software life cycle.

    Supporting the needs of skilled labor will be necessary to leverage the benefits of open source projects. As such, organizations will require not only competitive wages but also relevant training and investment into cutting-edge technologies to retain such developers.

    Another factor that could drive workers away is unnecessary toil, which can negatively affect morale. A company’s environmental, social and governance (ESG) initiatives can also affect its talent pool. Furthermore, a commitment to high-quality developer experience can ensure the needs of developers are heard and respected.

    The EDB Open Source Talent Survey 2022 surveyed over 1,400 application developers and IT professionals from around the world. It targeted open source technology users, specifically those holding application development, information technology and operations titles. For additional insights, you can read the full report here.

  • Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    The Log4j vulnerability got me thinking: Is there such a thing as too much open source?

    Before anyone immediately fires off a flaming email, rage tweet or scathing blog post, hear me out for a moment. If you know me, you know that I am an open source fanatic. I’ve been asked many times, “Should we use open source software and, if so, how much?” My response was (and still is) that open source software is a massive source of innovation and I can promise you, whether or not you use it, know that your competitors certainly are!

    I could go on and on extolling the virtues of open source and how it enabled the cloud, reshaped software architectures, created new product categories and gave us valuable tools like telemetry and increased visibility into cloud-native apps, infrastructure and beyond.

    When I first heard about the Log4j vulnerability on December 9, like many others, I quickly informed the tech leaders, engineers and SREs in my network about the serious potential risks such a zero-day vulnerability in the widely-used Log4j tool represented. In one way—probably the only way—the Log4j exploit shared a very important characteristic with the SolarWinds supply chain attack of late 2020: The widespread distribution and ubiquitous use of the software across applications, systems and organizations. Arguably, Log4j is used much more widely.

    This similarity raised questions I hadn’t fully considered in the context of such widely used software. Can we use too much open source software? Is Log4j too prevalent in its use and, therefore, a single point of failure? How bad would the Log4j situation be if a fix wasn’t immediately available or if one wasn’t forthcoming?

    The answer I kept coming back to is a resounding ‘no’. I still don’t think there’s such a thing as using too much (insert any open source project name) software. Log4j—and so many other open source software projects—are massively beneficial to us, and we virtually couldn’t function without these systems, tools and solutions in today’s age of ubiquitous software.

    What the current Log4j vulnerability, recent software supply chain attacks and other cybersecurity incidents with widespread impact highlight is our need to quickly respond to security incidents and take remediation steps anywhere they are found in the software stack. And that includes open source software. High-impact security vulnerabilities can occur anywhere across the numerous software stacks and services we use, though they have even greater impact when they occur in widely-used infrastructure, reusable components and microservices.

    In a world of infrastructure-as-code (IaC), it’s no longer a matter of patching a particular set of routers or servers. Unfortunately, much of the software stack is not containerized or built using smaller, easily replaceable containers and microservices—at least not yet. Our mindset and processes going forward from this incident must change, and we have to be prepared to respond to and remediate vulnerabilities both horizontally and vertically across the software stack. In certain circumstances, we have to do this on a large scale.

    As is common with active open source projects, Log4j contributors responded quickly with a readily available fix. The real answer to my original question above is that few are as prepared to respond to an important security vulnerability as those incredible, hard-working, active and engaged open source software developers.

  • Is Open Source More Secure Than Closed Source?

    Is Open Source More Secure Than Closed Source?

    There’s no getting around the fact that security is one of the most essential factors in day-to-day operations for most software developers. From proprietary code to sensitive customer data and everything in between, there are hundreds – if not thousands – of crisis scenarios that can result from gaps in security.

    Data security is an issue that every company faces, no matter how large or small. Developers look for security solutions that follow today’s data and application security best practices in order to reduce risk and provide the most secure experience possible to the end user.

    A common debate among both users and developers is whether open source software is more or less secure than closed source alternatives. While there are a variety of different schools of thought as to what makes for a truly secure environment, there is good reason to believe that open source software is the superior option for those looking to prioritize security.

    While open source code may not be inherently more secure than its closed source brethren, here are a few reasons why it almost certainly can be — so long as you take the right approach.

    Open Source Offers True Transparency

    Both well-established tech giants and up-and-coming startups work with some of the brightest minds in the development community to bring valuable proprietary software products and services to market. At the end of the day, however, users have no choice but to trust what a vendor says about how a particular piece of software actually “works.” Since you can’t see the code itself, there’s no way to really verify whether or not what you’re being told – about features, functionality and security – is accurate.

    This can be problematic for a host of reasons—not least of which being the threat of potential security flaws. A company might boast about its commitment to user security and privacy through savvy public relations and product marketing efforts. But, by no means does this provide the user with anything more than lip service if the code doesn’t measure up; even if it’s rock-solid, the question of “How truly secure is this?” can never be answered with confidence.

    Open source software offers greater transparency to the teams that use it; visibility into both the code itself and how it is maintained. Giving organizations access to the source code allows them the opportunity to evaluate the security of the code for themselves. Additionally, users have more visibility into how and what changes are made to the code base, including the pre-release review process, how often dependencies are updated and how developers and organizations respond to security vulnerabilities.  As a result, open source software users have a more complete picture of the overall security of the software they’re using.

    Open Source Encourages Community Input

    Another major benefit is found in the communities which drive the growth and development of open source software. The vast majority of open source software is backed by communities of forward-thinking developers, many of whom use the same software they build and maintain as a primary means of communicating with team members. Open source developers and the communities around the software value users’ input to a significant degree, and many user suggestions end up getting incorporated into new versions. The community involvement and investment ultimately leads to many more responsible vulnerability disclosures than would likely occur if the software was closed source.

    When vulnerability reports do occur, they tend to be more detailed because the code is open source; often, they even come with code suggestions for how to remedy a given issue. This is incredibly helpful and can dramatically speed up patching the vulnerability, as it allows developers to move faster without spinning wheels and getting stuck in the diagnostic process.

    Faster Security Updates

    Within the framework of closed source software, users are at the mercy of the companies behind those products or services when it comes to receiving software updates―open source tends to be a different story. Fully open source projects even allow users and developers to take things into their own hands and contribute feedback and fixes, should they choose to do so.

    More often than not, updates and fixes for high-profile closed source applications involve a great deal of complex planning. If it’s not in the budget, for example, users may not see a new update for weeks, months, or even longer—security flaws or not.

    In most circumstances, open source tends to move faster than closed source when it comes to iterating and releasing new versions. This is true for a handful of reasons, including the fact that open source software tends to have more eyes on the source code at any given time, as well as a community-driven interest in bettering the product whenever possible. If a significant security flaw is uncovered, users may even choose to fix the code themselves, resulting in a level of control that can never be achieved in a closed source environment.

    Open Source Offers Flexibility, Collaboration and Enhanced Security

    An open source methodology, in and of itself, is no guarantee of security, but it does offer teams greater insight and control over the software they rely on. And as open core and source-available software are more broadly adopted, they offer a wealth of opportunities to build incredibly secure environments without sacrificing usability for end users or support from official maintainers.

  • The Benefits of Open Source Technologies

    The Benefits of Open Source Technologies

    Over the last 20 years, we have seen the proliferation of open source software and technologies become part of commercial offerings, either as part of the technology stack that powers the product or part of the product itself. Although these two use cases are largely different, both have come to showcase just how useful open source is, not only for the developer community but for businesses as well.

    One of the benefits of working with open source technologies or projects is the free sharing of ideas. Open source brings people together to brainstorm and develop a common piece of technology. The shared love for what they do crosses cultural and geographical boundaries. One of the best-known – and arguably, most important – open source projects is the Linux kernel and operating system. Linus Torvalds released the first version of the kernel to the open source community through a mailing list, sparking worldwide collaborative development and widespread adoption.

    The passion for open source stems from a deeply rooted belief that contributors are solving an important problem, and that they are working towards the betterment of the world as a whole. In many cases, this is demonstrable. The Linux kernel now powers the majority of data centers worldwide, serving billions of users. But it’s not only that subjective passion that has played a key role in establishing open source technologies. The peer-review process of open source projects means that each code commit passes a rigorous, public audit and verification process. It has proven to be a superb way to increase code quality, reduce bugs and regressions and guard against vulnerabilities. Research has shown, objectively, that this process produces higher quality software than the standard, proprietary quality assurance and testing procedures.

    When selecting an open source technology to use in development, there are a couple of issues that need to be considered in order to safeguard the quality of your product. One key consideration is to resist chasing the latest technology fad. Instead, select the right technology for the job. It’s in developers’ DNA to obsess over new and exciting technologies, but this does not always mean that they are appropriate. While Kubernetes may be the right solution if you need to serve millions of users at Netflix-like scale while managing maintenance and cost, it likely isn’t the best choice for a new startup launching the first iteration of their product. In this case, speed of development and flexibility to make changes is more important than scalability (so, perhaps, the startup might be better off using Ruby on Rails or Django). These three projects all share an important characteristic: They have active communities that not only safeguard project features but also maintain them and offer peer-to-peer support.

    When implementing a new feature with a particular technology, this supporting community is very important, since they can greatly accelerate the development of your product. These are people who love what they do and want to see other community members succeed with the technology. In this regard, it’s also important to consider giving back to the projects and communities you benefit from. You can either participate in the communities and help others yourself, one-on-one, or contribute by sharing the improvements that you have made to the open source technology. If you have extended the API, for example, or discovered and fixed bugs, there is no reason not to contribute your changes back and further enrich the ecosystem. The credibility you build in this way can also be a benefit, as people will identify you, your team and your product as supporters of the open source project. It’s a virtuous cycle of collaboration with benefits that should not be underestimated.

    As you and your product become an important part of the open source ecosystem, either because you use open source components or because the core of your product is open-sourced, remember that trust is notoriously hard to build and very easy to lose quickly.

    Whatever one’s feelings are on this matter, the open source community is very careful about who they trust and can easily be alienated by a company that appears not to have their best interests in mind. In order to build trust, it’s important for teams to build credibility. Open source communities are largely merit-based, so unless the community sees proof of expertise and knowledge, they will not automatically trust a self-proclaimed expert. This credibility can even extend to the personal, like the many open source developers who have a large following on social media and lend their credibility to the projects and companies that they work for.

    Finally, when dealing with open source technologies, projects, and communities, it’s key to remember that developers are very sensitive to blatant sales pitches. Authenticity matters in the way that a project, company or brand presents itself. Open source is all about collaboration and community; it’s a relationship built on trust and mutual benefit, not profit.