Author name: ITMAITY

Learn how managed services, part of the Open Telecom Transformation Program, help CSPs get the most value from transformation.   ​  ​Learn how managed services, part of the Open Telecom Transformation Program, help CSPs get the most value from transformation. Telecommunications Blog | Dell

Ensure business continuity with fast, secure data replication powered by Dell Connectrix B-Series solutions.   ​  ​Ensure business continuity with fast, secure data replication powered by Dell Connectrix B-Series solutions. PowerStore Blog | Dell

Today, we are taking the next step in strengthening our European Digital Commitments to empower our customers with greater choice, more control over their data privacy and the most robust digital resilience we have ever offered. Building on our 42-year history as a company in Europe, we are expanding our efforts with Microsoft Sovereign Cloud. This offer spans both public cloud and private digital infrastructure, ensuring our customers can choose the right balance of control, compliance and capability for their needs. With this expanded offering we are announcing Data Guardian for European operations, External Key Management for customer-controlled encryption, Regulated Environment Management for simplified configuration and Microsoft 365 Local for critical productivity services in private cloud environments. This brings together comprehensive productivity, security and cloud solutions designed to enable European organizations to grow, compete and lead on their own terms and with more control than ever before across Sovereign Public Cloud, Sovereign Private Cloud and National Partner Clouds. Building on our experience delivering sovereignty solutions that meet the needs of highly regulated customers and government agencies, our Sovereign Public Cloud is an evolution and expansion of the Microsoft Cloud for Sovereignty and will be offered across all existing European datacenter regions, for all European customers, across enterprise services such as Microsoft Azure, Microsoft 365, Microsoft Security and Power Platform. Sovereign Public Cloud ensures customer data stays in Europe, under European Law, with operations and access controlled by European personnel, and encryption is under full control of customers. This is enabled for all customer workloads running in our European datacenter regions requiring no migration. Microsoft’s new Sovereign Private Cloud will support critical collaboration, communication and virtualization services workloads on Azure Local. This solution now integrates Microsoft 365 Local and our security platform with Azure Local, providing consistent capabilities for hybrid or air-gapped environments to meet resiliency and business continuity requirements. In France and Germany, our National Partner Clouds offer comprehensive capabilities of Microsoft 365 and Microsoft Azure in an independently owned and operated environment. In France, we have an agreement with Bleu, a joint venture between Orange and Capgemini, for Bleu to operate a “cloud de confiance” for the French public sector, critical infrastructure providers and essential services providers that is designed to meet SecNumCloud requirements. In Germany, we have an agreement with Delos Cloud, an SAP subsidiary, for Delos Cloud to operate a sovereign cloud for the German public sector that is designed to meet the German government’s Cloud Platform Requirements. Across our Sovereign Public Cloud, Sovereign Private Cloud and support for National Partner Clouds, Microsoft Sovereign Cloud offers the most comprehensive set of sovereignty solutions in the industry for integrated productivity, security and cloud. Sovereign Public Cloud for all Microsoft Cloud customers in Europe Many technology providers have approached sovereignty as niche requirements for a unique set of customers that require a specific deployment approach that at times is at odds with the economics and innovation of public cloud systems. This often requires running duplicate systems and teams, migrating to separate environments and limiting access to cutting-edge technologies like AI. However, Microsoft’s Sovereign Public Cloud builds an evolving set of sovereign capabilities that can be configured to meet specific needs without sacrificing functionality or requiring migration to specialized datacenters. With Microsoft’s Sovereign Public Cloud currently in preview and set to be generally available in all European cloud regions later this year, we will introduce new features and solutions that reinforce this vision. Announcing Data Guardian Our EU Data Boundary already provides an industry-leading commitment to store and process your data on infrastructure located in Europe. Data Guardian will add an additional level of assurance by ensuring that only Microsoft personnel residing in Europe control remote access to these systems. Data Guardian adds additional human and technical oversight whenever engineers outside of Europe need access. All remote access by Microsoft engineers to the systems that store and process your data in Europe is approved and monitored by European resident personnel in real time and will be logged in a tamper-evident ledger. Announcing External Key Management to extend Azure Managed HSM Encryption under the full control of customers provides an additional guarantee of data protection. With external key management, customers can connect Azure to keys stored on their own Hardware Security Module (HSM) on-premises or hosted by a trusted third party. We’re working with major HSM manufacturers such as Futurex, Thales and Utimaco to ensure their support. Announcing Regulated Environment Management The Regulated Environment Management service will allow customers to easily manage all these features in one place (for instance, configuring Data Guardian policies or reviewing access log entries). Regulated Environment Management will be at the center of the customer experience for configuring, deploying and monitoring workloads in support of sovereign operations. Together, these tools will be at the center of the customer experience for configuring, deploying and monitoring workloads in the Sovereign Public Cloud. Sovereign Private Cloud with Azure Local and Microsoft 365 Local While strengthening sovereign controls in public cloud environments is critical, we also understand that some scenarios require certain workloads be run in a physical environment under full customer control to support business continuity risk mitigation. Azure Local delivers Microsoft cloud services in customer locations, enabling organizations to meet specific data residency and sovereignty requirements. It includes core Azure capabilities — such as compute, storage, networking and virtualization services — while providing a consistent management and developer experience. Azure Local is ideal for delivering services closer to where data is generated or regulated, whether in-country, on-premises or in partner-operated datacenters. Microsoft’s Sovereign Private Cloud solution is in preview today and will be generally available later this year. Announcing Microsoft 365 Local Microsoft 365 Local provides customers with additional choice by bringing together Microsoft’s productivity server software into an Azure Local environment that can run entirely in a customer’s own datacenter. This provides a simplified deployment and management framework for organizations to run Microsoft’s trusted productivity servers in environments they fully control. Built on our validated reference

