devopsy.kinsta.cloud

Author: Mike Vizard

DARPA Enlists GrammaTech to Apply AI to Reverse Engineer Code

The Defense Advanced Research Projects Agency (DARPA) has awarded a research contract to GrammaTech for low code technology that will make it possible for end users to leverage artificial intelligence (AI) without requiring intervention from the original software developer.

GrammaTech’s AI tool, dubbed ReMath, aims to ease application updates by automatically inferring high-level mathematical representations from existing binaries in systems and embedded software. The tool is currently in development.

Dr. Alexey Loginov, vice president of research for GrammaTech, said development teams spend a lot of time using low-level tools such as disassemblers, debuggers and decompilers to manually analyze binaries. ReMath will accelerate that reverse engineering process by recovering and converting machine language into representations that end users can directly manipulate, said Loginov.

The goal is to free developers up to build new software, rather than continuously updating software that has already been deployed, noted Loginov. This approach should ultimately reduce the backlog of application and software development projects organizations have, added Loginov.

The ReMath project is the latest in a series of DARPA contracts awarded to GrammaTech. In general, the company is working towards applying AI to advance DecSecOps via a static application security testing (SAST) tool that identifies vulnerabilities in code. The ReMath project focuses on applying AI to use cases involving, for example, industrial control systems. These systems could benefit from allowing domain experts, with no coding expertise, to maintain and update them on their own, said Loginov.

Other DARPA projects GrammaTech is actively researching include a type-ahead capability that automatically recognizes existing artifacts in a software repository, said Loginov. This capability will make it simpler for developers to reuse code within the context of a GitOps process without inadvertently introducing additional errors, Loginov said.

In the future, the potential impact of AI on software development could be profound, as more reliable code moves into production environments. The percentage of code graduating into those environments on the first attempt should increase considerably in the years ahead. That should enable more reliable delivery of application code via continuous integration/continuous delivery (CI/CD) platforms.

As software development becomes more efficient, the current developer shortage should also ease, and open up resources to launch a greater number of application development projects. Rather than spending time on manual tasks that provide no differentiated value, Loginov said software engineers will be able focus more of their time and energy on process innovation.

In the meantime, developers should expect to see a rash of development tools with AI capabilities in the months ahead. None of those tools are likely to eliminate the need for developers any time soon; however, much of the drudgery involved in writing code today is likely to be sharply reduced as machine learning algorithms and other forms of AI are applied to software development.

January 11, 2021
Cloudflare Lays Out GitOps Ambitions for CDN Platform

Cloudflare’s acquisition of Linc is the latest move in the hosting provider’s move to better align its content delivery network (CDN) service with the tools and frameworks organizations rely on to build modern applications using GitOps processes, according to CEO Matthew Prince. Cloudflare also announced other updates and automation-related features, including a way to automatically deploy JavaScript applications using Linc’s technology.

Prince said these latest moves are part of an ongoing effort to simplify integration of front-end applications with back-end services.

Cloudflare Pages, for example, enables developers to select their preferred repository, identify what types of frameworks they are using, and then automatically deploy their applications on the Cloudflare CDN. The goal is to automate the continuous integration process in a way that enables developers to focus more of their time and effort on developing code, said Prince.

Linc’s technology, meanwhile, will make back-end services more accessible to front-end applications using Front-end Application Bundles (FABs) that accelerate server-side rendering by combining front-end and back-end logic. The result is better performance across any type of application that relies on JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as JAMstack, a framework for building complex applications.

Prince said JAMstack adoption is accelerating because it allows developers to continuously modify the user experience (UX) without the need to modify back-end services. The CDN, meanwhile, has emerged as a platform for continuously deploying applications closer to the point where they are consumed by the end user, said Prince.

That’s become especially critical at a time when digital business processes require data to be processed in near-time, and as closely as possible to the point where it is generated, said Prince. That’s not possible when application logic runs on a public cloud, Prince added.

Cloudflare currently has points of presence in 200 cities worldwide, and is actively courting developers as part of an effort to usurp CDN rivals. Most recently, Cloudflare added a Durable Objects capability that makes it possible to run stateful applications across a distributed, serverless Cloudflare Workers service.

Ultimately, Prince said the goal is to automate the majority of the DevOps process, as code moves from a Git repository to the network edge. A CDN will also provide the means to monitor and secure applications running at the network edge, Prince added.

