devopsy.kinsta.cloud

Category: DevOps Open Source

ProjectDiscovery Brings Open Source AI Testing to Vulnerability Discovery

ProjectDiscovery has made available an autonomous security testing platform that leverages an open source artificial intelligence (AI) testing framework to detect and validate vulnerabilities at a lower total cost.

Company CEO Rishi Sharma said version 1.0 of the Neo platform is also available via a cloud service that makes it possible for DevSecOps teams to run tests and conduct investigations using a consumption-based pricing model.

Additionally, Neo 1.0 adds integrations with DevOps tools and platforms such as GitHub, Jira, Confluence, Slack, Linear, application programming interfaces (APIs), webhooks, and the Model Context Protocol (MCP).

Based on an open source project, ProjectDiscovery, in addition to using Neo to detect, validate and route vulnerabilities to the responsible developer, also provides access to Nuclei, an open-source vulnerability scanner driven by customizable YAML templates to detect misconfigurations and exploits. Also included are tools such as Subfinder for discovering subdomains, an httpx tool to probe HTTP, a web crawling tool dubbed Katana, and a port scanning tool known as Naabu.

Collectively these components provide the foundation for an open source ProjectDiscovery ecosystem that already includes more than 100,000 practitioners, making it less costly to discover and remediate vulnerabilities using an autonomous security testing and penetration platform that continuously generates alerts in real time or can be used to run tests at scheduled intervals, said Sharma. Relying on code scanning tools is no longer enough, he added. Instead, there needs to be an entire tool chain in place that not only identifies vulnerabilities but also makes it simpler to identify which vulnerabilities can be reached and actually abused, noted Sharma. Otherwise, DevSecOps teams will soon find themselves overwhelmed by the number of false positives that are generated by AI models, he added.

As artificial intelligence (AI) models advance to the point where discovering vulnerabilities and creating exploits becomes trivial, DevSecOps teams now more than ever need to be able to discover those vulnerabilities before software is deployed in a production environment. The challenge is that, historically, the cost of applying AI to test code has been too high for many organizations to adopt, said Sharma.

In fact, organizations need to realize that application security in the AI era is not just a technical issue but more importantly requires new processes to be defined and embraced that go beyond simply asking an AI model to identify vulnerabilities in source code, he added.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said the truth is there has never been a shortage of vulnerability findings. DevSecOps teams drown in them and burn triage time sorting real threats from noise. Neo validates what it finds, then routes the exploitable issues to the developer who owns the code. The scan-and-fix cycle was built for human code at human speed. AI writes and exploits faster than weekly scans keep up, so testing now has to run where code gets created, he added.

It’s not clear how long it will be before there is a full-blown vulnerability crisis, but it’s apparent DevSecOps teams are running out of time. Technical debt that has been kicked down the proverbial road for years now needs to be rapidly reduced because many more cybercriminals will have access to more advanced models in a matter of weeks. Each DevOps team will then need to determine at what rate to remediate vulnerabilities in existing applications versus opting to replace legacy applications with ones that are, hopefully, more secure.

In the meantime, however, DevSecOps teams, while continuing to hope for the best, would be well-advised to start preparing for the worst-case scenario as soon as possible.

August 13, 2026
Open Source Code Just as Secure as Proprietary Software—If You Manage It Right, Says CISA
Open source can be just as safe as proprietary software, though government agencies (and private enterprises) should take additional measures to secure it properly, according to a new guide published by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

The report, “Open Source Software: Security Principles and Practices,” provides with guidance to help agencies comply with two Presidential Executive Orders (14144 and 14306) which both urged them to do a more thorough job securing the software they use, a response to recent exploits like Log4Shell and XZ utils.

CISA acknowledges that open source can provide immeasurable benefits to government agencies, not merely because it is available without licensing fees, but also because agencies can extend the software to meet their own requirements. But at the same time, open source software must be managed differently than proprietary software.

Malicious hackers (and increasingly AI agents) use vulnerabilities to gain entry and exploit systems. In the case of the vendor software, it is the vendor’s responsibility to provide timely updates should a software vulnerability be found, which agencies should apply as soon as possible.

