Open Source

67 posts

cloudflare3 min readCurated summary

Powering the agents: Workers AI now runs large models, starting with Kimi K2.5

Cloudflare is expanding Workers AI beyond smaller models by adding Moonshot AI’s Kimi K2.5, a frontier open-source model designed for agentic workloads. With a 256k context window, tool calling, vision, and structured outputs, Kimi can power an agent’s full lifecycle directly on Cloudflare’s platform. Cloudflare argues that its price-performance makes open-source models essential as personal and enterprise agents dramatically increase inference demand. ## Kimi K2.5’s Price-Performance Advantage - Cloudflare uses Kimi internally for: - Agentic coding through OpenCode - Automated code review via the Bonk public code review agent - Security analysis of Cloudflare codebases - A security-review agent processes more than 7 billion tokens daily and has found over 15 confirmed issues in one codebase. - Compared with a mid-tier proprietary model, switching to Kimi reduced the estimated cost of this workload by 77%, from roughly $2.4 million annually. - As employees increasingly run multiple agents continuously, inference costs become a major barrier to scaling. - Cloudflare positions open-source, frontier-quality models as a more economical alternative to proprietary systems. ## Serving Large Models on Workers AI - Supporting Kimi required upgrades to Workers AI’s inference stack, which historically focused on smaller models. - Cloudflare uses its proprietary Infire inference engine and custom kernels to improve: - Model performance - GPU utilization - Throughput - The platform applies advanced serving strategies such as: - Data, tensor, and expert parallelization - Disaggregated prefill, separating input processing from generation across machines - Workers AI handles these infrastructure optimizations so developers do not need specialized machine learning, DevOps, or reliability engineering expertise. ## Prefix Caching for Agent Workloads - Agents frequently resend large prompts containing: - System instructions - Tool definitions - MCP server tools - Conversation history - Entire codebases - Prefix caching avoids reprocessing unchanged input tokens during multi-turn interactions. - This reduces prefill work, improving: - Time to First Token (TTFT) - Tokens Per Second (TPS) - Overall inference cost - Workers AI now exposes cached tokens as a usage metric and charges less for them than regular input tokens. - Cloudflare has also introduced techniques to improve cache hit rates. ## Session Affinity - Workers AI provides an `x-session-affinity` header to route requests from the same session or agent to the same model instance. - Keeping requests on the same instance increases prefix-cache reuse. - Higher cache hit rates lead to faster responses, greater throughput, and lower costs. - Clients should provide a unique session or agent identifier with the header. Cloudflare’s recommendation is to use Workers AI when building agents that need frontier-level reasoning without the cost and operational burden of proprietary models or self-hosted infrastructure.

Read original(opens in new tab)
discord3 min readCurated summary

How ROOST is Advancing Online Safety

Discord argues that online safety should be built through shared, open-source infrastructure rather than isolated corporate systems. Its donated rules engine, Osprey, lets platforms detect suspicious behavior and harmful activity in real time, while ROOST develops and maintains tools for broad industry adoption. Early adoption, including by Bluesky, suggests this model can raise baseline safety standards across the internet. ## The Need for Shared Safety Tools - Nearly 100 million people use Discord daily, generating hundreds of millions of events that must be evaluated for threats. - Generative AI has increased the scale and sophistication of phishing, deepfakes, and coordinated abuse. - Smaller platforms often lack the resources to build effective trust-and-safety systems from scratch. - ROOST aims to make proven safety technologies open, shared, and auditable. ## How Osprey Works - Osprey is a real-time rules engine for event processing and behavioral analysis. - It can evaluate logins, messages, account creation, content posts, and platform-specific actions. - Safety teams write rules in a simple language and deploy them without engineering dependencies. - The engine produces transparent decisions indicating whether activity is safe, suspicious, or malicious. - Discord runs thousands of rules across hundreds of action types. - Investigation findings feed new rules, while enforcement generates additional signals for future detection. - The open-source release is based on Discord’s production system rather than a reduced version; improvements from ROOST were later reintegrated into Discord. ## ROOST’s Collaborative Model - ROOST builds on earlier cross-industry efforts such as image hashing for child-safety work, the Tech Coalition’s Lantern program, GIFCT incident response, and shared ISO safety standards. - Unlike organizations that primarily steward open-source projects, ROOST also develops and maintains a suite of public-interest safety tools. - Its projects include Osprey and Coop, a comprehensive review tool. - Open-source tools can raise the minimum level of protection available to smaller platforms and reduce the spread of threats across services. - The model also enables companies to build managed services around free tools, similar to businesses built around Linux. ## Adoption and Industry Impact - Musubi announced a managed Coop offering, while Zentropi integrated its labeling engine with Coop. - Osprey v1 was introduced at FOSDEM, prompting collaboration among engineers from multiple organizations and protocols. - Platforms such as Bluesky are already using Osprey. - More than 360 million users across participating platforms are now covered by open-source safety tooling. - ROOST continues development through public contributor and adopter working-group meetings held every two weeks. ROOST’s approach suggests that open, production-grade safety infrastructure can help platforms respond faster to emerging threats while creating a shared foundation for industry-wide improvement.