It’s not clear how much application logic will be pushed to the network edge via CDNs; however, it’s apparent CDNs are emerging as an important deployment platform that should be incorporated with DevOps processes. How providers achieve that goal is, in part, dictated by the framework used to build an application.

Cloudflare’s moves are indicative of the larger trends of automating DevOps processes, a development that should make DevOps best practices more widely accessible to many more developers.

January 7, 2021
BMC Expands Scope of Mainframe Management Portfolio

BMC this week updated its portfolio of mainframe tools as part of an effort to make mainframe platforms more accessible to IT operations teams and developers.

At the core of these offerings is BMC Automated Mainframe Intelligence (AMI), which embeds machine learning algorithms in mainframe platforms to automate a wide range of processes. BMC AMI supplants the company’s existing MainView tools with a framework that promises to make artificial intelligence (AI) more accessible via a revamped user interface.

John McKenny, senior vice president and general manager for ZSolutions at BMC, said an AI model based on the data collected by BMC AI can now be spun up in a matter of minutes, and can identify a potential issue days before it might otherwise occur.

BMC AMI also exposes a REST application programming interface (API) through which more mainframe tasks will be automated.

McKenny said as organizations accelerated digital business transformation initiatives in the last year, the need to modernize mainframe platforms became more acute. Mainframes are now the backend for multitier application environments that need to be managed in concert with other platforms, McKenny said.

BMC is also adding Compuware zAdviser dashboards to the DevOps platform it gained with the acquisition of Compuware last year. BMC also updated Compuware Topaz for Total Test to streamline test creation for mainframe applications. There’s a growing need for better tools to test digital business processes created for the mainframe, noted McKenny.

Other updates include Control-M job scheduler and Compuware ThruPut Manager integration, to ensure jobs run at or before their expected times on a mainframe, and an update to BMC AMI Data for IMS that simplifies database management in mainframe environments.

Finally, BMC updated the BMC AMI Security offering with the Compuware Application Audit tool; this update allows for better capture of relevant user access and behavior data.

McKenny said while mainframes remain one of the most secure platforms available, administrators must ensure security policies are properly implemented. IT organizations should avoid complacency and ensure zero-trust security in mainframe environments, McKenny said.

McKenny added that, despite their long tenure and the rise of cloud computing, mainframes remain relevant. Many organizations determined that the fastest way to achieve their digital business transformation goals is by extending their mainframe platforms – platforms many of them already rely on to process and analyze transactions.

What’s changing is the IT professionals that manage mainframes alongside other platforms, such as the cloud. Many of those IT professionals naturally expect integrated AI capabilities that enable the average IT administrator to manage a platform that was once the sole realm of dedicated IT specialists.

January 7, 2021
Report: Software Quality Issues Costing U.S. Companies $2.08 Trillion

A report published today by the Consortium for Information & Software Quality (CISQ) estimates poor software quality collectively cost companies in the U.S. an estimated $2.08 trillion in 2020.

The report, co-sponsored by software quality and security tools provider Synopsys, attempts to calculate, at least theoretically, the cost of known software failures. The report identifies operational software failures, estimated to be $1.56 trillion, as the single largest cost. The next-largest cost contributor is unsuccessful development projects, which totals $260 billion, an estimated 46% increase since 2018, according to the report. The project failure rate remained steady, at about 19%, for over a decade, according to the report.

Finally, legacy systems issues contributed $520 billion to costs in 2020, a significant decrease from the $635 billion these issues cost in 2018.

That estimate does not include technical debt, which CISQ estimates at another $1.13 trillion. Technical debt costs have been growing at a rate of 14% per year since 2018, the report noted.

Joe Jarzombek, director for government and critical infrastructure programs for Synopsys, said it’s apparent there’s not enough focus on quality assurance within software supply chains. However, as organizations begin to realize how dependent their digital business transformation initiatives are on quality software, business executives will be forced to shift focus.

Unfortunately, most business executives today still don’t understand or appreciate how software is constructed. Most organizations don’t even have a bill of materials describing the components that make up an application, noted Jarzombek.

That issue becomes especially problematic in the event of a security breach, because too many organizations can’t draw a correlation between vulnerabilities and the impact on specific components of an application, added Jarzombek. At the same time, however, cybercriminals are becoming more efficient at scanning applications to discover and exploit those vulnerabilities, said Jarzombek.