With open source software, however, agencies need to take a more proactive role in patching and understand the dependencies, or additional software components, that an open source package relies on. Those components also need to be secured, the guidance advises.

The guidance describes established principles for patching. It also provides a framework to evaluate trustworthiness and risk tolerance of software packages, as well as a set of best practices to procure, deploy and maintain open source software.

In practical terms, agencies wishing to use open source should establish a process that supports staff in choosing the software that meets the agency’s needs but minimizes risks to the agency.

For instance, an agency’s Office of the Chief Information Officer may set up a system to pre-approve certain software libraries for use in the agency. Automated tools could help verify safe software packages, and reviews would consider potential risk exposure. The CIO could still individually sign off on higher-risk components, such as operating systems.

To help agencies, CISA produced the C4 Framework, which can be used to assess the trustworthiness of a software package. It looks at four factors (the four Cs):
- Codebase: Take a look at the actual source code and dependencies that make up the software component of interest. How recently was the last update committed? How many vulnerabilities have been found? How many out-of-date dependencies does it rely on?
- Community: How robust is the community that maintains and contributes to the project? Is it part of a foundation, or managed by a private company?
- Conduct: How is the project managed? Is there a vulnerability disclosure process? Do the project leaders follow their own code of conduct?
- Configuration: Is the default configuration secure? Are there guides for use in highly-sensitive environments?
Open source AI systems should go through additional checks, CISA recommends. Agents should get sufficient transparency into the training data, in addition to the software itself. “Only with transparency and access can agencies understand and study the software, analyze it for vulnerabilities, and remediate any found vulnerabilities or risks,” the guide recommends.

CISA has targeted this report to U.S. federal agencies, though the advice here is rock-solid for use in the industrial sector as well. Many businesses in finance and health care, for instance, routinely follow government guidance. So if your organization uses open source in any capacity, this report may be worth checking out.
July 31, 2026
AI Is Exposing a Growing Blind Spot in Open Source Security

With AI, teams across organizations are now building internal applications faster than ever, often pulling in open source libraries and frameworks without much thought about long-term support, lifecycle management, or security ownership. An unintended consequence of this is that unsupported open source software (OSS) is quietly spreading across environments faster than security and engineering teams can keep track of it.

Most organizations already struggled with open source visibility before AI-assisted development became mainstream. Now, many are also accumulating technical debt at a much faster rate, creating future maintenance, security, and migration obligations every time new dependencies are introduced.

The question is no longer simply how fast organizations can build software with AI. It’s whether they can securely govern and sustainably support the software ecosystems they are creating.

Unsupported OSS is Becoming a Major Blind Spot

Many organizations already have unsupported frameworks and abandoned dependencies inside critical applications; most just do not realize it yet. As AI expands software development beyond traditional engineering teams, it’s becoming easier than ever to introduce open source dependencies without understanding whether projects are actively maintained, security patches still exist, or frameworks are approaching end-of-life.

The result is fragmented software stacks and growing visibility gaps across enterprise environments. It is also accelerating the accumulation of technical debt, creating future maintenance, support, and migration obligations every time new dependencies are introduced. Much of that debt remains hidden until a security issue, compliance requirement, or modernization effort forces it into the open.

While AI is dramatically increasing the speed and breadth of vulnerability discovery across open source ecosystems, the harder challenge is validating findings. This includes understanding exposure, prioritizing remediation, and fixing issues safely, all work that still depends heavily on maintainers and security teams already stretched thin.

AI is Breaking the Traditional Security Feedback Loop

For years, open source security operated on an imperfect but manageable equilibrium. Vulnerabilities were discovered relatively slowly, maintainers had time to validate reports, and engineering teams could prioritize remediation in cycles that were difficult but sustainable. AI is disrupting that balance.

The imbalance between vulnerability discovery and remediation is already becoming visible across the open source ecosystem. Recent reporting around Spring projects illustrates how quickly vulnerability discovery is accelerating. After 17 CVEs were disclosed across all of 2025, between this last March-April alone, 30 CVEs were reported.