Read original(opens in new tab)
datadog3 min readCurated summary

When an AI agent came knocking: Catching malicious contributions in Datadog’s open source repos

Datadog describes how AI-powered attackers targeted its open-source repositories through malicious issues, pull requests, and comments. The campaign, attributed to the “hackerbot-claw” agent, focused on weaknesses in GitHub Actions and LLM-powered workflows. Datadog’s LLM-based review system and layered CI security controls detected the activity and helped limit its impact, while prompting further hardening. ## Why Open-Source Repositories Attract Attackers - Public repositories are attractive targets because automated CI/CD pipelines often build and execute code from external contributions. - Common attack techniques include: - Injecting user-controlled values, such as PR titles, into workflow scripts. - Using indirect poisoned pipeline execution to introduce malicious dependencies or build instructions. - Abusing `pull_request_target` workflows, which may run untrusted code with elevated permissions. - Prompt-injecting LLM-powered GitHub Actions used for issue triage, labeling, or code assistance. - Attackers may also disguise malicious changes through: - Large or obfuscated diffs. - Invisible Unicode characters. - Malicious libraries. - Imposter commits that resemble legitimate dependency references. ## Datadog’s LLM-Based Contribution Detection - Datadog receives dozens of external PRs each week across projects such as the Agent, tracers, SDKs, Vector, chaos-controller, and Stratus Red Team. - Its BewAIre system monitors GitHub events and selects security-relevant activity, including PRs and pushes. - BewAIre: - Extracts, normalizes, and enriches code diffs. - Sends them through a two-stage LLM pipeline. - Classifies changes as benign or malicious. - Produces a structured explanation for each verdict. - Malicious verdicts are forwarded to Datadog Cloud SIEM, where detection rules create enriched signals for the Security Incident Response Team to investigate. ## Hardening CI and Development Workflows - Datadog reduces the potential impact of successful attacks through multiple preventive controls: - Its `dd-octo-sts-action` generates minimally scoped, short-lived GitHub credentials using OIDC. - Long-lived and overly broad personal access tokens and GitHub Apps are being replaced. - Unused GitHub Actions secrets are identified and removed across thousands of repositories. - Organization-wide controls enforce branch protection, mandatory PR approval, commit signing, and lower-privilege default `GITHUB_TOKEN` permissions. - Engineers are provided with documented best practices and secure “golden paths” for CI development. ## The Hackerbot-Claw Campaign - Modern AI models are increasingly capable of offensive security tasks, especially when given tools, feedback loops, and autonomy. - StepSecurity reported an AI agent attacking open-source CI systems on March 1. - Between February 27 and March 2, the actor: - Opened 16 pull requests. - Created two issues and eight comments. - Targeted nine repositories across six organizations. - The activity was later linked to the hackerbot-claw agent, whose GitHub account was removed. - Datadog’s investigation began after BewAIre alerted the team to a suspicious contribution in the newly public `datadog-iac-scanner` repository on February 27. ## Practical Takeaway Organizations that accept public contributions should combine automated, AI-assisted review with least-privilege credentials, strict workflow permissions, secret management, mandatory approvals, and human incident response. Detection alone is insufficient; CI pipelines should be designed so that a malicious contribution has limited access and minimal opportunity to compromise secrets or production systems.

Read original(opens in new tab)
github3 min readCurated summary

How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework

