Category: Features

  • The Cyber Resilience Act Threatens the Future of Open Source

    The Cyber Resilience Act Threatens the Future of Open Source

    The European Union (EU) is currently considering approval of the Cyber Resilience Act (CRA), a proposed regulation that is a major threat to the future of the global open source industry. While the intention of the act is to enhance cybersecurity (which is extremely welcome), its current form lacks clear liability exemptions for many open source developers and maintainers, which could be a death knell for open source in the EU and which could spark additional, global implications.

    The CRA regulation for the EU was proposed on September 15, 2022, by the European Commission. The intent is to improve cybersecurity and cyberresilience in the EU through common cybersecurity standards for products with digital elements. In theory, this is welcome. But there are some notable areas that many open source developers and industry organizations are concerned about.

    Modern applications are comprised of 90% open source code; penalizing open source developers would lead to a fragmented community and hinder important projects across various sectors, including critical infrastructure, health care and even military systems.

    The seemingly purposeful omission of exemptions for open source would put undue onus on open source foundations and maintainers and poses a serious risk to not just EU innovation and security but global collaboration. Something we, and many others in the industry, have tried to raise awareness about over the past six months. Unfortunately, the EU has largely ignored the industry’s voice. Holding open source developers whose components end up in commercial products liable for security issues will stifle innovation and harm the EU economy without providing a substantive improvement in security.

    This legislation is slated for a vote on July 19 in the parliament’s Industry, Research and Energy (ITRE) committee, where it will then be sent on to the full parliament. And, if nothing is done, it could be adopted without even a vote in a plenary session by the Parliament itself. I feel strongly that if the open source industry doesn’t take a stand now, it will become law and the open source community as we know it will be no more.   

    There are two main problems with the proposed CRA: It discourages commercial support of open source and imperils vulnerability disclosure.

    CRA Discourages Commercial Support of Open Source

    The revised CRA offers new cybersecurity requirements for hardware and software products, much like the U.S.’s National Cybersecurity Strategy does. It calls for software vendors and producers to understand what components are in their software and to be able to recall software that is affected by a vulnerability. But, unlike the recently released details for the U.S. strategy, it seems to be trying to call out certain open source projects from foundations and large companies. By doing so, it potentially impacts every open source project, which creates a web of issues.

    It goes without saying that open source projects rely heavily on volunteers, individual contributors and small teams who often work without significant resources or financial support. The support that foundations and contributors do get often comes from commercial entities who have adequate resources to provide developer time to give back to the community.

    The current CRA text only excludes OSS software that has no commercial activity around it. Unfortunately, it defines commercial activity in part, this way:

    “where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.”

    This can be read to mean that if the main contributors are not unemployed, then the project is commercially tainted. It does not clarify what was probably intended—that the employer fully controls the project here.

    Additionally, it says:

    “Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.”

    The first part is acceptable, but recurring donations from commercial entities are the upside of contributing back to open source. This may force the projects to reject large contributions to avoid becoming “tainted,” and will likely cause commercial entities to enact further bans on OSS contributions and pull their support entirely.

    Further, if the CRA is passed without proper exemptions, these developers and maintainers may face legal risks and liabilities for vulnerabilities found in code used in commercial products. The OSS developers have no visibility into how and in what instances their components are used; only the final manufacturer of the product has this visibility.

    The potential legal risk, without an upside, would discourage OSS developers from contributing to and maintaining open source projects. This situation not only undermines the spirit of open source but could bring about an open source crisis and isolate the EU from the rest of the world. Non-EU open source producers will avoid the EU market, meaning no access to Linux, Apache, Kubernetes and many other projects. Repositories like Maven Central, npm and PyPi may be prompted to ban EU consumption to avoid being considered a distributor. EU projects concerned about liability could pull their source code off the internet, and EU businesses may be forced to halt contributions to open source projects.

    CRA Imperils Vulnerability Disclosure

    The regulation also would require that vulnerabilities be disclosed to the European Union Agency for Cybersecurity (ENISA) within hours of discovery, whether or not a fix is available. This would make it difficult to conduct coordinated disclosure—where researchers give vendors time to develop security patches before vulnerabilities are disclosed publicly. This would increase the chances that bad actors will develop exploits for the vulnerabilities before they are fixed, putting every company that uses that software at risk. This would be an unfortunate outcome for a law whose purpose is to improve security of software.

    What Can we Do?

    As I mentioned earlier, time is of the essence since this measure is moving quickly and faces a vote this week. We need the community to take immediate action. GitHub and other industry bodies need to publicly oppose the proposed measure. EU developers, maintainers and others need to ask their European Parliament Members (MEPs) to investigate further and bring the voices of the open source community to the discussion.

    Legislators need to understand the importance of collaboration and the role of the global developer community in driving open source innovation. Open source projects underpin much of the software we use every day. It’s the lifeblood of the internet. Legislation that deters contributors would interfere with the open source community’s ability to maintain existing projects and deliver new software, impacting the tech industry, hurting the EU economy and compromising overall software security.

  • Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk today launched a platform for ingesting data from sensors, industrial equipment and internet-of-things (IoT) platforms so that it can be analyzed alongside data collected from IT environments.

    Announced at the company’s .conf23 conference, the Splunk Edge Hub extends the reach of the troubleshooting platform Splunk provides that increasingly involves various types of edge computing platforms.

    Tom Casey, senior vice president for products and technology at Splunk, said Splunk Edge Hub is designed to be deployed in those edge computing environments and reduce the total amount of data that needs to be transferred back to an instance of the Spunk analytics platform running in a data center or in the cloud.

    That approach makes it possible to remotely monitor everything from environmental conditions to identifying anomalies indicative of an outage that might be prevented. The overall goal is to unify visibility across IT and operational technology (OT) environments as these systems and applications become more integrated, said Casey.

    It’s not clear how quickly that integration is occurring, given the historic cultural divide that has existed between IT and OT teams. But with the rise of digital business transformation initiatives, the data collected from edge computing platforms is increasingly being incorporated into a wide range of applications deployed at the edge, in local data centers and in the cloud.

    In general, observability tools are being used to not only improve processes but identify and block suspicious activity. Of course, OT teams have been monitoring edge computing platforms for decades, but observability platforms make it feasible to interrogate logs, metrics and traces to hopefully discover issues before there is a disruption to services. The challenge, of course, is that not everyone on either the OT or IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue. The Splunk approach essentially leverages the skillset of IT professionals that have mastered its platform to address that issue; something most OT professionals are not going to be able to do using their existing tools and platforms.

    One way or another, DevOps teams will soon need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than responding after a metric that OT teams are monitoring has already exceeded its threshold.

    In the event there is still an issue, observability platforms should also reduce mean-time-to-remediation (MTTR) as visibility into IT environments, including edge computing platforms, is improved.

    It’s not likely that OT and IT teams will ever be completely unified, but as observability platforms continue to evolve, there will be much greater opportunities for collaboration.

  • State of API Report Highlights Productization and Generative AI

    State of API Report Highlights Productization and Generative AI

    In today’s software landscape, an API-first strategy is increasingly popular. It’s the bedrock of how applications are built and connected. APIs help promote internal tech reusability, helping developers do more with less. Due to this increasing API reliance, maintaining quality control is increasingly important for internal and partner integrations and ensuring the reliability and security of these connections remains a top priority.

    Due to the rising API ubiquity, nearly half of the total development energy is spent working with APIs. And to continually improve these interfaces, taking a product mindset is proving helpful. In fact, 60% of API developers now view their APIs as products. Generative AI has also shown incredible promise and is now being used in tandem with traditional tools to increase API code quality.

    Postman recently released its fifth annual State of the API Report. The 2023 edition, which surveyed thousands of developers and API professionals, found subtle changes in tooling preferences and styles. It also sheds light on the ongoing API productization movement and API developers’ use of generative AI. Below, I’ll focus on these two key areas and review the report for its other key takeaways.

    API Productization is Hot

    The majority of API developers now view their API as a product, and this figure rises to 68% in large companies. A full 65% of respondents said their API generates revenue, too. This news is significant, as it demonstrates the industry is maturing its view of APIs. They are no longer offshoot developer toys but fully functional services contributing to overall business growth.

    But how much growth? Well, of those monetizing APIs, 43% now say APIs generate a quarter of company revenue. For some companies, APIs generated more than 75% of total revenue! There also appears to be a parallel between API revenue generation and large companies.

    Do you view your APIs as products? Most developers say "yes."
    Do you view your APIs as products? Most developers say yes.

    Other industry reports unearthed similar API productization potential. Rapid’s 2022 State of APIs report found that 42.6% of organizations are now monetizing APIs. And investment into API-first products remains strong even amidst a broader contracted tech investment climate. These findings come as social media giants like Reddit and Twitter attempt to monetize their APIs.

    That said, for 28% of companies, API revenue still equates to less than 10% of total revenue. APIs still don’t get the lion’s share, perhaps because they’re packaged with an existing platform or because of the many other indirect ways APIs might benefit the business. Furthermore, consumers are becoming more cost-conscious, as 60% cite pricing as a factor before integrating with an API. Still, the numbers are significant firsts for the burgeoning economy.

    Most API Developers are Using Generative AI

    Generative AI interfaces like ChatGPT and Bard have certainly taken the tech industry by storm due to their ability to generate code snippets, debug code and more. And for the first time, the State of the API Report spotlighted generative AI and its use within the API economy.

    Today, 60% of API professionals are using generative AI on the job. API engineers commonly use generative AI to find mistakes in code, generate machine-readable code and increase learnability around their programs. Some even use generative AI to suggest potential security flaws in their APIs.

    Compared with other app development endeavors, developers are by far most excited about building generative AI-powered applications in the year ahead. Yet, the efficiency gains are modest—many engineers forecast productivity improvements of 10% to 25%.

    How are API developers using generative AI in their work?
    How are API developers using generative AI in their work?

    Generative AI is set to accelerate many areas, including DevOps and API operations. Yet, contrary to some headlines, generative AI can’t automate all aspects of the software development life cycle. Rather, the technology is more likely to augment the API developer’s workflow than replace the need for seasoned professionals altogether.

    Other Key Takeaways

    Similar to last year’s report, integrating between internal applications, programs or systems remains a top concern for integrating an API or producing an API. The good news is that these integrations continue to increase in quality.

    The report found that deployment failures and times-to-recovery are improving on average. More than half (56%) of respondents said API security incidents occur less than once a year within their organization. This shouldn’t overshadow the significant impact API security breaches can have but signals that DevSecOps is beginning to respond to persistent API vulnerabilities.

    There are more API-first leaders than ever before. And API owners continue to evolve how their services are built and deployed. For example, REST is still by far the most common API style, used by 86% of developers. Webhooks made second place at 36%. However, GraphQL rose in usage, bumping SOAP into fourth position.

    SOAP slips on API architectural styles
    REST is still the dominant style, but GraphQL makes gains as SOAP slips.

    Other Quick API Factoids

    • More non-developers are becoming interested in APIs, as evidenced by 53% of survey takers being non-developers.
    • Most APIs are private—61% percent of businesses’ APIs are for internal use only.
    • After the technology group, business/IT services, financial services and health care are the most common sectors to adopt APIs.
    • Microservices is still the dominant architectural style of APIs, at 42%.
    • Performance, security and reliability are the top factors evaluated when integrating with a new API.
    • Improper authentication, authorization or access control is the most commonly cited API risk.
    • Common API tools include Postman, SwaggerHub, Datadog, SoapUI and Insomnia. Top gateway and API management platforms include AWS API Gateway, Azure API Management, Apigee and Kong.
    • JSON Schema is by far the most popular API specification.
    • The financial industry is a leader in API-first strategies—32% of respondents spend more than 20 hours a week working with APIs.
    • Most developers deploy APIs to production once a week to once a month.
    • When developers leave a company, their departure can cause outdated documentation, zombie APIs and a loss of institutional memory.

    API Obstacles Remain

    Looking to the future, investment in APIs is projected to climb. In fact, 92% of developers said their organization plans to invest the same or more time and resources into APIs in the coming year. Yet, some obstacles remain—a lack of documentation and poor service discoverability are still prominent roadblocks to API consumption. Furthermore, a lack of time and talent are major concerns that might stunt API development.

    The Postman State of API Report surveyed over 40,000 developers and API professionals, making it the largest study conducted on APIs to date. It should be noted that, given Postman’s specific focus in the market and its surveyed pool, figures may be skewed to represent increased API enthusiasm. For deeper insights, you can read the entire report here.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Indeed.com

    ServiceNow
    San Diego, California
    Senior Software Engineer – DevOps
    $119,970 to $204,030

    LinkedIn

    Fox Tech
    New York, New York
    Senior DevOps Engineer
    $118,000 to $157,500

    SimplyHired.com

    GM Financial
    Arlington, Texas
    DevOps Automation Engineer III
    $113,000 to $143,000

    CareerBuilder.com

    Edward Jones
    Henley, Missouri
    DevOps Technical Architect
    $109,696 to $186,781

    Dice.com

    Suremind Solutions
    St. Louis, Missouri
    DevOps/Site Reliability Engineer (SRE)
    $100,000 to $140,000

  • Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    Forking RHEL! Oracle and SUSE Join the Fight ¦ Silverman Sues AI Firms

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)

  • JFrog Adds Curation Capability for Open Source Software Components

    JFrog Adds Curation Capability for Open Source Software Components

    JFrog today announced it is adding a curation capability for open source software to its portfolio that will use metadata generated by binaries to identify malicious packages and software components that have licensing issues.

    Sharan Hiremath, senior product manager for JFrog, said JFrog Curation is an extension of the JFrog Artifactory binary repository that the company provides to enable organizations to manage their software supply chains.

    JFrog Curation also validates software packages against JFrog’s Security Research library of recorded Critical Vulnerabilities and Exposures (CVEs) and publicly available information to help establish a trusted repository of pre-approved, third-party software components.

    That approach automatically employs the JFrog Xray scanning tool to eliminate the need to individually scan each package before developers employ them, said Hiremath.

    Making sure open source software components are secure is often problematic because developers download them from public repositories that are frequently targeted by cybercriminals. There have now been more than 100,000 instances of malicious software packages discovered in repositories in the last year alone, noted Hiremath.

    In addition, cybercriminals have become adept at creating fake repositories that mimic legitimate repositories; that can result in developers downloading software components infected with malware.

    JFrog Curation takes the shift left concept of application security to the next level by automatically blocking the use of risky open source software packages, noted Hiremath. The JFrog platform will also surface advice on how to remediate any vulnerability discovered, in addition to creating an audit trail to enable organizations to comply with various regulatory mandates.

    While open source software components reduce the cost of application development, from a cybersecurity perspective, it’s the wild, wild West, noted Hiremath. Organizations are trying to bring more discipline to the way software is constructed by adopting DevSecOps best practices, but they need an approach that doesn’t introduce any additional friction into the application development process, he added.

    JFrog Curation addresses that issue by addressing cybersecurity and compliance issues before any open source component becomes part of the build, said Hiremath.

    As regulations to hold organizations more accountable for the security of the software they deploy are being proposed around the world, it’s only a matter of time before organizations must revisit the security of their software supply chains. Cybercriminals have already proven how adept they are at injecting malware into software components that could be used in thousands of downstream applications. In the eyes of regulators, organizations that don’t scan open source software for malware and vulnerabilities are engaging in reckless behavior that will warrant stiff penalties.

    The challenge is that, after giving developers free rein to develop software any way they see fit, organizations are now faced with a challenge that is as much cultural as it is technical. Automated processes will naturally play a key role in curbing aberrant behavior in application development, but there is, as always, no substitute for some good old-fashioned common sense.

  • Tricentis Acquires Waldo to Further Advance Mobile Testing

    Tricentis Acquires Waldo to Further Advance Mobile Testing

    Tricentis has acquired Waldo as part of an effort to expand the scope of the automated testing capabilities it provides for mobile applications.

    Waldo adds a software-as-a-service (SaaS) platform that provides IT teams with a no-code tool for generating mobile application tests. Waldo uses a virtual environment to simulate iOS and Android devices in a way that eliminates the need for physical devices to conduct tests. Instead, DevOps teams record their applications and then use the no-code tools to generate tests directly from within a browser.

    Tricentis CTO Mav Turner said Tricentis opted to acquire Waldo because it makes it simpler for IT teams to generate tests that can be integrated across a DevOps workflow.

    There currently is a lot of debate over how far application testing should be shifted left toward developers. In theory, the more developers test applications themselves the fewer issues there should be once an application is deployed in a production environment. However, there is still going to be a need for dedicated testing teams to conduct tests across multiple stages of the application development process to ensure quality, noted Turner.

    The difference is more of those tests can include edge use cases that previously there would not have been enough time to conduct, he added.

    Earlier this year, Tricentis added the ability to test native iOS and Android applications to its Testim software-as-a-service (SaaS) platform as part of an effort to extend the reach of that platform to applications that run natively on a mobile device.

    Testing mobile applications is more critical than ever because the cost of failure—in terms of impact on the business—is now much higher as more organizations depend on software to drive business processes. The challenge is that many of these app developers don’t have a software engineering mindset, so they need testing platforms that automatically create and run tests on their behalf in a way that can be customized for specific use cases.

    Over time, the quality of applications should steadily improve as many of the low-level mistakes that developers make are eliminated. That should improve everything from application security to the user experience as applications are continuously updated.

    In addition, organizations that embed testing within DevOps workflows are steadily reducing the number of issues that need to be addressed before applications are deployed.

    Hopefully, as more artificial intelligence (AI) is applied to the testing process, the number of reasons tests are not run as frequently as they should be will steadily decline. Today, it is still too difficult for many developers to author tests, so they don’t conduct as many as they should. Of course, many of them also simply run out of time when writing the code that drives the application takes longer than anticipated.

    One way or another, developers will run out of excuses for not running tests as accountability for code quality increases.

  • BigPanda Extends AIOps Platform to Embrace Generative AI

    BigPanda Extends AIOps Platform to Embrace Generative AI

    BigPanda today added generative artificial intelligence (AI) capabilities to analyze incidents surfaced by its AI for IT operations (AIOps) platform.

    Blair Sibille, field CTO for BigPanda, said Generative AI for Automated Incident Analysis leverages generative AI platforms based on the general-purpose large language models (LLMs) created by OpenAI.

    The goal is to make it simpler for IT teams to discern the root cause of an issue by, for example, taking advantage of summaries of alerts enabled by generative AI to make it simpler for IT professionals of any skill level to understand what requires their most immediate attention, he added. Today, insights are lost in the sea of alerts that often inundate IT teams, Sibille noted.

    BigPanda has been at the forefront of applying machine learning algorithms to automate IT operations management. Now, the company is incorporating external general-purpose LLMs to further augment IT teams, said Sibille.

    As IT environments continue to be more complex, it’s becoming essentially impossible for IT teams to manage them at scale without relying more on automation. AI technologies take automation to another level, but they won’t eliminate the need for DevOps teams to manage IT environments, added Sibille.

    BigPanda claimed generative AI capabilities will make it possible to reduce the amount of time required to resolve tickets by seven minutes each, with an accuracy rate of 95% during beta testing. Over time, those capabilities not only reduce mean-time-to-resolution but also reduce the level of toil that often conspires to burn out DevOps teams, said Sibille.

    At the core of the BigPanda AIOps platform is a data lake capable of consuming data generated by multiple applications and systems. That data then provides the foundation on which machine learning algorithms are applied to surface insights.

    It’s not clear how much generative AI will automate DevOps workflows, but in effect, more IT teams will be able to take advantage of having the equivalent of a DevOps engineer that they can query any time an issue arises using natural language, noted Sibille.

    AI doesn’t mean that IT outages will be completely eliminated, but it does mean they will become a lot less stressful, he added.

    Naturally, there’s a lot of speculation concerning the impact AI will have on DevOps. Some contend it’s only a matter of time before the entire software engineering process is automated. As those advances are made, the cost of building applications will effectively drop to zero. Others argue that AI will simply augment DevOps teams in a way that makes it simpler to manage IT at scale using either the same number or possibly even fewer engineers.

    The one thing that is clear is that AI will soon be pervasive. DevOps teams should start evaluating today which tasks will be automated with an eye toward planning how DevOps roles will evolve as AI advances accelerate.

  • Roadie Adds Scorecard Tool to Backstage SaaS Platform

    Roadie Adds Scorecard Tool to Backstage SaaS Platform

    Roadie today made generally available a tool that automatically tracks and reports how software development teams are performing against engineering standards defined by a DevOps team. The Tech Insights tool is an addition to Roadie’s implementation of the open source Backstage developer portal and is delivered via a software-as-a-service (SaaS) platform.

    Roadie CEO David Tuite said Tech Insights is a proprietary tool that Roadie developed as an extension to its platform. Tech Insights provides scorecards that track software assets in the Backstage catalog and ensure they are meeting predefined quality and compliance targets.

    Tech Insights comes with built-in, pre-defined data sources; alternatively, DevOps teams can define them using external application programming interfaces (APIs) or files in a repository. A rule known as a Check can then be created to validate whether a project complies with the engineering standards defined by the DevOps team. Each DevOps team can create an unlimited number of scorecards.

    In addition, teams can create prompts and notifications to warn engineers when they are about to make a change that will violate an engineering standard. DevOps teams can also employ gamification techniques to show teams how their performance compares to others.

    While Roadie is now adding its first proprietary tool to the platform, Tuite said the company remains committed to enabling organizations to migrate their instance of Backstage to another environment should they ever deem it necessary, he added.

    Originally developed by Spotify, Backstage makes it possible to create and manage a catalog of blueprints that developers can readily consume rather than requiring them to repeatedly build these capabilities themselves. The goal is to create scaffolds that developers can consistently reuse across multiple application development projects.

    Spotify has since donated Backstage to the Cloud Native Computing Foundation (CNCF). However, Backstage currently requires a significant amount of DevOps expertise to set up and maintain, an issue that Roadie is addressing by making it available as a SaaS platform that can be accessed by any application development team, said Tuite.

    The concept of a self-service portal through which developers can address their own needs may not be new, but as an open source project, Backstage is lowering the cost of improving overall developer productivity. At the same time, many organizations are now embracing platform engineering as a means of centralizing the management of DevOps.

    Ultimately, every minute developers spend on tasks other than writing code is one less minute they are spending writing the business logic that drives an application. Measuring developer productivity is, of course, an inexact science. No one knows for sure when inspiration might strike, but if developers are busy maintaining code that they created to provision infrastructure, it’s less likely they’ll be struck by a flash of brilliant insight that improves and application. The easier it is to spin up a development environment, the more likely that inspiration will one day turn into code that runs in an actual production environment.

  • Key Insights From the Stack Overflow 2023 Developer Survey

    Key Insights From the Stack Overflow 2023 Developer Survey

    Stack Overflow has released its seminal yearly developer survey. The 2023 report, which surveyed over 90,000 developers, provides a comprehensive view of the current software developer experience.

    Below, I’ll highlight a few important findings, namely the significant programming language and tooling preferences, the use of AI in the development workflow and what these trends could mean for the DevOps field. I also gathered insights from Joy Liuzzo, vice president of product marketing at Stack Overflow, to dive deeper into some of the findings.

    Developer Technology Preferences in 2023

    Of note is that more and more developers are learning to code online. Learning to code using online resources increased from 70% in 2022 to 80% in 2023. Although many developers (47%) still have a Bachelor’s degree in computer science or the equivalent, these trends underscore the movement toward alternative knowledge solutions, especially for younger programmers. The topmost online resources include technical documentation, blogs, forums and how-to videos.

    JavaScript is still king—it’s now in its eleventh year as the most common programming language. But it’s worth highlighting that Python has overtaken SQL as the third top language. “SQL was solidly in the top three (JavaScript, HTML/CSS, SQL) since 2015, so it’s a big deal for it to have fallen below Python,” said Liuzzo. “We’ve seen Python’s popularity increase based on the number of questions asked on our public site, so we’ve been expecting some shifts.”

    TypeScript and Bash/Shell have also consistently grown in usage over the last few years. “These two languages are involved with the functions of other popular programming languages, explaining their prevalence among programmers,” Liuzzo said.

    PostgreSQL also overtook MySQL as the most common database type. In terms of web frameworks, Node.js and React.js are the most dominant. Other frameworks, like jQuery and ASP.NET, are showing signs of going out of style, likely because they are older web frameworks.

    Spotlight on AI

    The explosion of new AI innovations, such as large language models (LLMs) and chat-driven generative AI tools, had a major impact on this year’s technology findings. In fact, 83% of respondents have used ChatGPT over the past year. This is followed by Bing AI (20.6%), WolframAlpha (13.36%) and Google Bard AI (9.86%). GitHub Copilot was ranked as the top most-used AI developer tool.

    There was a significant spike in using AI tools amongst those learning to code—these folks often see benefits like speeding up learning, increasing productivity and greater efficiency. “Pair this with how they are currently using AI tools to debug and get help (68%) and learn about a codebase (50%), and we see that the commonality is that AI tools enable learning,” explained Liuzzo.

    That being said, there’s skepticism around AI’s accuracy, and only 13% see improved accuracy in coding as a benefit of using such tools. These pain points may resolve as LLMs evolve, but for now, there still needs to be human judgment to catch bugs and avoid hallucinations.

    “AI has a complexity cliff. Much like Helmsman’s complexity cliff found in project management, after a certain point, the ability for AI to handle all the nuances and interdependencies of a solution drops off,” said Liuzzo. “That’s when humans, their ability to apply judgment and have original thoughts, saves the day.”

    So what are some takeaways for those working in the DevOps field, namely DevOps tooling providers and platform engineers? Well, new tooling preferences and habits will continue to evolve in the DevOps field in new ways. Here are some potential examples:

    • More Markdown-based collaboration. Markdown is the most admired asynchronous tool and has increased in popularity this year. New programmers are adopting a blend of Markdown, GitHub Discussions and Notion for their asynchronous tooling. Flavors of Markdown are already being used for comments, merge requests, issues and more.
    • Continued Docker reliance. Docker remains the top-used tool, followed by npm and Pip. Despite the rise of managed container services, Docker is still a popular way to package and distribute software.
    • Challengers to the big three loom in the distance. Amazon Web Services (AWS) is still the most-used cloud platform at 48.62%. It’s followed by Microsoft Azure (26.03%) and Google Cloud (23.86%). Yet, newer developers want to work more with Hetzner and Vercel.
    • Online learning is paramount to knowledge sharing. Given the steady increase in new programmers and their reliance on online resources rather than traditional schooling, DevOps and open source communities should seek to enhance their online footprint by making knowledge like tooling documentation and tutorials easily consumable.

    Last but not least, generative AI is set to enhance programming in many areas and is already becoming embedded into many environments. Just as AI can be used for code generation and debugging, LLMs will likely assist the DevOps side of the equation, helping automate the CI/CD pipeline, optimize infrastructure, detect anomalies and provide more chat interfaces to initiate these capabilities.

    “AI tools are empowering and enabling learning,” said Liuzzo. “Generative AI will democratize coding and grow the developer community by several folds—and that growing number of developers will be the ones using the tools and also verifying and validating the outputs as they learn—bringing the power of the developer community and the technological power of AI together.”