Organizations are now trying to manage exponentially larger software ecosystems using governance and remediation models designed for a much slower era of software development. That imbalance is becoming increasingly difficult for maintainers, security teams, and enterprises to absorb.

Governance Needs to Catch Up to the Speed of AI

Open source is not going away. AI will only make it more foundational to how software gets built. But enterprises can no longer treat open source governance as an informal process handled only during vulnerability remediation cycles.

As AI accelerates software creation, organizations need better insight into the open source software running across their environments, including which components are unsupported, approaching end-of-life, or no longer actively maintained. It’s no longer enough to know which components have vulnerabilities. Organizations also need to know whether the software they depend on can still be supported and secured over the long term.

Enterprise and security leaders should focus on a few practical priorities:

Identifying unsupported and end-of-life dependencies before they become operational risks

Understanding which OSS components are business-critical and actively maintained

Reducing Reliance on Reactive “Scan and Patch” Remediation Cycles Alone

Building longer-term support and lifecycle planning into how open source software is adopted and maintained

Open source remains foundational to modern software development. But as AI accelerates software creation and vulnerability discovery simultaneously, unsupported OSS is becoming harder for enterprises to govern, support, and secure at scale.

Organizations that navigate this shift most successfully will not simply be the ones building software fastest. They will be the ones capable of maintaining visibility into the open source software they depend on and treating OSS governance as a core operational discipline, not an afterthought once vulnerabilities appear.

June 25, 2026
GitHub Breach Tied to Malicious VS Code Extension Exposes Thousands of Internal Repositories

GitHub says attackers accessed thousands of internal repositories after a company employee’s device was compromised through a malicious Visual Studio Code extension, though the company said it has removed the malicious extension, isolated the compromised endpoint, and launched an investigation.

The company confirmed that approximately 3,800 internal repositories were affected. GitHub stated that investigators have not found evidence of impact to customer repositories or enterprise environments outside GitHub’s own systems.

The hacking group TeamPCP later claimed responsibility for the intrusion in a post on the Breached cybercrime forum. The group alleged it had obtained source code and thousands of private repositories and sought at least $50,000 for the data.

GitHub has not formally attributed the attack to TeamPCP, though the company acknowledged that the group’s public claims are generally consistent with the scope of the ongoing investigation.

The GitHub breach is the latest example of the increasing attacks against software development infrastructure. Hackers view developer platforms as efficient paths into enterprise systems because a single compromise can create downstream access across multiple companies.

GitHub said it continues to review logs, rotate credentials and monitor for additional malicious activity tied to the incident. The company said it plans to publish a more detailed report once its investigation is complete.

Protecting Dev Tools

Enterprise security teams are facing a growing challenge these days: protecting not only production systems, but also the interconnected tools that developers are using. Over the past several years, malicious extensions and backdoored open source packages have been used to distribute credential stealers and ransomware.

Visual Studio Code extensions are commonly used to add features and integrations to Microsoft’s widely adopted code editor. Because these extensions often operate with elevated permissions inside development environments, compromised plugins can provide attackers with access to internal systems.

Earlier incidents involving the VS Code marketplace included extensions masquerading as legitimate developer tools that secretly harvested credentials or deployed malware. In January, researchers identified malicious AI-themed coding assistant extensions that reportedly transmitted data from compromised systems to infrastructure located in China.

TeamPCP has emerged as a notable actor in software supply chain attacks targeting open source ecosystems. Researchers have linked the group to campaigns involving GitHub Actions workflows, npm packages, Docker environments and PyPI repositories.

Several of those operations focused on stealing sensitive developer information including SSH keys, Kubernetes configurations and cloud credentials. Researchers have also connected the group to compromised software packages distributed through legitimate repositories and typosquatting campaigns designed to trick developers into downloading malicious code.

The risk of attacks has expanded further as companies adopt AI-assisted coding tools and open source dependencies to accelerate software development. Many enterprises now rely on large ecosystems of third-party plugins and extensions that can introduce additional security exposure.

May 20, 2026
OpenSSF’s CRob: ‘The Runway Is Rapidly Running Out’ on EU CRA Readiness