GitHub Security Lab’s open-source Taskflow Agent uses AI-driven, multi-step auditing workflows to find high-impact vulnerabilities in web applications and open-source projects. The authors report more than 80 vulnerabilities, including authorization bypasses and private-data disclosures, with about 20 already disclosed. They argue that carefully designed taskflows and prompts can give LLMs enough freedom to discover vulnerabilities while reducing hallucinations and false positives. ## Running the Audits - The taskflows are available in the [`seclab-taskflows`](https://github.com/GitHubSecurityLab/seclab-taskflows) repository. - To run an audit: 1. Start a Codespace for the repository. 2. Wait for initialization. 3. Run `./scripts/audit/run_audit.sh myorg/myrepo`. - Audits may take one or two hours on a medium-sized repository. - Results are stored in SQLite and can be inspected in the `audit_results` table. - Rows marked with a check in `has_vulnerability` indicate potential findings. - A GitHub Copilot license and premium model requests are required. - The same repository should be audited multiple times because LLM results are nondeterministic; using different models may reveal different vulnerabilities. - Private repositories require changes to the Codespace configuration to grant access. ## How Taskflows Work - Taskflows are YAML files defining ordered tasks and dependencies for an LLM. - The `seclab-taskflow-agent` runs tasks sequentially and passes their results between stages. - Repository audits begin by dividing the codebase into functional components. - For each component, context is gathered, including: - Untrusted-input entry points - Intended privilege levels - Component purposes and behavior - This context is stored in a database for later auditing tasks. - Separate tasks can: - Suggest generic security issues - Carefully verify each suggested issue - Focus on specific vulnerability classes - Tasks can be reused across many components asynchronously through templated prompts and component-specific substitutions. ## Why Use Multiple Tasks - A single large prompt is less reliable because LLMs may omit steps in complex, multi-stage investigations. - Taskflows help control, debug, and structure the process even when models provide large context windows. - Breaking work into stages allows each result to be reviewed and reused as context for subsequent analysis. - Repeated task execution across components makes the approach scalable for large repositories. ## General Security Auditing - The team initially used the framework to triage CodeQL alerts, where strict instructions and predefined criteria helped limit false positives. - General auditing is more difficult because the LLM must search broadly for vulnerabilities rather than evaluate known alerts. - Greater freedom increases the risk of hallucinations and unexploitable findings. - The authors’ approach uses taskflow design and prompt engineering to preserve a high true-positive rate while allowing the model to investigate diverse security issues. ## Reported Vulnerabilities - The taskflows have found more than 80 vulnerabilities in open-source projects. - Many reported issues are high-impact, including: - Authorization bypasses - Information disclosure - Logging in as another user - Accessing private user data - Examples include exposing personally identifiable information in ecommerce shopping carts and authenticating to a chat application with arbitrary passwords. - The authors manually verify findings before reporting them and maintain an advisories page as disclosures become public. The practical recommendation is to run the open-source taskflows on your own projects, repeat audits with different models, and manually validate every result. The framework is intended to improve through shared taskflows, prompts, and findings across the security community.

Read original(opens in new tab)
meta2 min readCurated summary

Investing in Infrastructure: Meta’s Renewed Commitment to jemalloc

Meta is renewing its commitment to jemalloc, recognizing its long-term role in delivering reliable and efficient infrastructure alongside the Linux kernel and compilers. After acknowledging that short-term decisions created technical debt and slowed development, Meta has unarchived the original repository and begun rebuilding a long-term roadmap. The effort will focus on modernization, reduced maintenance, hardware adaptation, and closer collaboration with the open-source community. ## Why jemalloc Matters - jemalloc is a high-performance memory allocator used as a foundational component of Meta’s software stack. - It has adapted to changing hardware and workloads over time. - Its impact is comparable to other core infrastructure components such as the Linux kernel and compilers. ## Reflecting on Technical Debt - Meta says recent development gradually moved away from the rigorous engineering principles needed for foundational software. - Some changes provided short-term benefits but introduced technical debt. - That debt increased maintenance burdens and slowed future progress. - Community feedback, including discussions with jemalloc founder Jason Evans, prompted Meta to reassess its stewardship. ## Renewed Development Priorities - **Technical debt reduction:** Clean up, refactor, and improve the codebase to make jemalloc more efficient, reliable, and maintainable. - **Huge-page allocation:** Continue improving the hugepage allocator (HPA) and its use of transparent hugepages (THP) to improve CPU efficiency. - **Memory efficiency:** Optimize memory packing, caching, and purging mechanisms. - **AArch64 support:** Improve out-of-the-box performance on ARM64 systems. - **Hardware and workload adaptation:** Continue evolving jemalloc for current and emerging platforms. ## Open-Source Collaboration - The original jemalloc repository has been unarchived. - Meta intends to work with the open-source community on the project’s future. - The company acknowledges that renewed trust must come through measurable improvements and sustained development. - Community members are invited to provide feedback, contributions, and collaboration. Meta’s practical next step is to demonstrate its renewed commitment through code cleanup, performance improvements, and transparent collaboration. The project’s long-term health will depend on consistent execution rather than statements alone.