Many organizations also don’t appreciate how adept cybercriminals have become at exploiting what are perceived as low-level vulnerabilities to distribute malware laterally across an application, said Jarzombek. There is a tendency to patch only the most critical vulnerabilities within an application, while the rest are left to future updates. When fixing low-level vulnerabilities is not prioritized, these vulnerabilities may remain over multiple release cycles.

Ultimately, Jarzombek said, rather than treating security separately from the application development process, it should be addressed as part of a comprehensive approach to software quality assurance. The immediate challenge, however, is that not enough developers have access to the tools they need to address these ongoing cybersecurity issues.

The impact of poor software quality on individual companies will vary widely, but poor software quality is itself a universal issue. Most software development teams are not deliberately ignoring these issues; instead, the processes currently employed to build software are not especially robust, mature or, for that matter, automated, leaving organizations vulnerable.

January 6, 2021
Orchestration Emerges as Crucial DevSecOps Enabler in 2021

As DevSecOps best practices continue to evolve and mature in 2021, security orchestration is emerging as a cornerstone of a solid defense-in-depth approach to application security.

DevSecOps assumes organizations will shift responsibility for application security further left toward developers. If this assumption is correct, then developers clearly need access to a range of code analysis tools to achieve that goal. The challenge they face is incorporating tools from multiple vendors within a DevSecOps workflow. At different points in the development process, it may make sense to employ a static application security tool (SAST) versus a dynamic application security tool (DAST) that stress-tests the application just before it is deployed.

Not surprisingly, providers of these tools are starting to align with security orchestration engine providers. ZeroNorth, for example, recently added ShiftLeft, a provider of a SAST tool, to the list of security tools that can be orchestrated via its software-as-a-service (SaaS) platform.

Joanne Godfrey, director of product marketing for ZeroNorth, said organizations that have embraced DevSecOps are standardizing on two to three security tools. This mitigates the risk of becoming overly dependent on a single tool to discover vulnerabilities, Godfrey said. No single security tool can uncover every possible vulnerability in a timely manner, so DevOps teams must work to integrate multiple security tools into their workflows.

Developers need tools capable of identifying vulnerabilities as they write code. They should also construct tests to proactively flag vulnerabilities before those are incorporated into a larger build. New vulnerabilities, however, are discovered all the time and it’s not uncommon for a container build deemed safe yesterday to suddenly need an update as quickly as possible. DevOps teams also need to secure the runtimes and hosts on which application builds are deployed, which typically requires more collaboration with the security teams usually responsible for managing platform security and DevSecOps.

Despite this need to collaborate closely, the cultural divide between DevOps and cybersecurity teams is often wide. While there’s a lot of interest in DevSecOps best practices, developers don’t always prioritize application security when there are delivery deadlines to be met. This often results in security issues being addressed late in the application development process or, worse, addressed after the fact as part of an update delivered after an application has been deployed in a production environment.

As application development accelerates, it’s imperative that the current divide between DevOps and security teams is bridged. Short-handed cybersecurity teams simply can’t keep pace with the rate at which applications are being built, deployed and updated. The need to shift more application security responsibility left toward developers increases daily.

The challenge now is, rather than simply delivering an empty DevSecOps sermon, IT leaders need to practice what they preach and provide developers with the tools and processes required to secure their applications.

January 6, 2021
Reserved.ai Applies Machine Learning to Rein in Cloud Costs

Reserved.ai has added a new artificial intelligence (AI) tool to more accurately predict cloud computing workloads and rein in cloud spending. The company says its Purchase Planner tool uses machine learning to optimize cloud computing workloads by automatically purchasing cloud reserve instances based on the forecasts it generates.

Purchase Planner leverages the machine learning algorithms Reserved.ai created to monitor and forecast when organizations should optimally reserve instances on a public cloud. The forecasts are based on customers’ current application workload requirements, as well as what the AI platform estimates overall demand for reserved instances is likely to be in the months ahead.

The Purchase Planner tool is currently available on Amazon Web Services (AWS), and there is also a public beta edition available for Microsoft Azure clouds with support for Google Cloud Platform (GCP) planned for this quarter.

Reserved.ai CEO Aran Khanna said Purchase Planner enables Reserved.ai to automatically purchase reserved instances on the AWS cloud. If, for any reason, those reserved instances are not required, Khanna said Reserved.ai will buy them back from customers.