The EU’s Cyber Resilience Act kicks into high gear this September, and companies are still clueless about how they must obey its strictures.

MINNEAPOLIS — At Open Source Summit North America, Christopher “CRob” Robinson, Chief Security Architect for the Open Source Software Foundation (OpenSSF), spoke about the European Union’s (EU) Cyber Resilience Act (CRA). CRob warned that companies are still “running straight at that wall” as the first CRA enforcement date draws ever closer.

The CRA, for those who don’t know it, sets mandatory cybersecurity rules for nearly all “products with digital elements,” which means hardware and software, sold on the EU market, with most obligations falling on manufacturers but some also on importers and distributors. That means if you sell pretty much anything in the EU, you must include a security risk assessment; design them with secure default configurations and the ability to restore to a secure state; eliminate known exploitable vulnerabilities; and provide and deploy security updates. If you don’t, the EU will sock you with fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Scary stuff, right? You’d think companies would be working their fingers to the bone getting their goods ready for the post-CRA market. You’d be wrong.

“It’s wild,” CRob said. “We did a report last year… and we’re doing the sequel. And people still are not aware of what they need to do and are not prepared, but the runway is rapidly running out.”

How bad is it? CRob said, “62% of people in Europe were unaware of what they needed to do last year. This year it’s 66%, which is statistically the same.”

It’s even worse outside Europe. In a blog post, CRob pointed out that “The geographic disparity is even more alarming. In the United States and Canada, nearly 72% of respondents are unfamiliar with the regulation. It cannot be understated: If you are a North American company selling software products into the EU market, you are legally required to comply with the CRA. However, the majority of the neighborhood is still walking unprepared toward a September 2026 reporting deadline.”

The Linux Foundation and partners had expected their second CRA readiness survey to show clear progress after a year of talks and guidance aimed directly at manufacturers and developers. Instead, the tech business remains oblivious.

“The TL;DR is we and other groups within the industry have been working on this very hard for a year, and we thought we had done a better job of getting in the rooms where the manufacturers or developers are,” CRob said. “We had expected that the second iteration of the report was going to be amazing… but the results are very middling.”

Looking ahead, the Linux Foundation is taking its message to Brussels, the de facto EU capital, in June. There, “we’re going to talk with the European Commission and ENISA.” In addition, Linux Foundation Europe will host a European policy day on June 8, followed by a June 9 event focused “purely on cyber security, mostly the CRA,” but Robinson expects the AI Act will also be on the agenda. In short, ” people need to wake up.”

Robinson argues that CRA compliance cannot be delegated to technical teams alone and says senior executives are not yet sufficiently engaged. “It’s an urgent wake‑up call, that’s for damn sure,” he added, “You need the C-suite, and it needs to get involved. This can only happen from the top down, and they’re just not going to pay attention to the open-source conferences.”

Beyond awareness, Robinson says many companies are making structurally bad bets about how to meet CRA obligations around vulnerability management and updates. In a separate Linux Foundation economics study on ROI for Open Source Software Contribution, he cites “a little over half” of organizations reporting that they “passively wait for upstream to do something before they react.”

“With the CRA, Robinson continued, “that’s like a really bad move because the upstream doesn’t have the deadlines and the fines,” he said. “They’ll try to work as quickly as they can, but… they’re not going to be yelled at or threatened to work any faster.”

Others respond by forking open source code and maintaining private branches: “They’ll do private forks, where they’ll have a private copy, they might do their own patches and not contribute that upstream,” Robinson said. “That was like over almost $260,000 of either expense or engineering labor for each product release by those organizations, that’s the technical bet they’re taking.” He argues that those numbers should “wake up the C-suite,” given the number of releases many vendors cut each year.

For large organizations (5,000+ employees), CRob added, “This burden exceeds 11,152 labor hours per cycle. Maintaining these divergent codebases is a giant bill for a strategy that actually makes supply chain transparency worse. Contributing fixes upstream isn’t just being a ‘good neighbor’ – it’s the only financially rational path forward.”

Robinson also links CRA readiness to the rapid adoption of AI in software security, which he says will massively increase the volume of fixes vendors must handle. “It’s an explosion of AI. I see it in three tiers right now.”