Read original(opens in new tab)
gitlabOriginal article

What’s new in Git 2.53.0? (opens in new tab)

Git 2.53.0 introduces significant performance and maintenance improvements, specifically targeting large repositories and complex history rewriting workflows. Key updates include compatibility between geometric repacking and partial clones, as well as more granular control over commit signatures during imports. These enhancements collectively move Git toward more efficient repository management and better data integrity for modern development environments. ## Geometric Repacking Support with Promisor Remotes * Git utilizes repacking to consolidate loose objects into packfiles, with the "geometric" strategy maintaining a size-based progression to minimize the computational overhead found in "all-into-one" repacks. * Previously, geometric repacking was incompatible with partial clones because it could not correctly identify or manage "promisor" packfiles, which contain the metadata for objects expected to be backfilled from a remote. * The 2.53.0 release enables geometric repacking to process promisor packfiles separately, preserving the promisor marker and preventing the tool from crashing when used within a partial clone repository. * This fix removes a major blocker for making the geometric strategy the default repacking method for all Git repositories. ## Preserving Valid Signatures in git-fast-import(1) * The `git-fast-import` tool, a backend for high-volume data ingestion and history rewriting, previously lacked the nuance to handle commit signatures during partial repository edits. * A new `strip-if-invalid` mode has been added to the `--signed-commits` option to solve the "all-or-nothing" problem where users had to choose between keeping broken signatures or stripping valid ones. * This feature allows Git to automatically detect which signatures remain valid after a rewrite and only strip those that no longer match their modified commits. * This provides a foundation for tools like `git-filter-repo` to preserve the chain of trust for unchanged commits during migration or cleaning operations. ## Expanded Data in git-repo-structure * The `structure` subcommand of `git-repo`, intended as a native alternative to the `git-sizer` utility, now provides deeper insights into repository scaling. * The command now reports the total inflated size and actual disk size of all reachable objects, categorized by type: commits, trees, blobs, and tags. * These metrics are essential for administrators managing massive repositories, as they help identify which object types are driving disk consumption and impacting performance. These updates reflect Git’s continued focus on scalability and developer experience, particularly for organizations managing massive codebases. Users of partial clones and repository migration tools should consider upgrading to 2.53.0 to leverage the improved repacking logic and more sophisticated signature handling.

kakaoOriginal article

Smarter and More (opens in new tab)

Kakao has released Kanana-2, a high-performance open-source language model specifically engineered to power Agentic AI by enhancing tool-calling and instruction-following capabilities. Surpassing its predecessors and rivaling global frontier models like Qwen3, Kanana-2 offers a versatile suite of variants designed for practical, high-efficiency application in complex service environments. ### Optimized Model Lineup: Base, Instruct, and Thinking * **Kanana-2-30b-a3b-base:** Provided as a foundational model with pre-training weights, allowing researchers to fine-tune the model using their own datasets. * **Kanana-2-30b-a3b-instruct:** A version optimized through post-training to maximize the model's ability to follow complex user instructions accurately. * **Kanana-2-30b-a3b-thinking:** Kakao’s first reasoning-specialized model, designed for tasks requiring high-level logical thinking, such as mathematics and coding. ### Strengthening Agentic AI Capabilities * **Tool Calling:** Multi-turn tool-calling performance has improved more than threefold compared to Kanana-1.5, significantly enhancing its utility with the Model Context Protocol (MCP). * **Instruction Following:** The model's ability to understand and execute multi-step, complex user requirements has been refined to ensure reliable task completion. * **Reasoning-Tool Integration:** Unlike many reasoning models that lose instruction-following quality during deep thought, the "Thinking" variant maintains high performance in both logical deduction and tool use. ### High-Efficiency Architecture for Scale * **MLA (Multi-head Latent Attention):** Compresses memory usage to handle long contexts more efficiently, reducing the resources needed for extensive data processing. * **MoE (Mixture of Experts):** Activates only the necessary parameters during inference, maintaining high performance while drastically reducing computational costs and response times. * **Improved Tokenization:** A newly trained tokenizer has improved Korean language token efficiency by 30%, enabling faster throughput and lower latency in high-traffic environments like KakaoTalk. ### Expanded Multilingual Support * **Broad Linguistic Reach:** The model has expanded its support from just Korean and English to include six languages: Korean, English, Japanese, Chinese, Thai, and Vietnamese. By open-sourcing Kanana-2, Kakao provides a robust foundation for developers seeking to build responsive, tool-integrated AI services. Its focus on practical efficiency and advanced reasoning makes it an ideal choice for implementing agentic workflows in real-world applications where speed and accuracy are critical.