Given thriving demand for reserved instances on public cloud, Khanna said reselling those instances minimizes any financial risk for the company.

Historically, many IT organizations have over-provisioned their cloud resources to mitigate the cost of having to purchase cloud instances on demand. In the wake of the economic downturn brought on by the COVID-19 pandemic, Khanna said more IT teams are attempting to optimize their cloud costs by reducing the number of reserved cloud instances they anticipate they’ll need based on their current cloud infrastructure consumption. Achieving that goal requires a massive amount of guesswork that can be more accurately calculated by machine learning algorithms, Khanna said.

Khanna said the Reserved.ai platform provides the added benefit of requiring only 15 minutes to install, with a minimal infrastructure footprint required.

Capacity optimization as an IT discipline has been around for decades. In the age of the cloud, however, IT organizations lost visibility into capacity utilization and cloud computing costs as developers spun up virtual machines. Now, finance teams require IT teams to, at the very least, maximize the number of workloads run while more accurately predicting cloud costs. Any actual reduction in cloud spending is a secondary benefit. The challenge today is that most cloud optimization efforts rely on the manual efforts of IT teams, and often, they’re unable to keep pace with the rapid rate of change in the cloud.

Understanding the true cost of cloud computing will be more critical in the months ahead, as more organizations look to compare the cost of running one type of workload on the cloud versus another. Gaining visibility into those costs today will only be feasible when IT teams can rely on AI platforms capable of analyzing those costs in near real time. Otherwise, by the time an IT team becomes aware of an opportunity to reduce costs, the opportunity has already been seized by another organization.

Regardless of how IT teams rein in cloud costs in the months ahead, the goal should be to maximize the number of workloads that can run without increasing the budget. After all, most organizations today are focused on maximizing their existing cloud investments to the fullest extent possible.

January 4, 2021
AWS Looks to Meld MLOps and DevOps

The rate at which machine learning operations (MLOps) and DevOps best practices are converging is poised for rapid acceleration in 2021. At the recent online AWS re:Invent conference, Amazon Web Services (AWS) announced it is adding a bevy of capabilities to Amazon SageMaker, a managed MLOps service, that includes a continuous integration/continuous delivery (CI/CD) service for MLOps it is calling Amazon SageMaker Pipelines.

Amazon SageMaker Pipelines enables developers to define a machine learning workflow that encompasses everything from loading data to training configuration; algorithm set up and debugging algorithms. Rather than having to acquire and deploy a standalone CI/CD platform for building artificial intelligence (AI) models, AWS is making the case for using a managed service that enables developers to manage workflows from within the Amazon SageMaker Studio tools it already provides for building AI models.

Workflows can be shared and reused between teams to either re-create a model or can serve as a launch point from which to create another AI model.

Amazon SageMaker Pipelines also logs each event in Amazon SageMaker Experiments, which enables IT teams to organize and track machine learning experiments and versions of AI models. In addition, a Deep Profiling for Amazon SageMaker Debugger now makes it possible for developers to more quickly train AI models by automatically monitoring system resource utilization and generating alerts whenever bottlenecks are detected.

AWS has also added a Distributed Training capability to Amazon SageMaker that it claims makes it possible to train large, complex deep learning models up to two times faster than current AWS approaches by enabling data and AI parallelism across its cloud services.

The cloud services provider has also added an Amazon SageMaker Edge Manager service that enables developers to optimize, secure, monitor and maintain machine learning models deployed on fleets of edge computing devices. The Amazon SageMaker JumpStart service enables developers to search for AI models, algorithms and sample notebooks.

Finally, AWS has added additional data preparation tools that come pre-configured with support of AWS and third-party data sources, a repository for storing AI models, a preview of additional tools for automatically matching AI models to data sources such as the Amazon RedShift data lake, the ability to match an AI model to a graph database and a tool that detects bias within AI models.

Bratin Saha, vice president and general manager for machine learning services at AWS, said as usage of AI models increases, the scope of these initiatives naturally lends itself more to cloud platforms. Many applications are starting to employ multiple classes of AI models in combination with each other; Saha noted this requires massive amounts of data and compute resources to train those models that are only readily available in the cloud.