At the top are upstream maintainers, who he expects will “figure a way to manage this” by automating and leveraging new tools, but who will also generate “exponentially more patches every day.” The second tier consists of manufacturers “on the hook for things like the CRA,” who must “retool internal processes that have existed for decades… very conservative, very brittle, slow processes.”

The third, and in his view least prepared, group is downstream enterprises such as “a bank, or a hospital, or whatever.” “All these people… are totally unprepared for thousands of fixes hitting their inbox,” Robinson warned, adding that bad actors will inevitably weaponize AI‑driven vulnerabilities and exploits. He asked, “How do we prepare purely downstream consumers to be able to take these patches, deploy them quickly, so that they aren’t… a victim to some attack?”

That’s a good question, and for now, there are no good answers. Companies will soon have no choice but to figure it out. All the hysteria about how bad Y2K was going to be turned out to be so much hype because the hard work had already been done. When it comes to the CRA, however, far too few companies have done their homework.

May 20, 2026
The Future of Observability: How OpenTelemetry is Shaping IT Operations in the Age of AI

Today’s IT application environment is complex and evolving quickly, especially with the integration of artificial intelligence (AI). Modern development processes and collaborative approaches like open-source code have streamlined the creation of sophisticated applications, enabling development teams to rapidly build complex systems. The proliferation of data, driven by AI, allows these apps to source vast amounts of information, further contributing to the development of advanced and impressive applications. However, as applications get more complicated, managing and monitoring them becomes increasingly challenging. One solution the industry is turning to is OpenTelemetry (OTel), an open-source framework designed to provide a consistent and comprehensive approach to collecting and understanding data.

DevOps and other modern development processes have significantly advanced how we build applications. Containerization technologies such as Docker and orchestration platforms like Kubernetes support these processes by enabling consistent, scalable and portable application environments. These modern practices enhance efficiency, reliability and scalability, allowing organizations to quickly adapt to demands and deliver high-quality applications.

Additionally, open-source code — a code that anyone can access, utilize or modify — plays a pivotal role in modern application development. As a collaborative approach, it has been instrumental in creating complex, scalable and innovative solutions that might have been otherwise impossible within a closed framework. Open-source code has enabled DevOps teams to achieve amazing feats in the world of application development. Democratizing a source code allows users anywhere to share and access useful software, but because the code is governed by its users, it also creates an environment where users can build off each other, making application advancement hypothetically infinite.

The ability to utilize open-source code and, therefore, pull from different open-source repositories has led to an explosion of progress in application development. However, significantly more advanced applications have created increasingly complex application environments, which makes it harder for teams to monitor their systems from an IT operations standpoint. In addition, AI-driven systems have added new layers of complexity. AI workflows involve real-time processing and unprecedented amounts of data, necessitating robust monitoring systems capable of managing it all.

OTel Presents a Promising Solution

Pulling from the same open-source belief, there is a solution to this challenge: OTel. Just as open-source code has fostered the creation of advanced and innovative apps, OTel, an open-source solution, exists to better manage and monitor them. OTel addresses these pain points in its ability to provide a standardized approach to collecting and analyzing telemetry data, ensuring that organizations can effectively monitor and manage the performance of these fast-moving and intricate AI-driven systems. The OTel framework supports the real-time monitoring and observability needs of AI applications, helping teams maintain the health, performance and reliability of their systems in the face of massive data volumes and convoluted processing tasks.

OTel helps manage large amounts of data generated by AI systems and enhances AI’s ability to predict and detect issues. AI systems run by processing data gathered from various sources, including telemetry data managed by OTel. When that rich telemetry data is fed into AI-driven analytics platforms, it fosters predictive maintenance, issue detection and automated remediation. In other words, by easily accessing high-quality and organized data, AI systems can learn over time what is normal for a particular IT environment and then automatically adjust and improve its responses to debug issues and maintain system performance. As a result, OTel contributes to the process of helping systems identify problems early and take action without needing constant human intervention, thereby improving efficiency and effectiveness overall.