naverOriginal article

Naver TV (opens in new tab)

This technical session from NAVER ENGINEERING DAY 2025 details the transition from traditional open-source exporters to a Telegraf-based architecture for collecting custom system metrics. By evaluating various monitoring tools through rigorous benchmarking, the developers demonstrate how Telegraf provides a more flexible and high-performance framework for infrastructure observability. The presentation concludes that adopting Telegraf streamlines the metric collection pipeline and offers superior scalability for complex, large-scale service environments. ### Context and Motivation for Open-Source Exporters * The project originated from the need to overcome the limitations of standard open-source exporters that lacked support for specific internal business logic. * Engineers sought a unified way to collect diverse data points without managing dozens of fragmented, single-purpose agents. * The primary goal was to find a solution that could handle high-frequency data ingestion while maintaining low resource overhead on production servers. ### Benchmark Testing for Metric Collection * A comparative analysis was conducted between several open-source monitoring agents to determine their efficiency under load. * Testing focused on critical performance indicators, including CPU and memory footprint during peak metric throughput. * The results highlighted Telegraf's stability and consistent performance compared to other exporter-based alternatives, leading to its selection as the primary collection tool. ### Telegraf Architecture and Customization * Telegraf operates as a plugin-driven agent, utilizing four distinct categories: Input, Processor, Aggregator, and Output plugins. * The development team shared their experience writing custom exporters by leveraging Telegraf’s modular Go-based framework. * This approach allowed for the seamless transformation of raw data into various formats (such as Prometheus or InfluxDB) using a single, unified configuration. ### Operational Gains and Technical Options * Post-implementation, the system saw a significant reduction in operational complexity by consolidating various metric streams into a single agent. * Specific Telegraf options were utilized to fine-tune the collection interval and batch size, optimizing the balance between data granularity and network load. * The migration improved the reliability of metric delivery through built-in retry mechanisms and internal buffers that prevent data loss during transient network failures. For teams currently managing a sprawling array of open-source exporters, migrating to a Telegraf-based architecture is recommended to centralize metric collection. The plugin-based system not only reduces the maintenance burden but also provides the necessary extensibility to support specialized custom metrics as service requirements evolve.

discordOriginal article

ROOST Announces “Coop” and “Osprey”: Free, Open-Source Trust and Safety Infrastructure for the AI Era (opens in new tab)

ROOST, a non-profit dedicated to digital safety, has launched two open-source tools, Coop and Osprey, to provide enterprise-grade content moderation and threat investigation capabilities to organizations of all sizes. By open-sourcing technology previously developed by industry leaders like Discord and Cove, ROOST aims to democratize access to the infrastructure required to detect, triage, and respond to online harms. This initiative shifts Trust and Safety from a proprietary competitive advantage to a shared public resource, enabling platforms to prioritize user protection without the burden of expensive enterprise software. ### Content Review and Compliance with Coop Built on technology acquired from Cove and utilized by platforms like Notion, Coop focuses on the human-in-the-loop aspect of content moderation. * The platform provides robust tools for content review, allowing teams to route specific cases to subject-matter experts for deeper analysis. * It includes built-in integration with the National Center for Missing & Exploited Children’s (NCMEC) API, automating the mandatory reporting process for child sexual abuse material (CSAM). * The interface is designed to surface relevant context and metadata, ensuring moderators can make informed decisions and take immediate action against policy violations. ### Incident Response and Investigation with Osprey Osprey is a lightweight investigation tool originally developed by Discord to manage large-scale safety incidents and platform-wide threats. * It serves as a foundation for incident response, helping safety teams understand platform trends and investigate coordinated threats like phishing or harassment campaigns. * The tool is designed to be user-friendly and accessible for grassroots communities while remaining powerful enough for established platforms. * Early adopters, including the decentralized social network Bluesky, are implementing Osprey to demonstrate that effective safety infrastructure can be scalable and resource-efficient. ### A Collaborative Model for Safety Infrastructure The launch of these tools represents a strategic shift toward a collaborative "public-interest" model for digital defense. * ROOST acquired the intellectual property of Cove and received the donation of Osprey from Discord to ensure these tools remain available as a public good. * The initiative is backed by philanthropic funding and legal support from Perkins Coie, removing the financial barriers that often prevent smaller platforms from implementing high-level safety measures. * Major industry players like Notion and Bluesky are championing the move, signaling an industry-wide push to share safety innovations rather than silo them. Platforms and developers should prepare to integrate these tools into their safety stacks as they become publicly available in the coming months. By adopting open-source infrastructure for routine tasks like NCMEC reporting and incident triage, organizations can focus their internal resources on platform-specific innovations while maintaining a high standard of digital safety.