Welcome to the next episode in our GitHub for Beginners series, where we’re diving into the world of GitHub Copilot. This is our eighth and final episode, and it’s been quite a journey. We’ve covered a lot of different topics showcasing the power of GitHub Copilot, and you can check out all our previous episodes on our blog or as videos. Today we’re covering that important step of code review—getting a second pair of eyes on your code. This can help catch bugs, improve code quality, and ensure consistency. We’ll also talk about refactoring code—restructuring existing code without changing its functionality. This can make things more efficient or more readable for those who need to understand it later (even if that’s yourself). In any development project, maintaining a clean and efficient codebase is crucial to make future work easier. But in reality, things can quickly become messy as you’re focused on making it work. That’s where Copilot can come in handy. It doesn’t just assist you in writing code, it also makes the review and refactoring process smoother and more efficient. For the demos in this series, we’re using GitHub Copilot in Visual Studio Code Copilot is available in other IDEs, but the available functionality may vary depending on your environment. Refactoring code Suppose that you have a function that is long and difficult to understand. Refactoring code can make it easier to understand and ensure pieces of it aren’t too unwieldy to follow. To use GitHub Copilot to help you with this refactoring task, open up Copilot Chat and do the following: Highlight the function you want to refactor in your code editor. In Copilot Chat, send the prompt please provide refactoring suggestions. Review the changes that Copilot suggests. It might break the code up into smaller pieces or optimize the logic for better performance. It might even update variable names to be aligned with your naming conventions. Once you’re comfortable with the suggested changes, click the Apply in editor button to apply the changes and have Copilot automatically update the file. This works well for small changes, but there’s no reason to stop there. This is just if you want to focus Copilot’s attention on a specific area of your code. You can also have it look across entire files or your project. For example, take a look at this dashboard component. Let’s say you want to improve it. To do so, open up the component in your editor and send Copilot Chat the following prompt: How can I improve this code? Copilot will then give several suggestions on ways the code can be improved. You can review these suggestions and even ask Copilot to explain each step in greater detail. When you’re finished, click the Apply in editor button to have Copilot make the necessary changes. To see this in action, check out the video version of this episode. Just remember that since Copilot is a generative AI tool, the suggestions you see might not match those in the video exactly. You can take this a step further by asking specific and direct questions. For example, you might want to make the data fetching logic reusable across components by creating a custom hook and centralizing the logic. To do this, create a new chat conversation and ask it the following: How can I extract the data fetching logic into a custom hook? Copilot generates refactored code that allows you to extract the logic out of the Dashboard component into a new hook directory that you can use in multiple components in the app. This makes it much more reusable! To follow through on this: Save the changes in a new file by selecting … > Insert into New File. Import the hook into the dashboard file. Remove the old code. Now what if you wanted Copilot to take a look and make sure you didn’t have a bunch of redundant code in your file? Just ask it. Is there any redundant code in this file? Copilot scans your code and identifies any redundancies that can be corrected. After reviewing the suggestions, go ahead and apply them to tighten up your code and make it a bit cleaner. Reviewing and refactoring your code with GitHub Copilot is a great way to do an initial overview of the work you’ve done. You can also ask Copilot for performance improvement suggestions, how to make functions more modular, have it add comments, or upgrade syntax to be more modern. If you can think of a question, ask Copilot and see what it can do. Code reviews in github.com If you have the proper access, you can also get GitHub Copilot code reviews directly on github.com to make the process even more seamless. First, open up a pull request. Under the “Reviewers” section in the top-right corner, you’ll notice Copilot listed as a possible reviewer. Click Request to have Copilot review your code. Once Copilot finishes the review, scroll down on the pull request to see any suggestions that it makes. It’s important to note that Copilot always leaves a Comment review, and never an Approve or Request changes review. This means that Copilot’s reviews will never be required nor block merges. To accept any of Copilot’s suggestions, click Commit suggestion at the bottom of the specific suggestion you’d like to integrate. This pulls up a context menu. Click Commit changes and GitHub will update your pull request with that change. You can also batch several suggested changes by clicking the Add to batch button under individual suggestions so they are pulled into one change. After you’ve integrated any suggestions and made any changes, you can request another review from Copilot by clicking the circular arrows in the “Reviewers” box next to Copilot’s name. With Copilot code review, you can have Copilot perform a preliminary review of your code before asking your team for that final code review.  Key components and limitations The key components of using Copilot for code review