Overall, AWS claims it already has more than 100,000 customers building AI applications on its platform using various tools and processor classes. AWS said in 2021 it will add G4ad Graphics Processing Unit (GPU) instances based on processors from AMD and revealed its intention to build its own GPUs next year. The company also plans to add an Amazon EC2 instance based on up to eight of Intel’s Habana GAUDI accelerators to deliver up to 40% better price-performance than current GPU-based EC2 instances.

At the same time, AWS has extended its alliance with NVIDIA to make software modules for building AI models available on the AWS Marketplace.

In effect, Saha said AWS is inviting IT teams to either build AI models on AWS or bring their own AI models, encapsulated in containers, to its platform.

AWS is clearly aiming to dominate AI, regardless of how such capabilities are infused into enterprise applications. In fact, in many cases, AWS will automatically construct the AI model for customers, or simply return the results generated by an AI model via an application programming interface (API). It will be up to each organization to determine when building their own AI model makes the most sense, and to what degree they want to rely on AWS to automate the deployment process.

What’s certain is that many of the same DevOps principles—created long before AI models ever came along—will still be relevant as the applications that use those models are continuously updated for years to come.

January 4, 2021
AWS Taps Grafana Labs to Launch Managed Observability Service

Amazon Web Services (AWS), in collaboration with Grafana Labs, has added a preview of managed service based on the Grafana observability platform to its portfolio of tools for managing cloud applications and infrastructure.

The Grafana platform is based on an implementation of the open source Prometheus monitoring platform being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). The implementation curated by Grafana Labs is designed to centralize observability across multiple clusters using the same console.

Grafana Labs CEO Raj Dutt said organizations running workloads on AWS can now more easily invoke an observability platform that runs on the same cloud platform on which they have deployed application workloads.

In addition, Dutt noted IT organizations running workloads on AWS can seamlessly upgrade to Grafana Enterprise, which can pull information from third-party data from platforms including ServiceNow, Splunk, Snowflake, Datadog, MongoDB, Oracle, New Relic, Dynatrace, Wavefront and AppDynamics.

Grafana Labs already offers both an on-premises edition of its platform in addition to a software-as-a-service edition. The edition that AWS is running provides access to an observability platform for applications running on AWS platforms. Organizations that want to apply the Grafana Labs platform to manage applications running on multiple platforms would employ the existing offerings available from Grafana Labs.

The company also earlier this year added a distributed tracing platform dubbed Grafana Tempo that makes it possible to leverage existing object storage platforms and services to analyze traces. Grafana Labs also rolled out version 2.0 of Loki, which normalizes different structured, unstructured or JSON log formats in a way that allows DevOps teams to extract additional labels as well as enable additional filtering and grouping.

In general, interest in observability is on the rise in direct proportion to the rate at which IT environments are becoming more complex. As more microservices-based applications are deployed, the level of dependency between them starts to increase exponentially. Attempting to correlate data generated by multiple monitoring tools is next to impossible, so IT organizations are starting to shift toward observability platforms that unify the collection of application and infrastructure metrics in a way that provides more context.

Competition among providers of these platforms is already fierce, so the alliance with AWS is a notable endorsement of the approach being pursued by Grafana Labs. Less clear is to what degree IT teams will be replacing many of their existing monitoring tools once observability platforms are deployed more widely. Most existing monitoring tools are optimized for a specific class of infrastructure or application; in many cases, eliminating the licensing fees for those platforms would pay for the cost of standardizing on a single observability platform.

Regardless of the path chosen, the way IT is managed is fundamentally changing. Each IT organization will need to adjust their IT management processes to keep pace with the rate at which IT is now becoming more complex. In fact, the next big issue may not be choosing which observability platform to select as much as it is navigating the profound changes to the internal IT culture that are sure to follow.

December 23, 2020
Sentry Extends Application Performance Monitoring Tool

Sentry this week announced it has added support for applications that employ serverless computing frameworks as well as the Google Web Vitals service to its application monitoring tool.

Company CEO Milin Desai said incorporating Google Web Vitals metrics into Sentry Performance Monitoring will become crucial as Google makes good on a pledge to rank websites and applications on its search engine based on the metrics it collects via this service.

Google Web Vitals determines how fast an application is by monitoring how fast a site presents user interface objects. By coupling Web Vitals with transaction data gathered by Sentry, it becomes possible for developers to correlate how a transaction may be adversely impacting the user experience. That data then can be employed to adjust what application programming interfaces (APIs) should be called within an application, Desai said.