figma2 min readCurated summary

Welcoming Payload to the Figma Team | Figma Blog

Figma has welcomed the team behind Payload, an open-source headless CMS and application framework, to strengthen its developer tools and connect design more closely with development. Payload will remain open source, with continued investment and no immediate changes for users. The partnership supports Figma’s broader vision of letting teams design, build, and deploy digital products within a collaborative ecosystem. ## Why Figma Chose Payload - Payload is known for its highly customizable architecture, extensibility, and strong developer experience. - It has become one of the leading open-source projects in its category and is used by several Fortune 100 companies. - Figma was especially impressed by Payload’s active open-source community and its practice of incorporating developer feedback into the product. - Both companies emphasize collaboration, community participation, and continuous improvement. ## What Happens to Payload - Payload will remain an open-source product. - There will be no immediate changes for existing users. - Figma plans to continue investing in the project and improving it. - Figma and Payload users will receive ongoing communication as the combined CMS strategy and product roadmap develop. ## Bridging Design and Development - Figma aims to become a central hub where teams can create and deploy digital products. - Payload’s CMS and framework capabilities can help connect Figma’s design tools with production websites and applications. - As AI accelerates the generation of code and content, controlling deployments and refining user experiences across channels becomes increasingly important. - The partnership is intended to reduce the traditional gap between designers and developers. ## The Broader Context - The announcement follows Figma’s push into web publishing through Figma Sites. - Payload’s flexibility and developer-focused tools could expand what developers can build across Figma’s platforms. - The companies expect their combined teams and communities to create more integrated design, development, and content workflows. Figma’s acquisition of the Payload team is positioned as a long-term investment in collaborative, developer-friendly product creation, while preserving Payload’s open-source identity and existing user experience.

Read original(opens in new tab)
figma2 min readCurated summary

Six Myths Holding You Back from Embracing Design Systems | Figma Blog

Design systems are not reserved for large companies or teams with advanced design practices. Figma argues that the best system is practical, goal-oriented, and tailored to an organization’s brand, users, and needs—not copied from industry trends or famous examples. By challenging common assumptions, teams can adopt design systems more confidently and incrementally. ## Design Systems Benefit Teams of All Sizes - Small organizations can use design systems to improve efficiency, consistency, and collaboration. - The system’s scale and appearance may vary, but its core purpose remains the same. - Mixpanel’s redesign is cited as an example of using a design system to reduce costs, improve consistency, and make analytics more accessible. ## A Design System Does Not Need Every New Technique - Design trends change constantly, and no single approach is universally correct. - Teams should learn from industry practices without becoming distracted by building a “perfect” or fashionable system. - A useful design system should serve clear organizational goals rather than imitate the latest trends. ## Material Design Is Not a Universal Solution - Google’s Material Design is influential, but it is not automatically suitable for every organization. - Design systems should reflect a company’s brand identity, user needs, and business objectives. - Teams should balance established standards with solutions appropriate to their current context. - Examples such as Uber Base, Spotify Backstage, Pipedrive, Microsoft Teams, and Salesforce Lightning demonstrate that successful systems can differ significantly. ## You Do Not Have to Build Everything From Scratch - The article begins addressing the misconception that every design system must be created internally from the ground up. - Open-source design-system resources and existing UI kits can provide a starting point. - Reusing proven foundations can help teams move faster while adapting components to their own requirements. The practical recommendation is to start with the problems your team needs to solve, then adopt or create only the structure necessary to address them.

Read original(opens in new tab)
figma3 min readCurated summary

The Future of Design Systems is Complicated | Figma Blog