In my spare time I enjoy building Gundam models, which are model kits to build iconic mechas from the Gundam universe. You might be wondering what this has to do with software engineering. Product engineers can be seen as the engineers who take these kits and build the Gundam itself. They are able to utilize all pieces and build a working product that is fun to collect or even play with! Platform engineers, on the other hand, supply the tools needed to build these kits (like clippers and files) and maybe even build a cool display so everyone can see the final product. They ensure that whoever is constructing it has all the necessary tools, even if they don’t physically build the Gundam themselves. About a year ago, my team at GitHub moved to the infrastructure organization, inheriting new roles and Areas of Responsibility (AoRs). Previously, the team had tackled external customer problems, such as building the new deployment views across environments. This involved interacting with users who depend on GitHub to address challenges within their respective industries. Our new customers as a platform engineering team are internal, which makes our responsibilities different from the product-focused engineering work we were doing before. Going back to my Gundam example, rather than constructing kits, we’re now responsible for building the components of the kits. Adapting to this change meant I had to rethink my approach to code testing and problem solving. Whether you’re working on product engineering or on the platform side, here are a few best practices to tackle platform problems. Understanding your domain One of the most critical steps before tackling problems is understanding the domain. A “domain” is the business and technical subject area in which a team and platform organization operate. This requires gaining an understanding of technical terms and how these systems interact to provide fast and reliable solutions. Here’s how to get up to speed:  Talk to your neighbors: Arrange a handover meeting with a team that has more knowledge and experience with the subject matter. This meeting provides an opportunity to ask questions about terminology and gain a deeper understanding of the problems the team will be addressing.  Investigate old issues: If there is a backlog of issues that are either stale or still persistent, they may give you a better understanding of the system’s current limitations and potential areas for improvement. Read the docs: Documentation is a goldmine of knowledge that can help you understand how the system works.  Bridging concepts to platform-specific skills While the preceding advice offers general guidance applicable to both product and platform teams, platform teams — serving as the foundational layer — necessitate a more in-depth understanding. Networks: Understanding network fundamentals is crucial for all engineers, even those not directly involved in network operations. This includes concepts like TCP, UDP, and L4 load balancing, as well as debugging tools such as dig. A solid grasp of these areas is essential to comprehend how network traffic impacts your platform. Operating systems and hardware: Selecting appropriate virtual machines (VMs) or physical hardware is vital for both scalability and cost management. Making well-informed choices for particular applications requires a strong grasp of both. This is closely linked to choosing the right operating system for your machines, which is important to avoid systems with vulnerabilities or those nearing end of life. Infrastructure as Code (IaC): Automation tools like Terraform, Ansible, and Consul are becoming increasingly essential. Proficiency in these tools is becoming a necessity as they significantly decrease human error during infrastructure provisioning and modifications.  Distributed systems: Dealing with platform issues, particularly in distributed systems, necessitates a deep understanding that failures are inevitable. Consequently, employing proactive solutions like failover and recovery mechanisms is crucial for preserving system reliability and preventing adverse user experiences. The optimal approach for this depends entirely on the specific problem and the desired system behavior. Knowledge sharing By sharing lessons and ideas, engineers can introduce new perspectives that lead to breakthroughs and innovations. Taking the time to understand why a project or solution did or didn’t work and sharing those findings provides new perspectives that we can use going forward. Here are three reasons why knowledge sharing is so important:  Teamwork makes the dream work: Collaboration often results in quicker problem resolution and fosters new solution innovation, as engineers have the opportunity to learn from each other and expand upon existing ideas. Prevent lost knowledge: If we don’t share our lessons learned, we prevent the information from being disseminated across the team or organization. This becomes a problem if an engineer leaves the company or is simply unavailable. Improve our customer success: As engineers, our solutions should effectively serve our customers. By sharing our knowledge and lessons learned, we can help the team build reliable, scalable, and secure platforms, which will enable us to create better products that meet customer needs and expectations! But big differences start to appear between product engineering and infrastructure engineering when it comes to the impact radius and the testing process. Impact radius With platforms being the fundamental building blocks of a system, any change (small or large) can affect a wide range of products. Our team is responsible for DNS, a foundational service that impacts numerous products. Even a minor alteration to this service can have extensive repercussions, potentially disrupting access to content across our site and affecting products ranging from GitHub Pages to GitHub Copilot.  Understand the radius: Or understand the downstream dependencies. Direct communication with teams that depend on our service provides valuable insights into how proposed changes may affect other services. Postmortems: By looking at past incidents related to our platform and asking “What is the impact of this incident?”, we can form more context around what change or failure was introduced, how our platform played a role in it, and how it was fixed. Monitoring and telemetry: Condense important monitoring and logging into a small and quickly digestible medium to give you the general health of the system.