Imagine a system that not only monitors but also predicts anomalies, diagnoses root causes autonomously and adapts to changing conditions in real-time — all powered by AI algorithms trained on vast amounts of telemetry data. With OTel, AI-driven systems can rapidly reveal and analyze billions of insights, contributing not only to an increased level of observability but to an environment where issues can be solved before ever becoming an issue.

We live in a world where modern application development processes have enabled teams to create incredibly advanced, helpful and even transformational applications. As applications become increasingly complex, the demand for sophisticated observability solutions grows in tandem. The future of observability hinges on the advancement of technologies such as open-source software and AI. While open-source software has significantly improved application development processes, it has created an environment where applications have become extremely difficult to monitor.

The combination of modern AI-driven observability solutions with OTel presents a promising solution. By standardizing the collection and analysis of telemetry data, OTel ensures that organizations can achieve robust observability, enabling them to harness the full potential of AI and to keep developing advanced applications while also being able to manage them. Due to this, through enhanced observability, OTel is going to do for IT operations what open-source software originally did for application development. It is going to transform it.

July 11, 2024
System Initiative Open Sources Digital Twin Tool for DevOps

System Initiative (SI) today announced it is making the digital twin tool it developed to manage DevOps workflows available under an open source Apache 2.0 license.

Company CEO Adam Jacob said the approach will enable third parties to contribute to a project that is still early in its development cycle while SI provides commercial support via a subscription service.

SI has developed a tool that creates a digital twin of a DevOps environment that provides a level of abstraction that makes it simpler to manage complex workflows at scale.

At the core of that effort are models of IT environments created by the SI platform accessed via a visual interface. The automation framework built into the platform uses the relationships between models to infer configuration dynamically and generates typescript code that a DevOps team can then apply to automate a task.

Feedback loops are provided in real-time to give insight into the viability of a configuration, in addition to eliminating the need for state files to track and ‘plan’ versus ‘apply’ stages.

This approach streamlines a lot of the complexity that creates bottlenecks in DevOps workflows in what heralds the arrival of a new DevOps 2.0 era, said Jacob.

In general, SI is making a case for an alternative approach to managing DevOps as the existing platforms and framework are fundamentally broken, added Jacob. Models that create digital twins of DevOps environments represent the arrival of a new era of software development and deployment, he noted.

As more organizations realize their dependency on software to drive digital processes many are then looking to improve the productivity of developers and the DevOps teams that support them. Unfortunately, many DevOps teams are supporting DevOps workflows using custom code that varies widely in quality. Rather than rely on a DevOps engineer to write code, the SI digital twin tool will create code that can be applied more consistently to create DevOps workflows programmatically.

One of the reasons few organizations today have fully automated DevOps across the application development and deployment process is that it’s simply too difficult to achieve using legacy tools and DevOps platforms. It’s not clear to what degree a digital twin approach to managing DevOps will resolve that issue, but when coupled with the arrival of artificial intelligence (AI) capabilities the way DevOps is managed is clearly about to transform.

It may take a while for that transition to occur, but DevOps teams that have historically embraced automation are at the very least going to aggressively experiment with technologies that promise to eliminate much of the drudgery that makes DevOps more tedious than need be. The issue, as always, will be determining which technologies live up to the current level of hype being generated in a way that can be easily adopted.

August 16, 2023
Creating a Growth Loop for Your Open Source Project

Every open source project hopes to achieve escape velocity, attracting enough users and contributors to become a successful, sustainable project that expands over time. But how do you attract developers and create the cycle of adoption that can lead to a thriving ecosystem?

It obviously starts with building a great product that developers love to use, and there’s an element of luck in finding this sweet spot and breaking through. But there’s also a lot that you can control. I was fortunate to have helped create an open source project, Streamlit, that expanded quickly and our company was acquired last year. I wanted to share what worked for me in the hope that it also can be helpful for you.

My guiding principle is to meet developers where they are and make it as simple as possible, at every step in the journey, to discover your project, learn how to use it and build great products. Depending on the type of open source project you’re creating, providing a simple way to share artifacts and use cases built from your code—in our case, this was applications—can also be a powerful way to raise awareness.