Design systems have evolved from simple visual metaphors into complex frameworks supporting many platforms, use cases, accessibility needs, and performance expectations. The article argues that teams need more structure to manage this complexity, but excessive control can suppress creativity. The future lies in balancing consistent systems with flexibility, experimentation, and contributions from the wider design community. ## Complexity Is the New Normal - Early systems such as Google’s Material Design used familiar metaphors—like stacked paper—to help users understand digital interfaces. - Google later abandoned that metaphor as users became more comfortable with digital interactions and products expanded across: - New devices and form factors - Accessibility standards - More sophisticated interactions - Higher performance expectations - Products such as Instagram evolved from single-purpose apps into platforms for discovery, advertising, partnerships, and shopping. - Larger teams now work across multiple interconnected systems, creating a need for better ways to organize design and development work. ## Taming Chaos with Structure - Design teams are adopting processes inspired by software development, particularly branching and merging. - Contributors can work on isolated branches, propose fixes or components, and have system managers review changes before incorporating them into the main system. - Spotify’s Encore supports “local systems,” allowing sub-teams to fork and extend the central system for specialized needs. - Spotify’s advertising team developed a strong collection of video-player components, which later influenced the broader organization. - Open design systems can: - Gather feedback from a wider range of users - Encourage outside contributions - Make products and design decisions more transparent - Build organizational trust and visibility ## When Structure Becomes Too Restrictive - Strict systems can limit experimentation and make designers feel they lack creative freedom. - A design system should reduce the effort required to express ideas, not create additional barriers. - Shopify designer José Torre compares systems to gardening rather than architecture: - Architecture implies that everything is planned and finished. - Gardening involves planting, observing, adapting, and intervening as unexpected growth occurs. - Components such as buttons and menus may develop in unforeseen directions, so systems need room to evolve rather than enforcing rigid boundaries. ## Finding the Balance - Effective design systems must combine consistency with adaptability. - Teams should establish enough structure to coordinate large, interconnected efforts while allowing local experimentation and new patterns to emerge. - Collaboration, contribution workflows, and ongoing maintenance are more valuable than treating a design system as a fixed, finished artifact. Design systems should be treated as living ecosystems: structured enough to provide shared foundations, but flexible enough to support creativity, accessibility, and changing product needs.

Read original(opens in new tab)
datadog3 min readCurated summary

Engineering Spotlight: Tay Nishimura

Tay Nishimura’s career shows that succeeding in tech is often less about fitting a standard engineering mold and more about finding work that matches one’s strengths. Although she initially struggled with the speed and coding demands of software development, her rigor, visual thinking, and careful approach became valuable in site reliability engineering. Her transition was enabled by self-directed learning, community education, and ToyNet, an open source networking simulator that demonstrated her practical abilities. ## Entering Tech from Mathematics - Tay began as a mathematics major focused on real analysis, then added computer science after advice from a professor. - Internships at Amazon and Google introduced her to the technology industry. - She found a sharp contrast between academia and industry: - School rewarded theoretical rigor. - Industry emphasized practical, fast, and agile solutions. - Tay also felt like an outsider because she had little exposure to computers growing up. ## Struggling with Traditional Software Engineering - Coding did not come naturally to Tay’s visual way of thinking. - She translated code into drawings to understand and modify it, then converted those ideas back into code. - This process produced high-quality, careful work but made her slower than colleagues expected. - A manager suggested product management and site reliability engineering as possible alternatives. - Tay discovered that her deliberate pace was useful for SRE work, particularly when evaluating failure modes and making critical changes. - Because her company offered no path into those roles, she eventually left rather than continue facing increasing stress. ## Discovering Networking and Technical Program Work - Tay’s next role had a software engineer title but involved work closer to product or technical program management. - She learned that job titles and responsibilities vary significantly between companies. - With better work-life balance, she began studying computer networking in her free time. - She created visual diagrams and learning modules to explain switches, routers, and packet flows. - These efforts became Project Reclass, a nonprofit teaching technical skills to incarcerated people and military veterans. - The program used improvised equipment, such as fake routers and switches, to teach concepts in environments where real networking hardware was unavailable. ## Building ToyNet During the Pandemic - After her company laid off its entire office during COVID-19, Tay decided to pursue SRE directly. - When prisons suspended in-person education, Project Reclass adapted by creating a digital networking simulator. - Tay architected ToyNet, an open source platform built with: - React - A Flask backend - Containerized Mininet instances for network emulation - Users can connect simulated routers, switches, and hosts, configure IP addresses, and run commands such as `ping` and `arp`. - ToyNet was designed to work for incarcerated learners with restricted internet access. - Deploying it in the cloud also gave Tay practical experience that helped compensate for limited professional cloud experience. - Companies interested in the project were more likely to advance her through the interview process, eventually leading to Datadog. ## Finding the Right Environment at Datadog - At Datadog, Tay learned Kubernetes, chaos engineering, network traffic control, and Go. - She found that her rigor and visual thinking were assets rather than liabilities. - While learning Datadog’s Chaos Controller codebase, she mapped files and dependencies by drawing boxes and arrows. - Her experience suggests that engineers do not need to learn or reason in a single conventional way; the right environment can turn an apparent weakness into a strength. Tay’s path recommends experimenting broadly, studying independently, and building concrete projects that reveal how you think and solve problems. The most suitable tech role may emerge only after moving between companies and disciplines rather than forcing yourself to succeed in an ill-fitting position.