Learn how to maximize the value of your Dell AI PCs by understanding a straightforward AI PC software strategy.   ​  ​Learn how to maximize the value of your Dell AI PCs by understanding a straightforward AI PC software strategy. Artificial Intelligence Blog | Dell

Dell, NVIDIA and Mistral AI will work together to develop integrated AI solutions that offer streamlined data processing for demanding AI workloads.   ​  ​Dell, NVIDIA and Mistral AI will work together to develop integrated AI solutions that offer streamlined data processing for demanding AI workloads. Artificial Intelligence Blog | Dell

At Dell Technologies World this year, the spotlight was on the next wave of innovation. Breakout sessions took a deep …   ​  ​At Dell Technologies World this year, the spotlight was on the next wave of innovation. Breakout sessions took a deep … PowerScale Blog | Dell

Are you facing challenges with telecom cloud operations? Learn how Dell’s Support & Adoption services help CSPs overcome barriers and drive transformation.   ​  ​Are you facing challenges with telecom cloud operations? Learn how Dell’s Support & Adoption services help CSPs overcome barriers and drive transformation. Cloud Transformation Blog | Dell

Simplified, secure and scalable solutions to accelerate your AI innovation.   ​  ​Simplified, secure and scalable solutions to accelerate your AI innovation. AI Solutions Blog | Dell