At the same time, he noted a larger percentage of developers are starting to employ serverless computing frameworks within the front end of their applications. The Sentry platform now monitors serverless computing frameworks that are employed within a PHP, Node and Ruby-based application. Most of those frameworks are being used to trigger a specific action when some type of event occurs within an application, said Desai.

Finally, Sentry has also added a Trends view that enables developers to see the most improved and most regressed transactions that have occurred over time. That capability enables developers to more easily determine when changes to the overall IT environment are adversely impacting their applications. Armed with that data, it then becomes easier to identify what changes were made at that time.

In general, Desai said there is not enough focus on enabling observability for application developers versus IT operations teams. Sentry Performance Monitoring is designed to enable developers to correlate specific events occurring within their code to actual end user experiences by adding five lines of code to their applications.

Observability tools for developers will not obviate the need for observability tools for IT operations teams, but Desai noted as far as visibility into applications is concerned, most developers today are flying blind. Observability is supposed to be a core tenet of any DevOps practice. However, the level of observability actually being achieved tends to vary widely among IT organizations.

Of course, the best place to solve any issue is going to be within the application code, whenever possible. Many developers could eliminate performance issues long before many IT operations teams realize they exist if they had more visibility into how code was executing. That issue will become all the more pressing as IT organizations deploy applications based on microservices that have many dependencies.

The challenge IT organizations face now is determining not only which observability platforms to employ, but also what level of visibility is required for all the different roles and personas that make up that team.

December 23, 2020
CentOS Rebellion Against Red Hat Gains Momentum

Two insurgent efforts to make sure the CentOS distribution remains viable have been launched following a decision by Red Hat to no longer invest in that fork of the Red Hat Enterprise Linux (RHEL) distribution.

Launched in 2006, CentOS is widely employed by IT organizations that need an open source distribution of Linux to, for example, deploy a web server. Red Hat gained control over the CentOS trademark in 2014 as the primary sponsor of the project. Starting next year, Red Hat will only support CentOS Stream, which provides IT teams with a “rolling preview” of capabilities the company plans to make available on RHEL. Both RHEL and CentOS Stream are available via a subscription from Red Hat.

The backlash to that announcement has been swift. Gregory Kurtzer, one of the co-founders of CentOS, has launched Rocky Linux with the support of more than 650 contributors to make sure IT organizations have access to a distribution of a fork of RHEL that doesn’t require a subscription.

Kurtzer said many of those contributors work at independent software vendors (ISVs) that would prefer to see forks of RHEL continue to be available to their customers. Ultimately, the goal will be to add new capabilities to a Linux distribution in a more agile manner than what has occurred under the stewardship of Red Hat, added Kurtzer.

At the same time, CloudLinux is pledging to spend $1 million annually to create a distribution of Linux dubbed Project Lenix that is also based on a fork of RHEL. CloudLinux has previously provided a hardened edition of CentOS that has been installed more than 200,000 times by 4,000-plus customers.

CloudLinux CEO Igor Seletskiy noted the only other existing RHEL-compatible distribution of Linux is Oracle Linux. However, given Oracle’s stewardship of the open source MySQL and database, and the way the transition to open source editions of Java technologies has progressed, Seletskiy said there are many in the open source community who would prefer an alternative.

As for the Rocky Linux effort, Seletskiy said Project Lenix not only will appear sooner but also IT teams will be able to convert entire fleets of servers over to it via a single command with no reinstallation or reboot required.

Red Hat can do little to quell these initiatives because RHEL itself is based on open source code that anyone can employ to create a separate distribution. It’s not clear what impact this nascent rebellion will have on the ability of Red Hat to further monetize RHEL; however, it does illustrate how difficult it really is for a provider of any open source code to maintain control over the community that evolves around a given project.

Many contributors to these projects are also becoming resentful of vendors that productize their efforts by converting open source software into, for example, a cloud service or subscription service that goes on to be the dominant means through which open source software is consumed. As a result, there is increased pressure for vendors to find a way to better reward contributors to these projects. Initiatives such as Rocky Linux and Project Lenix are clearly tapping into an egalitarian spirit within the open source community that runs counter to the way some vendors monetize these initiatives.

It’s not clear to what degree these two efforts might inspire other revolts based on forks of open source code. However, it’s clear that the stewards of the primary open source project may not be the complete masters of their domain regardless of who may own the trademark for a specific distribution.

December 21, 2020