Read original(opens in new tab)
figma2 min readCurated summary

The year ahead: a conversation with Soleio, Julie Zhuo, and May-Li Khoe | Figma Blog

The article explores how creative work may evolve in 2022 as remote and hybrid work become permanent. Soleio argues that collaboration will move further into digital tools, requiring stronger documentation, asynchronous processes, and organizational discipline. He also predicts that creative tools will spread across the workforce and increasingly incorporate automated, virtual collaborators. ## Hybrid Work Will Reshape Creative Collaboration - Creative work will increasingly reflect hybrid workforce models. - Institutional knowledge and team context will move from physical offices into digital environments. - Traditional brainstorming sessions may shift from conference rooms to tools such as FigJam. - Creative software will become more accessible and collaborative, encouraging people outside traditional creative roles to use it. ## London’s Growing Technology Ecosystem - Relocating from Silicon Valley to London required Soleio to adjust his understanding of the two technology ecosystems. - Whereas technology dominates the Bay Area, it remains a newer and more disruptive sector in many other regions. - London is attracting more early-stage investors and becoming a stronger home for ambitious startups. - This growth may allow founders to build major technology companies without moving to Silicon Valley. ## Global Teams Need Better Organizational Hygiene - Distributed teams must deliberately coordinate feedback and decision-making across time zones. - Clear writing, recorded video feedback, and structured processes will become more important. - Remote teams cannot rely on shared office space or informal conversations to maintain context. - Transparent documentation and decision-making will become a competitive advantage. ## Automation and Virtual Collaborators - Design exploration and feedback are expected to become increasingly automated. - Future knowledge work may involve non-human agents that provide feedback, support iteration, and perform tasks currently handled manually. - These tools could fundamentally change the nature of teamwork by making virtual collaborators part of everyday creative processes. Teams preparing for the future should invest not only in collaborative tools, but also in documentation, asynchronous communication, and transparent organizational practices.

Read original(opens in new tab)
figma2 min readCurated summary

Shifting team culture at Config 2021 | Figma Blog

The Config 2021 sessions argued that inclusive, collaborative design depends on building cultures of transparency, trust, and shared participation. Speakers emphasized two complementary practices: acknowledging people’s real emotions and circumstances, and creating accessible spaces where newcomers and diverse perspectives can contribute. The overall conclusion was that teams cannot create inclusive experiences alone; they need intentional routines, open resources, and community support. ## Embracing Vulnerability - Figma researcher Nannearl Brown described how openness about personal struggles can create a more supportive team culture. - Team members were encouraged to share: - How they were feeling - What support they needed - What they were focusing on during the day - Daily Slack stand-ups included non-work activities—such as exercise, hobbies, or family time—to encourage work-life balance and help teammates understand one another. - Support requires more than listening; teammates should make room for each other’s emotions, experiences, and difficult moments. - The central message was that people do not need to appear fine all the time. ## Creating Inclusive Spaces - Bitcoin designers Johns Beharry and Christoph Ono noticed that Bitcoin design resources often excluded people without technical expertise or geographic access. - They responded by building shared spaces where experienced designers could support newcomers, including: - A Slack community - GitHub resources - The Bitcoin Design resource hub - Weekly community calls - The open-source Bitcoin Design Guide - The resources were designed to work across cultures, regions, languages, and levels of technical knowledge. - Their goal was to create a friendly environment that encouraged broader participation and more diverse perspectives. - They argued that inclusive and accessible design requires collaboration with people who bring different experiences. ## Building Collaborative Culture - Design is inherently collaborative and benefits from varied experiences and perspectives. - Inclusive culture helps more team members and collaborators participate in the design process. - Trust and transparency are developed through both interpersonal habits—such as honest check-ins—and structural tools that make knowledge widely accessible. Teams seeking a more inclusive culture should normalize vulnerability, establish supportive communication routines, and create shared resources that invite participation from people with different backgrounds and levels of expertise.

Read original(opens in new tab)