Nokia powers KDDI Policy & Charging with OTEL, Red Hat, & Intel, driving innovation and collaboration forward.   ​  ​Nokia powers KDDI Policy & Charging with OTEL, Red Hat, & Intel, driving innovation and collaboration forward. Telecommunications Blog | Dell

Discover how Miguel Ortega uses Dell Pro Max to push animated horror films beyond limits.   ​  ​Discover how Miguel Ortega uses Dell Pro Max to push animated horror films beyond limits. Dell Pro Max Blog | Dell

Welcome to the next episode in our GitHub for Beginners series, where we’re diving into the world of GitHub Copilot. We’re now on our seventh episode, and we’ve covered quite a lot of ground. You can check out all our previous episodes on our blog or as videos. Today we’re going to dive into the world of testing, a much needed but historically tedious part of the development process. This is especially true as our codebase becomes larger and more complex. Fortunately, we can use GitHub Copilot to help automate some of this process. After all, one of the most basic questions we have when writing code is: “Does it work?” For the demos in this series, we’re using GitHub Copilot in Visual Studio Code. Copilot is available in other IDEs, but the available functionality may vary depending on your environment. Testing 101 Before we jump into how to use GitHub Copilot to write some tests, we should talk about testing, why it’s important, and different ways to test your code. Be aware that test testing is a very deep topic, and we’ll only be touching the surface here. Covering the nuances of testing would be an entire course in and of itself. So why is testing important? In short, it’s how you make sure that your code does what you expect. Testing can take many different forms, such as: Acceptance tests: Tests that ensure your app meets a set of defined functionality. Integration tests: Tests that verify your app can talk across various systems such as databases and APIs. Unit tests: Tests focused on breaking the code into small, isolated pieces called units. These make sure the individual units do exactly what you’d expect them to do. Writing unit tests As we just covered, unit tests work by breaking down your code into smaller chunks that are easier to test. Making sure each individual piece is doing what it’s supposed to do increases confidence that the entire app will work when you put all the pieces together. One of the great things about unit tests is that you can automate the process. Once you’ve created a large battery of tests, you can literally run thousands of tests with a single command. This gives you a good indicator regarding the health of your application. By regularly running these tests, you’ll also discover if any changes to your code broke something you might not have been expecting. So how do you use GitHub Copilot to create some unit tests? Open up your code and highlight a section that you want to test. For example, you might highlight a specific function. Open up Copilot Chat. You might notice that Copilot suggests using the /tests slash command to write tests. Send Copilot the following prompt: /tests add unit tests for my code If Copilot asks if you want to configure a test framework, select Dismiss. Review the plan and code suggestions to make sure you understand what changes Copilot is going to make. Click the Add to new file button at the top of the code suggestion to create the tests. Save the new file. Run the tests by running the following command in your terminal: python -m pytest Congratulations! You just added some unit tests to your code! If you’d like to see a demo of this in action, make sure to watch the video! Test-driven development Now that you’ve seen how to write some unit tests, let’s talk a little bit about test-driven development (TDD). What exactly is TDD? It’s a process where you use the tests to drive how you develop your code. When using TDD, you write your tests first, and then create the implementation afterward. The process takes a little bit of adjusting how you think about development, but it does come with several advantages. It gives you the opportunity to see how your code will behave and ensure the tests you’re writing are testing what you expect them to test.  A concept that can be helpful for wrapping your brain around this is called “red, green, refactor.” In this process, you create the tests first, and they fail. They might not even build! This is the red stage. Then you write just enough code to get your tests to pass. For example, if you’re writing a test that makes sure an error is thrown if a number is less than 0, you write just enough code to throw that error on that condition. When you return to the test, it now passes. You’ve actively made a change to the codebase to implement the desired functionality. This is the green stage.  Finally, you implement any refactoring to make the code look good. Now that it works, you can focus on making it pretty. The entire time you are working on this, you keep running the unit tests to make sure your changes don’t break anything. As you probably guessed, this is the refactor stage. GitHub Copilot can help you with TDD. It’s one of the hidden little tricks that Copilot is able to do—you can tell it code will exist and generate tests based on that information. For example, if you were working on an email validation app, you could send the following prompt to Copilot Chat: I’m going to be adding a new validator function for usernames. Usernames must be between 3 and 16 characters, start with a letter or an underscore, not use multiple underscores to start, and after the first character chan have letters, numbers, and underscores. Just create the new test functions. This prompt provides the criteria that you’re expecting and gives it to Copilot. Copilot will then use this prompt to generate unit tests to test that functionality. If you ran these tests, they would fail, because you’ve only created the tests. Red stage. Now, to move on to the green stage, you could send Copilot the following prompt: Create the implementation Copilot will now generate the code to make sure these