I think about this in terms of a “growth loop” with multiple points of entry where developers can get interested and get started. These entry points include developer forums, source repositories, your documentation page, learning assets, your website and more. The point is to eliminate friction at every point in this loop and make it as easy and fun as possible to start building and sharing with your code.

For organizations trying to get their open source project off the ground, here are some key learnings about what worked for my company in building this growth loop and some tips for driving continued adoption and innovation.

Be Visible in the Open Source Community

We made it a point to go where developers are already at, including forums like Reddit and Stack Overflow and conferences like ODSC and FOSDEM. Engaging with developers to understand what they really need from your project and how to reduce points of friction is key. We were always grateful when people gave us feedback and we reached out to any developer who engaged with our product, whether they had 10 followers or 10,000. I’ve found that developers really appreciate it when you “show up,” and you learn an incredible amount that can help your project succeed.

Give Developers What They Need

Don’t hold back features or functionality that developers will find useful. Developers should have access to everything they need and feel confident that they won’t run into a significant paywall that prevents them from scaling. Building a successful open source project is a bottom-up process, and that means eliminating barriers to entry and making your code as easy to use as possible.

Where developers go, enterprises typically follow. If you can build a tool that developers love so much they’re coding with it in their free time, they’re likely to take it into the workplace. If your goal is monetization, this is where you’re most likely to have an opportunity to recoup your investment.

Enterprises require particular features around security, access management, IT support, scaling, service level objectives (SLOs) and other areas—capabilities they are often willing to pay for. So, consider a model where you give developers everything they need to become super users and look for adjacent areas where you can charge for enterprise-type features or enterprise implementations that businesses need.

Make Sharing Incredibly Easy

If developers build great things with your code, it’s helpful if they can share those things with the community to show what’s possible and drive interest. You can think of this as a type of advertising. Most developers aren’t won over by traditional ads, but discovering cool things that other developers have done with your code can be a great way to attract new users and fuel the cycle of discovery and adoption.

So think about the natural output from your project that developers could share with the community. Can they put code on GitHub? Share an app or visualization they built? Post a speed comparison? What can they put on Twitter if they love your project and want to show what they’ve achieved with it?

Our project is for building data apps, so early on, we added a feature that allowed people to take a screen recording and share their work on Twitter so others could see it in action. Later on, we added a free cloud offering so they could directly share apps with the community. Think about what works for your project and how you could make sharing easy.

Create Amazing How-Tos and Tutorials.

These can be important entry points on your growth loop, and it’s best to provide them through developers’ preferred channels. YouTube is a go-to for tutorials of all types, and you can also leverage Coursera, Educative and other e-learning platforms. Someone on my team created a Coursera course for our project that has more than 20,000 enrollees, and one of our Code Camp videos has been viewed over a million times.

Get creative. If your project is starting to see traction among students, think about providing educational materials that professors can use in the classroom. Online interactive courses are not only a great way to learn programming, they make it easier for educators to manage coursework and see who’s keeping up. This is an excellent way to promote your project and capture new developers.

Documentation is another important entry point. Our documentation page is starting to look like an e-learning course itself, with guides for getting started, sample code and sample apps. Documentation pages can be listed by search engines, and we found it was worth the engineering time to make this happen.

Contribute to Other Open Source Projects

Giving back to the community is a good practice for anyone who cares about software, but it can also benefit your project: Contributing to open source projects helps ensure that your software will be compatible with the tools your target developers use. As well as ensuring interoperability, this can help raise awareness of your project in relevant developer communities.

Reaching critical mass with an open source project is about understanding what your target developers need, being smart with your resources and removing friction wherever you can. This concept of a growth loop worked for our project, and I hope it helps you to achieve success with yours.

April 5, 2023
DevOps Done Right: How to Succeed in DevOps From Day One
Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

You’ll learn:
- DevOps best practices, processes and the tools you’ll need
- Tips and tricks from experienced practitioners sharing their real-world experiences
- The basics of DevOps
- How to choose the right technologies
- Common challenges and how to overcome them
- The benefits of DevOps as a methodology and a career
- And more!
As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.
February 14, 2023
Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

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: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

February 8, 2023