For over a decade, GitHub has offered enterprise authentication using SAML (Security Assertion Markup Language), starting with our 2.0.0 release of GitHub Enterprise Server in November 2014. SAML single sign-on (SSO) allows enterprises to integrate their existing identity providers with a broad range of GitHub products, extend conditional access policies, and bring enterprise organization management to GitHub. To ship this feature, we had to build and maintain support for the SAML 2.0 specification, which defines how to perform authentication and establish trust between an identity provider and our products, the service provider. This involves generating SAML metadata for identity providers, generating SAML authentication requests as part of the service provider–initiated SSO flow, and most importantly, processing and validating SAML responses from an identity provider in order to authenticate users. These code paths are critical from a security perspective. Here’s why:  Any bug in how authentication is established and validated between the service and identity providers can lead to a bypass of authentication or impersonation of other users.  These areas of the codebase involve XML parsing and cryptography, and are dependent on complex specifications, such as the XML Signature, XML Encryption, and XML Schema standards.  The attack surface of SAML code is very broad, so the data that is validated for authentication and passed through users’ (and potential attackers’) browsers could be manipulated.  This combination of security criticality, complexity, and attack surface puts the implementation of SAML at a higher level of risk than most of the code we build and maintain. Background When we launched SAML support in 2014, there were few libraries available for implementing it. After experimenting initially with ruby-saml, we decided to create our own implementation to better suit our needs.  Over the years since, we have continually invested in hardening these authentication flows, including working with security researchers both internally and through our Security Bug Bounty to identify and fix vulnerabilities impacting our implementation.  However, for each vulnerability addressed, there remained lingering concerns given the breadth and complexity of root causes we identified. This is why we decided to take a step back and rethink how we could move forward in a more sustainable and holistic manner to secure our implementation. So, how do you build trust in a technology as complex and risky as SAML?  Last year, this is exactly the question our engineering team set out to answer. We took a hard look at our homegrown implementation and decided it was time for change. We spent time evaluating the previous bounties we’d faced and brainstormed new ideas on how to improve our SAML strategy. During this process, we identified several promising changes we could make to regain our confidence in SAML.  In this article, we’ll describe the four key steps we took to get there: Rethinking our library: Evaluating the ruby-saml library and auditing its implementation Validating the new library with A/B testing: Building a system where we could safely evaluate and observe changes to our SAML processing logic Schema validations and minimizing our attack surface: Reducing the complexity of input processing by tightening schema validation Limiting our vulnerability impact: Using multiple parsers to decrease risk Rethinking our library When we reviewed our internal implementation, we recognized the advantages of transitioning to a library with strong community support that we could contribute to alongside a broader set of developers.  After reviewing a number of ruby SAML libraries, we decided to focus again on utilizing the ruby-saml library maintained by Sixto Martín for a few reasons:  This library is used by a number of critical SaaS products, including broad adoption through its usage in omniauth-saml. Recent bugs and vulnerabilities were being reported and fixed in the library, showing active maintenance and security response.  These vulnerabilities and fixes were distributed through the GitHub Advisory Database and CVEs, and had updates pushed through Dependabot, which integrates well with our existing vulnerability management processes.  This support and automation is something we wouldn’t be able to benefit from with our own internal implementation. But moving away from our internal implementation wasn’t a simple decision. We had grown familiar with it, and had invested significant time and effort into identifying and addressing vulnerabilities. We didn’t want to have to retread the same vulnerabilities and issues we had with our own code.  With that concern, we set out to see what work across our security and engineering teams we could do to gain more confidence in this new library before making a potential switch. In collaboration with our bug bounty team and researchers, our product security team, and the GitHub Security Lab, we laid out a gauntlet of validation and testing activities. We spun up a number of security auditing activities, worked with our VIP bug bounty researchers (aka Hacktocats) who had expertise in this area (thanks @ahacker1) and researchers on the GitHub Security Lab team (thanks @p-) to perform in-depth code analysis and application security testing.  This work resulted in the identification of critical vulnerabilities in the ruby-saml library and highlighted areas for overall hardening that could be applied to the library to remove the possibility of classes of vulnerabilities in the code. But is security testing and auditing enough to confidently move to this new library? Even with this focus on testing, assessment, and vulnerability remediation, we knew from experience that we couldn’t just rely on this point-in-time analysis.  The underlying code paths are just too complex to hang our hat on any amount of time-bound code review. With that decision, we shifted our focus toward engineering efforts to validate the new library, identify edge cases, and limit the attack surface of our SAML code. Validating the new library with A/B testing GitHub.com processes around one million SAML payloads per business day, making it the most widely used form of external authentication that we support. Because this code is the front door for so many enterprise customers, any changes require a high degree of scrutiny and testing.  In order to preserve the stability of our SAML processing code

From solo projects to major frameworks, open source maintainers are doing the work of many, for many—oftentimes without guaranteed funding. Thankfully, programs like GitHub Sponsors can make a critical difference in the long-term health of a project. But what makes an open source project attractive to sponsors?  We asked a few internal experts to analyze eight funded open source projects on GitHub. We then used that information to identify patterns and insights that could help maintainers and contributors understand what drives sponsorships in open source. The answer isn’t one-size-fits-all, but the most successful projects tend to get several of these right. With Maintainer Month well underway, our GitHub panel is a bit slimmer this month, but it includes:  Abigail Cabunoc Mayes, aka @abbycabs, who works on open source maintainer programs and serves on the board of the OpenJS foundation.  Kevin Crosby, aka @kevincrosby, who runs GitHub’s open source funding program.  Jeff Luszcz, aka @jeffrey-luszcz, who helps manage GitHub’s open source program office (OSPO). Below, we’ll highlight some of these projects—and break down the trends that make them stand out in today’s evolving open source landscape.  Top trends, at a glance In this analysis, we saw that projects that accomplish the following tend to receive funding:  Community engagement drives success: Projects with passionate user bases that value both the maintainers and the project. Projects that solve specific pain points can build powerful communities: Solving difficult or niche problems in unique ways unlocks value for the user. User-facing tools and packaging often get more visibility: Packaging tools or “products” that developers and members interact with daily. In contrast, foundational infrastructure projects that power these tools can struggle for visibility and funding, despite being essential to the ecosystem. Offer value in other ways that matter: Projects offering clear value through support contracts, training, memberships, or other services. Get the full analysis > 1. Ladybird: the open source web browser 🦅 Website Source C++ HTML JavaScript CMake Objective-C++ Swift 📜 BSD 2-Clause License Started by the former maintainer of SerenityOS and funded by one of the cofounders of GitHub (Chris Wanstrath, aka @defunkt), Ladybird is an independent, cross-platform web browser being built from scratch in C++/Swift that ships its own LibWeb rendering and LibJS JavaScript engines.  The project’s 501(c)(3) Ladybird Browser Initiative rejects ad deals and search‑engine royalties outright, funding itself only through unrestricted donations. That “no strings attached” stance resonates with privacy‑minded companies and individuals. Ladybird uses a sandboxed multi-process architecture and targets Linux, macOS, and other Unix-like systems—aiming to offer a modern, standards-compliant alternative that relies on zero Chromium or Gecko code. Why it matters Ladybird is a perfect example of values-based funding. Kevin expands on this: “There’s a desire among people for less data collection via web browsers and search engines, and Ladybird offers an untracked web experience.” Tapping into users’ values—like privacy, independence, or ethical tech—can motivate sponsorship beyond just technical features.  “This is a huge deal,” Kevin says. “The dream of an OSS web browser is one that a lot of people are ready to buy into. People are willing to pay not to have their data sold—data integrity is super valuable.” Ladybird also benefited from a strong “founder effect”: it was launched by well-known developers in the open source community, which helped it quickly attract attention and funding. Abigail speaks to this: “Projects started by well-known community members can gain momentum and financial backing much faster than those building an audience from scratch. While most projects in this list took years to build their funding community, Ladybird leveraged its founders’ reputations from day one.” 2. Neovim: the editor that inspires devotion ✍️ Website Source Vim Script Lua C CMake Python Shell 📜 Apache 2.0 License Neovim is a modern reimagining of the classic Vim text editor, designed to enhance extensibility, maintainability, and user experience. Launched in 2014, it introduces features like built-in Language Server Protocol (LSP) support, asynchronous I/O, and Lua scripting capabilities, all while maintaining compatibility with most of Vim’s features .  By swapping Vim‑script internals for an embedded Lua runtime, asynchronous job control, and a remote‑UI RPC API, Neovim can act as:  A terminal‑first IDE with built‑in LSP, Tree‑sitter syntax trees, an embedded terminal, and virtual‑text/inline‑diagnostics, An embeddable component inside other apps, or A headless background process that multiple GUIs attach to. Neovim has also cultivated a thriving ecosystem. Their delightful collection of plugins has become a major part of its appeal and funding story, offering developers highly customizable experiences out of the box. Why it matters Neovim perfectly captures maybe the strongest funding pattern we’ve seen: developers will pay to support tools they use every single day and that have become a part of their identity. Jeff gets it: “People are passionate about their text editors. And developers love Neovim because it continues to improve things.” Kevin continues: “A common thing is that tools that are more user facing get more funding because they’re more top of mind—whereas tools that are lower in the stack don’t get as much visibility. People really care about their text editors and identify with their editor.” 3. RunAsUser: system privileges made simple 🔑 Source PowerShell 📜 MIT License Kelvin Tegelaar builds multiple PowerShell modules for his community. RunAsUser is one featured module that lets you launch processes in the security context of the currently-logged-on user—even when the script itself is running as SYSTEM.  That’s handy for Remote Monitoring and Management (RMM) tools, scheduled tasks, or other automations commonly used by system administrators and managed service providers that normally run under the SYSTEM account but occasionally need to interact with resources that only the interactive user can access. Why it matters When you solve a pain point for a specific audience, they’re more likely to back you financially. Kelvin does this by making the lives of Windows system administrators (or sysadmins for short) easier. RunAsUser is a specific example of this.  “The users of this project value the maintainer, Kelvin’s, support,” Kevin says. “It’s not only that the project is