Forem: Brian Douglas

OpenClaw in a Box

Brian Douglas — Sat, 21 Mar 2026 22:59:08 +0000

An OpenClaw agent deleted 200+ emails from Meta's AI alignment director's inbox while ignoring her commands to stop. She had to run to her Mac to kill the process. Context window compaction dropped the safety constraint that said "ask before acting."

// Detect dark theme var iframe = document.getElementById('tweet-2025774069124399363-731'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2025774069124399363&theme=dark" }

No network boundary. No kill switch beyond reaching the machine. No recording of what the agent saw or why it ignored the stop command.

I built openclaw-in-a-box to make that scenario impossible. It runs OpenClaw inside a stereOS VM with Tapes as the flight recorder.

Last month ago I wrote about running OpenClaw on exe.dev with Discord. That post was about getting started safely on someone else's ephemeral VM. This project takes it further: you own the sandbox, you own the telemetry, and the whole thing is declarative and version-controlled.

Brian Douglas

Feb 2

Setting Up OpenClaw on exe.dev with Discord

#ai #llm #coding

Comments 3

5 min read

The sandbox

stereOS locks the agent down. Network egress allowlist means the agent can only reach APIs you explicitly permit. Gmail, Anthropic, npm. Nothing else. If the agent tries to curl somewhere unexpected, the network layer blocks it. This isn't application-level filtering. It's at the VM's network stack.

Secrets live in tmpfs, never written to disk, gone the moment the VM stops. Auto-teardown after 2 hours. If you walk away, credentials don't linger. The agent doesn't keep running overnight.

One jcard.toml file defines the entire sandbox. Resources, network policy, secrets, timeout. Reproducible, auditable, version-controlled.

mixtape = "opencode-mixtape:latest"
name = "openclaw-in-a-box"

[network]
mode = "nat"
egress_allow = [
  "api.anthropic.com", "openclaw.ai",
  "gmail.googleapis.com", "oauth2.googleapis.com",
  "registry.npmjs.org",
]

[timeout]
duration = "2h"

[secrets]
ANTHROPIC_API_KEY = "${ANTHROPIC_API_KEY}"

The flight recorder

Tapes sits between the agent and the LLM as a transparent proxy, capturing every request and response to SQLite with hash chains. No instrumentation. No SDK. It records at the network layer.

When the Meta incident happened, there was no way to replay the agent's reasoning. Why did it start deleting? What did the compacted context look like? At what point did it lose the safety constraint? Without a recording, all you have is the outcome: 200 emails gone.

With Tapes you get the full prompt, the full response, token counts, timestamps. Content-addressed so the sequence is tamper-evident. If the agent miscategorizes an email, you replay the tape. Every prompt, every response, every decision.

The difference between "200 emails gone, no idea why" and a complete forensic replay.

The architecture

┌─────────────────────────────────────────────┐
│  stereOS VM  (NixOS · 2 CPU · 4 GiB)       │
│                                             │
│  tapes proxy (:8080)                        │
│    ▲ intercepts all LLM traffic             │
│    ▼                                        │
│  openclaw gateway (:18789)                  │
│    ├── Claude API (via Tapes proxy)         │
│    ├── gog CLI → Gmail API                  │
│    └── skills/gmail-triage/SKILL.md         │
│                                             │
│  egress: anthropic, gmail, npm only         │
│  secrets: tmpfs (never on disk)             │
│  timeout: 2h auto-teardown                  │
└─────────────────────────────────────────────┘
       │
       │  shared mount (persists across restarts)
       ▼
  .mb/tapes/tapes.sqlite    agent black box
  .openclaw/                agent config
  output/                   INBOX_REPORT.md

The skill

The triage logic is a Markdown file. No code. The agent reads it, understands the rules, and executes them using the gog CLI for Gmail access.

It classifies messages into four categories: newsletter, receipt, action needed, FYI. Newsletters get archived. Receipts get labeled and archived. Action items get starred. FYI messages get marked as read.

Safety constraints baked into the skill: never delete messages, never send replies. If a message can't be confidently classified, leave it unread. Change the categories, add new ones, tighten the constraints. It's all prose.

Running it

git clone https://github.com/papercomputeco/openclaw-in-a-box
cd openclaw-in-a-box
mb up
mb ssh openclaw-in-a-box
bash /workspace/scripts/install.sh
bash /workspace/scripts/start.sh

The install script handles Node.js, OpenClaw CLI, Tapes CLI, and the gog CLI for Gmail access. OAuth setup for Gmail is a one-time step on the host. After that, mb up and start.sh is all you need between sessions.

What you get from the recordings

Query the black box directly to see the agent's reasoning:

sqlite3 .mb/tapes/tapes.sqlite \
  "SELECT role, substr(content, 1, 200) FROM nodes ORDER BY created_at DESC LIMIT 4"

assistant | Here's your inbox triage for the last 2 days (20 threads):
           ## Needs Attention
           - State DMV: Complete your application
           - Team standup invite: Tuesday 9am PDT...
user      | [tool_result]
assistant | [tool_input: gog gmail messages list ...]
user      | /gmail-triage

Read bottom to top. The user invoked /gmail-triage, the agent called gog to list messages, received the results, then produced the classification. Every step is captured.

Over time the recordings become training data. Analyze 100 triage sessions to find where the skill definition falls short. Which email categories does the agent struggle with? Which prompts produce better classification? The black box isn't just for incident response. It's how agents get better between runs.

When you're done, mb destroy openclaw-in-a-box. Secrets gone. VM gone. The only thing that survives is the tape.

Go try it.

papercomputeco / openclaw-in-a-box

Secure, sandboxed OpenClaw agents with full telemetry.

openclaw-in-a-box

Run OpenClaw in a stereOS VM with Tapes telemetry.

Get Started

Paste this into Claude Code, OpenCode, or any coding harness:

Set up openclaw-in-a-box from https://github.com/papercomputeco/openclaw-in-a-box — clone the repo and follow SKILL.md to get me running with a secure OpenClaw setup

The agent clones the repo, checks your environment, asks which integrations you want, and walks you through setup.

Manual setup

Prerequisites: Master Blaster (mb CLI) and ANTHROPIC_API_KEY exported.

git clone https://github.com/papercomputeco/openclaw-in-a-box
cd openclaw-in-a-box
export ANTHROPIC_API_KEY="sk-ant-..."
mb up
mb ssh openclaw-in-a-box
bash /workspace/scripts/install.sh   # first time
bash /workspace/scripts/start.sh

Integrations

The VM comes pre-configured for three integrations. Set up whichever ones you need -- the agent loads all available skills at startup.

Integration	Setup Guide	What It Does
Gmail Triage	Google OAuth + `gog` CLI	Archive newsletters, label receipts, flag action items
GitHub Org Triage	`GH_TOKEN` + `gh` CLI	Flag stale PRs, blocked issues, release

…

View on GitHub

aiagents #opensource #security

Setting Up OpenClaw on exe.dev with Discord

Brian Douglas — Mon, 02 Feb 2026 06:11:52 +0000

I'll be honest—when I first heard about Clawdbot (now rebranded as OpenClaw) a few weeks back, I had that immediate security alarm going off in my head. An AI agent running with Discord permissions, making API calls, potentially accessing who knows what? As someone who's spent years in developer experience, the threat model here was... concerning.

But then I started seeing folks in the community actually using it—spinning up Digital Ocean droplets, deploying to Railway.

So I decided to try it, but on my terms: isolated, observable, and disposable. Which is why I chose exe.dev, but this can work on the platform of your choice.

Why exe.dev?

I've known about exe.dev for months—it's this clever service that gives you ephemeral VMs that you can spin up and tear down instantly. Perfect for experiments you're not 100% sure about. If OpenClaw does something weird or I misconfigure something, I just nuke the VM and start fresh. No damage to my local machine, no persistent infrastructure to maintain.

Think of it as a playground where mistakes are cheap.

💡 Pro Tip: Add Telemetry from Day One

Before you start, consider adding tapes as a proxy layer. It records every API call OpenClaw makes, giving you visibility into prompts, token usage, and agent behavior. The official guide has details, or follow the optional setup in Step 7 below. Trust me—you'll want this data when debugging why your agent did something unexpected.

What You'll Need

Before we dive in, grab these:

An exe.dev account
A Discord bot token from the Discord Developer Portal
An Anthropic API key if you want to use Claude (optional, but recommended)

The Fast Path: Using the Template

Here's where exe.dev really shines. They have an OpenClaw template that handles most of the setup:

Navigate to exe.new/openclaw
Drop in your API keys when prompted
Let Shelley (exe.dev's setup assistant) do the heavy lifting

I'm going to walk you through the manual setup though, because understanding what's actually happening is half the value here.

The Manual Route (More Learning, Same Result)

Create Your VM

ssh exe.dev new
# You'll get a VM name like: curious-tesla-8432
ssh curious-tesla-8432.exe.xyz

You're now inside an Ubuntu VM that exists just for you, accessible from anywhere.

Install OpenClaw

This is surprisingly straightforward:

# Get the system ready
sudo apt-get update
sudo apt-get install -y git curl jq ca-certificates openssl nginx

# Install OpenClaw via their script
curl -fsSL https://openclaw.bot/install.sh | bash

# Run the onboarding (we're skipping interactive prompts)
openclaw onboard --non-interactive --accept-risk

That --accept-risk flag made me pause. It's OpenClaw's way of acknowledging that yes, you're running an AI agent with real permissions. I appreciate the directness.

Configure Nginx as a Reverse Proxy

OpenClaw runs on port 18789 internally, but we want to access it via standard web ports. This is where nginx comes in.

Edit /etc/nginx/sites-enabled/default:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 8000;
    listen [::]:8000;

    server_name _;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;

        # WebSocket support - crucial for real-time updates
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Standard proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Long timeouts for agent tasks that might run a while
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}

Apply the changes:

sudo systemctl restart nginx

Connect Your Discord Bot

Now for the fun part. Edit ~/.openclaw/openclaw.json and add your Discord credentials:

{
  "channels": {
    "discord": {
      "enabled": true,
      "token": "YOUR_DISCORD_BOT_TOKEN"
    }
  }
}

Restart the gateway to pick up the changes:

openclaw gateway restart

The Pairing Dance (This Tripped Me Up)

When I first tried to access the dashboard, I got this cryptic message:

disconnected (1008): pairing required

Turns out OpenClaw uses a device pairing system to prevent unauthorized access. Smart, but not immediately obvious.

Here's how to fix it:

# See what's waiting for approval
openclaw devices list

You'll see something like:

Pending:
  - id: abc123
    browser: Chrome
    requested: 2 minutes ago

Approve it:

openclaw devices approve abc123

Now refresh your browser. You should be connected.

Access Your Dashboard

Your OpenClaw dashboard lives at:

https://<vm-name>.exe.xyz/?token=<your-gateway-token>

Find your token in ~/.openclaw/openclaw.json under gateway.auth.token. I bookmarked this URL because I reference it constantly.

Verify Everything Works

openclaw health

You should see confirmation that Discord is connected and your agents are running:

Discord: ok (@yourbotname)
Agents: main (default)

This is your health check. Anytime something feels off, run this first.

Optional: Route Through Tapes for Observability

Here's where my Continue background kicks in. I want to see what API calls OpenClaw is making, so I route everything through tapes—Anthropic's proxy tool for inspecting and recording API interactions.

Start tapes:

tapes serve \
  --provider anthropic \
  --upstream "https://api.anthropic.com" \
  --proxy-listen "0.0.0.0:8080" \
  --sqlite "./tapes.db"

Update ~/.openclaw/openclaw.json:

{
  "providers": {
    "anthropic": {
      "baseUrl": "http://localhost:8080"
    }
  }
}

Restart: openclaw gateway restart

Now every Claude API call is logged to tapes.db. You can inspect prompts, responses, token usage—everything. This level of observability is crucial when you're evaluating AI tooling.

Things That Surprised Me

The pairing system actually works well - Once I understood it, I appreciated having explicit device approval
Config persistence is fragile - Some OpenClaw commands will overwrite your config. Always backup ~/.openclaw/openclaw.json before running setup commands
It's genuinely useful - Having a Discord bot that can reason about context and execute tasks is different from slash commands or simple bots

Troubleshooting Guide

"pairing required" won't go away

openclaw devices list
openclaw devices approve <id>

Refresh your browser after approving.

Discord shows offline

Double-check your bot token in the config
Verify the bot was added to your server with the right permissions
Run openclaw doctor for diagnostics

Gateway won't start

openclaw gateway status  # Check what's wrong
openclaw logs           # See error details
openclaw gateway restart # Try restarting

Quick Reference Commands

Command	What It Does
`openclaw health`	Connection status check
`openclaw devices list`	Show paired/pending devices
`openclaw devices approve <id>`	Approve a new device
`openclaw gateway restart`	Restart the gateway process
`openclaw doctor`	Run full diagnostics
`openclaw logs`	View gateway logs

Final Thoughts

Running OpenClaw on exe.dev turned out to be the perfect middle ground. I got to experiment with AI agents in Discord without compromising my local environment, and I could observe everything happening via tapes.

Is it production-ready for your use case? That depends on what you're building. But as a tool for understanding how autonomous AI agents operate, how they handle context, and what the developer experience looks like? It's been genuinely educational.

The security concerns I had initially? Still valid. But now they're informed concerns rather than fear-based ones. And that's the difference between avoiding technology and understanding its tradeoffs.

Guide based on OpenClaw 2026.1.29 running on exe.dev. If you try this and run into issues, reach out—I'm probably debugging the same thing.

[Boost]

Brian Douglas — Tue, 26 Aug 2025 22:29:36 +0000

Olabode Lawal-Shittabey

Aug 26 '25

Continuous AI: A Simple Introduction

#ai #softwaredevelopment #llm #softwareengineering

Comments 2

4 min read

The Building Blocks of an AI Coding Assistant

Brian Douglas — Wed, 26 Mar 2025 18:03:08 +0000

In my latest newsletter, I ranted about how most developers approach AI coding assistants wrong.

We're treating these tools like magic boxes instead of understanding their components. Today, I’ll dive into what makes a coding assistant work, using continue.dev—an open-source platform changing our view on AI coding tools. I'll break down the seven essential building blocks.

As I shared in my newsletter, my Go programming journey was transformed by leveraging these building blocks. When I started with Go, I struggled with its idioms and best practices. But by creating a customized coding assistant that indexes official documentation and enforces idiomatic patterns, I’ve dramatically accelerated my learning. What used to take hours now happens seamlessly.

I’m focusing on the Continue coding assistant because it’s the first I’ve used with this paradigm.

Breaking Down the AI Coding Assistant

If you've followed my work, you know I'm passionate about demystifying dev tools. The problem with most AI coding approaches is developers expect too much ("AI do my job") or too little ("it's just fancy autocomplete"). The reality lies in between, and understanding the building blocks helps us use these tools effectively.

Models

Models specify Large Language Models (LLMs) and other deep learning models for roles in the open-source IDE extension like Chat, Autocomplete, Edit, Embed, Rerank, etc. Explore available models on the hub.

Continue supports many model providers like Anthropic, OpenAI, Gemini, Ollama, Amazon Bedrock, Azure, xAI, DeepSeek, and more. Models can have roles such as chat, edit, apply, autocomplete, embed, and rerank. Read more about roles here. View models in the YAML Reference for details.

The key advantage is running your assistant locally with Ollama. Check out Chad's article on leveraging Ollama and Gemma 3.

Context

Context blocks define a provider referenced in Chat with @ to pull data from external sources like files, URLs, Jira, Confluence, and GitHub issues. Explore context provider blocks on the hub.

context:
  - id: go-docs
    name: Go Documentation
    description: Official Go programming language documentation
    sources:
      - type: web
        url: https://golang.org/doc/
      - type: web
        url: https://golang.org/doc/effective_go

  - id: go-stdlib
    name: Go Standard Library
    description: Go standard library documentation
    sources:
      - type: web
        url: https://pkg.go.dev/std

With this setup, reference Go documentation in chats using @go-docs or access the standard library with @go-stdlib. This has greatly boosted my productivity when writing Go code, as mentioned in my AI coding newsletter.

Learn about context providers here this guide here and create your own with. Find the config.yaml spec for context.

Docs

Docs are blocks pointing to documentation sites, indexed locally for reference using @Docs in Chat. Explore docs on the hub.

See my docs example in the rules section.

MCP Servers

Model Context Protocol (MCP) servers are popular, and Continue has had this as a primitive for some time. MCP is a standard for building and sharing language model tools, defined in mcpServers blocks. Explore MCP Servers on the hub.

MCP is the new AI buzzword, with many usage examples.

Rules

Rules blocks are instructions your custom AI code assistant always considers. The contents are inserted into the system message for all Chat requests. Explore rules on the hub.
rules:
  - id: effective-go
    name: Effective Go Guidelines
    description: Rules for writing idiomatic Go code
    content: |
      When writing or reviewing Go code, adhere to these Effective Go principles:
      1. Use proper error handling with explicit error returns
      2. Prefer composition over inheritance
      3. Follow Go naming conventions (CamelCase for exported, camelCase for internal)
      4. Use interfaces for abstraction and testing
      5. Use the standard library effectively
      6. Implement proper concurrency patterns with goroutines and channels
      7. Write clear and concise comments for exported functions

I've complemented this by indexing the official Effective Go documentation.

docs:
  - name: Effective Go
    version: 0.0.1
    schema: v1
    startUrl: https://go.dev/doc/effective_go

This setup ensures my coding assistant follows Go best practices and can reference official guidelines. As I mention in my newsletter, domain-specific rules enhance AI-generated code relevance.

Learn more in the rules deep dive, and see in the YAML Reference for details.

Prompts

Prompts blocks are reusable prompts for chat, useful for repetitive or complex tasks. Explore prompts on the hub.

prompts:
  - id: go-hype-beast
    name: Go Hype Beast
    description: A prompt for idiomatic Go code assistance
    prompt: |
      You are a Golang programming assistant. Help developers write clean, idiomatic, efficient Go code by following these best practices:

      1. Use gofmt for consistent formatting.
      2. Follow Go naming conventions:
         • CamelCase for exported names, camelCase for unexported.
         • Avoid stuttering in package names (e.g., vectordb.New() not vectordb.NewVectorDB()).
         • Name interfaces as "doers" (e.g., Reader, Writer).
      3. Write clear, concise code:
         • Keep functions small and focused.
         • Use meaningful names.
         • Limit line length, but don't obsess.
      4. Handle errors explicitly:
         • Check and handle errors immediately.
         • Avoid panic.
      5. Use Go's concurrency features:
         • Goroutines for concurrency.
         • Channels for communication.
      6. Optimize for readability and maintainability:
         • Explain "why" in comments.
         • Use defer for cleanup.
      7. Leverage Go's type system:
         • Use structs for related data.
         • Implement interfaces implicitly.
      8. Follow idiomatic Go patterns:
         • Prefer composition over inheritance.
         • Use slices over arrays when possible.
      9. Optimize performance:
         • Use efficient data structures and algorithms.
         • Profile and benchmark when necessary.
      10. Ensure code safety and security:
          • Use go vet and golint.
          • Avoid global variables when possible.

      When providing code examples, adhere to these principles and explain your recommendations. For style decisions, refer to the Go Style Guide and Effective Go documentation.

The "Go Hype Beast" prompt ensures my coding assistant provides idiomatic Go code suggestions following best practices. It transforms the assistant into a specialized Go expert, understanding the language philosophy. Combined with Effective Go documentation, it creates a powerful Go development environment.

Prompt blocks share the same syntax as prompt files but differ in two key ways:

Prompt blocks can't use context providers.
They're stored in config.yaml, not .continue/prompts.

Find the config.yaml spec for prompts here.

Data

Data blocks send development data to chosen destinations, useful for analysis, insights, or model fine-tuning. Learn more about development data here and explore data block examples here.

Configure data destinations in the data section of config.yaml.

Why This Matters

The block-based approach isn't just technical; it fundamentally shifts how we view AI coding assistants. Instead of a mysterious code generator, it offers a transparent, customizable toolset.

This modular approach allows you to:

Customize your assistant for specific languages or frameworks.
Swap components as better models emerge.
Understand how the assistant makes suggestions.
Build trust through transparency.

The Future is Composable

I'm thrilled by continue.dev's alignment with the Unix philosophy: tools should excel at one task and integrate via simple interfaces. By breaking down the assistant into seven blocks—Models, Context, Docs, MCP Servers, Rules, Prompts, and Data—continue.dev enables specialized assistants for diverse tasks.

Want a Python refactoring whiz? Combine retrieval blocks that understand Python idioms with transformation blocks for refactoring. Need documentation help? Mix generation blocks with retrieval blocks tailored to your team's style guide.

Build Your Own Assistant

The power of continue.dev is that it puts you in control. Instead of relying on commercial assistants, you can create the perfect assistant by combining these seven building blocks. Understanding them is crucial for an AI coding assistant that truly boosts your workflow.

If you prefer not to start from scratch, remix mine from my Continue profile:

https://hub.continue.dev/bdougie

Measuring Successful Communities in Open Source

Brian Douglas — Thu, 25 Apr 2024 07:00:00 +0000

Open Source Insights

There is no community tool that will replace building meaningful connections. Working in open source can be challenging to track and measure. Identifying what is success in a project can be hand-wavy and is sometimes met with a focus on the wrong metric. Organizations like the CHAOSS give us a lot of metrics, but no direction. There is currently no definitive statement on what success looks like in open source, but I have a few opinions to share.

oss.fyi/remix

In a recent talk I gave on discovering unconventional metrics, I outlined the overlooked metrics of new outside contributors and company representation.

New issues show interest

One key indicator of a thriving open source project is a consistent influx of new contributors opening issues. When a project regularly attracts new participants who are willing to invest their time in reporting bugs, suggesting improvements, or requesting features, it demonstrates the project's vitality and relevance to a growing community.

The Kubernetes project learned this first hand 10 years ago (this July) when they saw several issues opened by Red Hat employees. Find that story in my conversation with Brendan Burns here.

This cohort of engaged users, who may eventually become code contributors or long-term maintainers, is essential for the sustainability and growth of the project. By tracking the number of issues created by new authors over time, open source maintainers can gauge the success of their community-building efforts and the overall health of their project.

Open Source Contributors Metrics

It is not enough to track issues; tracking how issues are uniquely created by outside contributors play a role in the success of a project. These individuals, who are not part of the core development team, represent connected companies and communities with an interest in the project. Their contributions help to enhance the project's functionality, usability, and accessibility. Moreover, outside contributors serve as ambassadors for the project, spreading awareness and attracting new users and developers to the community. By leaning into this metric, open source maintainers can ensure the long-term viability and impact of their project.

The chart below highlights confidence for stargazers and forkers in the top 8 most popular JavaScript projects.

A metrics we are testing internally now is the “Contributor Confidence,” the ability for an individual to contribute more than once. Open source generally over indexes on good first issues, but following the journey through repeat contributions tells a better story for health.

Tracking Success

Open source is the bedrock for so many developing tools and companies, it would be paramount to figure this out so we can see the continued growth from the projects we depend on.

Tools focused on measuring community tend to focus on drive-by interactions like forks and comments but rarely give a sense of what impact the project is providing. Now with the acquisitions of crowd.dev and orbit.love last week, I could not be more proud and validated that the path we are on for sustaining open source through meaningful metrics is needed more than ever.

By focusing on open source projects, we're able to provide specialized insights that cut through the noise to give you the information you need for an impactful open source project.

Remember open source feels better when done together. Explore OpenSauced to discover how you can measure. Follow our changelog for updates as we ship more metrics to our workspaces.

Growth Hacking Killed GitHub Stars

Brian Douglas — Wed, 10 Apr 2024 23:28:12 +0000

In 2023, I had a chat with Max Stoiber, CEO of Stellate, on a podcast to learn about his early success on GitHub. His first open-source project, react-boilerplate/react-boilerplate, gained a whopping 10k stars in just one weekend after appearing on the homepage of Hacker News. This success led Max to drop out of university and create several other popular open-source projects, including styled-components. This library accelerates the process of building styles in React components.

Nowadays, the number of projects hitting 10k stars is more common, inflating the overall number of GitHub Stars. Presently, GitHub has over 100 million users, but back when React Boilerplate started, GitHub had fewer than 10 million users. Getting 10k stars on a project seemed impossible, but with 10x the amount of users, the value of the GitHub Star has suffered from inflation.

Looking back in 2023, the biggest projects with the highest star growth can attribute these star events to intentional marketing. Landing on the front page of Hacker News is still challenging, but tweeting your project's social card can return similar results. The industry has changed a lot in the last 10 years, and where there was a time when open source was driven by weekend code sessions, today open source is fueled by sustainable sponsorship and venture capital. This is not entirely a bad thing, as it provides a sustainable future for the biggest projects we get to use and love.

The challenge in this new reality is defining what is worth looking at and whether GitHub Stars are still relevant for discovering projects worth your time. Correlating the best metric to identify projects to invest your time in depends on who has the biggest reach in a community. This seems contrary to how open source started and marks a shift in how we think about success in open source moving forward. These high growth moments are now indicators of big events like appearing on a subreddit or getting mentioned by a developer influencer on YouTube.

A popular site to see your star growth is star-history and it has become a standard for sharing your GitHub Star growth hacking journey. They also link a post on "how to get more github stars."

The (Detailed & Creative) Playbook for Getting More GitHub Stars

Zevi Reinitz for Livecycle ・ Aug 14 '23

#opensource #github #showdev #tutorial

Some notable projects with Star events in the last year include godot, daytona, plane, and zed.

Growth Hacking With GitHub Stars

godot/gotengine capitalized on the Unity announcement on September 12th, of 2023, with their own announcements. At that time, they had been working on their tool for some time and already had a community they tapped into to share their open source alternative game engine.

(note this chart is available on oss.fyi/godot)

zed-industries/zed, the successor to the atom editor built in rust, coordinated the launch for their repo with friends and trusted acquaintances to create a star event that registers as the edge of the graph. That, indeed, is a vertical line if I ever saw one.

daytonaio/daytona, a self hosted cloud developer environment, learn from its predecessors to become the most starred project for a few days.

Finally, makeplane/plane came into some heat when they posted their chart with unnamed competitors. The stars are valid, and the result of conscientious growth hacking.

The open source community does not like to be sold and asking for a star is a low effort way for makers to grow and engage a community through open source. With that said, there are still a lot of open source maintainers and contributors who prefer not to participate in the process of growth hacking to gain GitHub Stars, and a lot of pushback came from engineers who built their careers on growing open source differently.

The Plane team wrote up outlining their growth hacking journey in a follow up post to the original tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1703627427946311832-751'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1703627427946311832&theme=dark" }

(Read about their journey to 20k stars here.)

The Problem with Open Source Star Inflation

Now that we have established that stars are the metric for growth hacking, what is the metric for showing the project's health? In our opinion at OpenSauced, there is not one metric but a few and you can start aligning alongside stars.

There is no doubt that thanks to growth hacking we are seeing GitHub Star hyper-inflation. Now, with currency inflation, it is encouraged to find alternative places to store your assets. Still, with GitHub being the home for open source, I don’t imagine a new stargazing like currency showing up anytime soon.

Stars are not quite a representation of adoption, but if we look closer, we could correlate a combination of metrics to tell a bigger story:

Commit velocity is a quick way to see a project’s activity.
Stars are a quick way to see early interest, but there is no correlation.

_Above is a star and commit velocity charts in grafana for the makeplane/plane project.
_
There is a shift happening in open source, and I think it would be unfair to not recognize the folks that built projects that made this ecosystem, the same ecosystem that makes it so easy to become an overnight (over a few months) success.

In a conversation with Brendan Burns on that same podcast, I learned that early Kubernetes used issue counts to measure interest and pull requests to assess adoption. Taking it a step further, you can see a correlation from forks to stars.

The chart above is the correlation between stars and forks.

Based on my conversation with Brendan this correlates to adoption and when you really dig in you will find that with plane being so new, their contributions made exclusively form plane from employees, with the exception of one contribution from a developer member of the French Government. Perhaps a sign of adoption starting with them.

The logical next step is to examine contributions from organizations and determine if there's a solid star-to-PR pipeline. If you're keen on monitoring your star-to-PR pipeline, consider setting up a workspace on OpenSauced to begin uncovering valuable engagement insights.

(oss.fyi/growthhack)

As the open source landscape evolves and GitHub Stars continue to inflate, it's essential for developers and contributors to consider multiple metrics when evaluating the health and success of a project.

By looking at commit velocity, issue counts, pull requests, and forks alongside stars, we can better understand a project's adoption and overall value. Let's continue to support the open-source community by focusing on meaningful contributions and nurturing authentic engagement, ensuring that we maintain the integrity that makes open source so special.

If you have some metrics you feel are a better focus on measuring open source success, consider leaving us some feedback.

AI Grant Traction in OSS Startups

Brian Douglas — Fri, 02 Feb 2024 01:35:19 +0000

Last year Nat Friedman and Daniel Gross kicked off the AI Grant and have incubated 60 companies with the pre-seed and seed funding.

// Detect dark theme var iframe = document.getElementById('tweet-1752831181677305952-390'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1752831181677305952&theme=dark" }

Applications are open once again and I was curious to see what open source projects benefited from participating in the previous batches. My thesis is that open source provides an organic opportunity for growth and traction for AI startups.

This list was put together by tracking all public GitHub organizations that took AI Grant funding on OpenSauced. There I was able to quickly see project activity and which projects have an open source developer community alongside that matches up with the traction and engagement.

The OpenSauced AI Grant recipient list is public and viewable here.

Rowy

You know, Rowy is open-source, and it's not just for developers. I always tell this story when I start working with new engineering teams. I once built an entire database for my employer's marketing site using Google Docs and a bunch of code. Only later did I discover that companies were offering this as a service - they're called CMSs! Thankfully, I survived my over-engineering days, and now there's an even better solution: using a spreadsheet-like interface to manage a database without even realizing it.

What's cool about Rowy is that it opens up your database to the rest of your team since they probably already know how to use a spreadsheet. Low-code tools are getting more popular by the day, and Rowy stands out by using GPT-3 to generate projects and workflows.

Not too long ago, Rowy launched BuildShip, which takes things up a notch by helping users create workflows for no-code tools. You might think that no-code tools come with limitations and lock-ins, but BuildShip is here to change that. It's compatible with over a million npm packages and offers one-click deployment options to various cloud platforms like AWS and Azure.

Rowy has been around for a few years and it looks like the majority of the recent contributions still mostly come from their cofounders (marked in OpenSauced as maintainers), but it seems like they have decent traction with over 5k stars and almost 500 forks.

While searching through their GitHub repo, I saw they engage the community by allowing them to upvote items on the roadmap. This seems like a clever way to build a highly engaged userbase, and it shows.

rowyio / rowy

Low-code backend platform. Manage database on spreadsheet-like UI and build cloud functions workflows in JS/TS, all in your browser.

✨ Airtable-like UI for managing database ✨ Build any automation, with or without code ✨

Connect to your database and create Cloud Functions in low-code - without leaving your browser.
Focus on building your apps Low-code for Firebase and Google Cloud

Website • Documentation • Chat with us • Twitter

Live Demo 🛝

💥 Explore Rowy on live demo playground 💥

Features ✨

20211004-RowyWebsite.mp4

Powerful spreadsheet interface for Firestore

CMS for Firestore
CRUD operations
Bulk import or export data - csv, json, tsv
Sort and filter by row values
Lock, Freeze, Resize, Hide and Rename columns
Multiple views for the same collection

Automate with cloud functions and ready made extensions

Build cloud functions workflows on field level data changes
- Use any NPM modules or APIs
Connect to your favourite tool with pre-built code blocks or create your own
- SendGrid, Algolia, Twilio, Bigquery and more

Rich and flexible data fields

30+…

View on GitHub

Stats from the repo:

⭐ 5.5k
👀 58
Forks: 457
License: Apache-2.0

Replicate

Replicate allows you to run machine learning models using a cloud API without needing to be an expert in machine learning or infrastructure management. You can run open-source models published by others, or package and publish your own, either publicly or privately. The great part is that many of these models are open-source on GitHub, making it an excellent resource for learning.

Think of cogs as GitHub repositories that you host on Replicate for private or public use in your projects. Managing and hosting ML models can take several paths, most of which require a strong background in MLOps, which can be intimidating for beginners.

With Replicate, you can explore hosted cogs and easily integrate them into your project with just a few lines of code. I highly recommend browsing through some hosted models for inspiration for your AI side project.
Explore some hosted replicate cogs

A number of the example cogs are made from Zeke the founding Designer at Replicate. Thanks to cog model, the approach towards contribution to the Replicate open source project is really approachable and will be a driving force for more users adopting shared models on their platform.

The secret sauce for a lot of open source is making the project extensible and cogs are proving that model. Their community is growing fast and onboarding new hosted cogs every day, some with up to 100k runs.

replicate / cog

Containers for machine learning

Cog: Containers for machine learning

Cog is an open-source tool that lets you package machine learning models in a standard, production-ready container.

You can deploy your packaged model to your own infrastructure, or to Replicate.

Highlights

📦 Docker containers without the pain. Writing your own Dockerfile can be a bewildering process. With Cog, you define your environment with a simple configuration file and it generates a Docker image with all the best practices: Nvidia base images, efficient caching of dependencies, installing specific Python versions, sensible environment variable defaults, and so on.
🤬️ No more CUDA hell. Cog knows which CUDA/cuDNN/PyTorch/Tensorflow/Python combos are compatible and will set it all up correctly for you.
✅ Define the inputs and outputs for your model with standard Python. Then, Cog generates an OpenAPI schema and validates the inputs and outputs with Pydantic.
🎁 Automatic HTTP prediction server: Your model's types are used…

View on GitHub

Stats from the repo:

⭐ 6.4k
👀 62
Forks: 434
License: Apache-2.0

Chroma

Every time we've experienced a major shift in computing - from mainframes to PCs, the web, mobile devices, and the cloud - we've seen the birth of a new software stack. In this latest stack, AI takes charge of the application logic layer. It's programmed using natural language, and it's incredibly flexible. But there's more to the story than just logic - we can't forget about memory.

To handle the memory, storage, and state layers, we need a completely new approach: AI programmable memory. This goes beyond simply storing and fetching information; it actually determines what info is accessible to the AI. This is crucial for making AI systems reliable, controllable, easy to understand, and safe.

Enter Vector Databases: these specialized databases are designed to efficiently store, manage, and work with high-dimensional vector data. They're not like your traditional databases with tables or documents - instead, Vector Databases use mathematical representations of data points in multi-dimensional space. This makes searching and retrieving information faster and more accurate, especially when dealing with huge data sets or complex queries.

By taking advantage of advanced indexing and search algorithms, Vector Databases boost the performance and scalability of AI applications. They're an essential ingredient for developing next-gen AI systems, and that's where Chroma comes in. It's a Vector Database that lets users create LLMs (Language Learning Models) to power intuitive AI experiences for their users.

I recently sat down with one of the Chroma founders to discuss their unique position in the space and how they stand out from other solutions.

Their secret sauce seems to make vector searching and building knowledge bases accessible. Not only do they work in Python, a well-known language for AI/ML, but they also have JavaScript and Rust SDKs supported by the community.

chroma-core / chroma

the AI-native open-source embedding database

Chroma - the open-source embedding database.
The fastest way to build Python or JavaScript LLM apps with memory

| | Docs | Homepage

pip install chromadb # python client
# for javascript, npm install chromadb!
# for client-server mode, chroma run --path /chroma_db_path

The core API is only 4 functions (run our 💡 Google Colab or Replit template):

import chromadb
# setup Chroma in-memory, for easy prototyping. Can add persistence easily!
client = chromadb.Client()
# Create collection. get_collection, get_or_create_collection, delete_collection also available!
collection = client.create_collection("all-my-documents")

# Add docs to the collection. Can also update and delete. Row-based API coming soon!
collection.add(
    documents=["This is document1", "This is document2"], # we handle tokenization, embedding, and indexing automatically. You can skip that and add your own embeddings as well
    metadatas=[{"source": "notion"

…

View on GitHub

Stats from the repo:

⭐ 10.8k
👀 73
Forks: 882
License: Apache-2.0

Submit to the AI Grant

Gaining traction for startups can be even more challenging than building a project. Securing funding and exposure creates a win-win situation, and these projects have all benefited from being accessible to the open-source community. My thesis on open-source is validated as AI startups gain significant traction by making their projects open and extending them to the community.

If you are considering building or launching an AI project in 2024, I recommend considering submitting for the AI Grant before the deadline, February 16th. I wasn’t able to cover all open source projects that received a grant, but here a few more worth checking out:

And if you like to see the longer list of previous open source submissions checkout oss.fyi/aigrant.

Resume Driven Contributions

Brian Douglas — Thu, 25 Jan 2024 17:23:00 +0000

10 years ago my open source journey started with an email to a maintainer because I really wanted to use his library but could not figure out how to code myself out of a simple error. I was given a ton of grace and returned the favor of the maintainers' patience that unblocked me by shipping a few documentation pull requests to make sure future developers could benefit.

I have been involved in open source either directly or adjacently since that first PR. During my tenure in open source I kicked off the open source curriculum at a bootcamp where students would make legit contributions projects and learn from the experiences I lived through. Today the need for developers and bootcamps graduates looking for opportunities for contribution to open source projects has risen.

The U.S. Bureau of Labor Statistics (BLS) projects that there will be roughly 162,900 vacancies for software engineers over the decade between 2021 to 2031.

The challenge is that these opportunities can be hard to come by and we are now seeing the industry asking, “Should I contribute to open source to level up my resume?” I will answer that and more in this blog post, but first let’s break down this opportunity.

The Opportunities You Make

Based a recent Twitter thread, finding open source opportunities for the sake of leveling up one’s resume proved to be a hot topic. Thanks to the recent record number of layoffs in 2022 and 2023, I see a trend for more folks looking to make contributions. The 6-figure salary question is now, “Where are the best places to find good first issues?” I recently saw that due to some contributor frustration in normal subreddits, folks are considering making a subreddit to share insider knowledge to get contributions into open source.

In a previous post, I mentioned that good first issues do not exist and the best way to contribute is by creating an issue. I believe that contributors find more opportunities for contribution when they find a bug or issue for a project. They are in a better place to make a contribution than if one is handed to them.

As Dax says, “Contributing to oss is a side effect of using OSS.” If you are looking for the hand out or a good first issue, you are approaching the problem backwards. Opportunities in open source are the ones you make by using open source. Try your hand at using the project and challenge yourself to be a power user.

// Detect dark theme var iframe = document.getElementById('tweet-1739837931127284121-539'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1739837931127284121&theme=dark" }

The Best Contributors Are Power Users

When chatting with JJ from the Next.js core team, I learned about his interest in the project during the early days. His curiosity was met with opportunity as he leveled up his own skills by taking the opportunity to work on the framework issues. This opportunity only presented itself thanks to his desire to learn more about React, JJ chose Next.js for every project while working on consulting projects.

JJ's story

His interest got noticed by the small core team and earned him a job via the DMs. JJ mentions that this experience was the one that earned him the job he has today, maintainer on the Next.js project at Vercel. Though past performance is a predictor of future growth, I chat with contributors and maintainers to learn the secret sauce for finding these opportunities. In this case, the opportunity to build a network from open source contributions.

Building a Strong Network Through Open Source Contributions

Contributing to open source projects not only helps you level up your skills but also allows you to build a strong network within the developer community. As you work on various projects, you'll have the opportunity to collaborate with other developers, maintainers, and users. This collaboration fosters a sense of camaraderie and helps you establish connections with like-minded individuals.

By actively participating in discussions, submitting pull requests, and providing valuable feedback, you demonstrate your expertise and commitment to the project. This can lead to recognition within the community, which can open doors to new opportunities, such as speaking engagements, job offers, or even invitations to join other projects.

Moreover, your contributions to open source projects are visible to potential employers and collaborators, showcasing your skills and experience in a tangible way. This can help you stand out in the job market and make it easier for others to reach out to you for collaboration or mentorship.

Contributing to open source projects not only enhances your resume but also helps you build a strong network within the developer community, leading to new opportunities and connections that can propel your career forward.

Should you contribute to open source to level up the resume?

Now back to the question at hand. If you are looking for a good first issue, then you have already missed out. The best contribution is the one who understands and lives to tell the story. When interviewing candidates for OpenSauced, I like to hear about the hard problems engineers face and hear stories about how they can persevere. OpenSauced is unique, we are open sourced and appreciate a good contribution story. But what is not unique is there are a bunch of engineers not doing open source and getting jobs. So if you want to leverage open source as your unfair advantage, make it an advantage by showing that you care about the success of the project and have a story to share.

If you are not interested enough to become a power user, my recommendation is submit the resume and leave the open source for others to contribute to.

But if you truly want to stand out in the hiring pool, stand out as a contributor. Try using open source projects with a critical eye for fixing problems for thousands of developers. Open source is not a necessity for getting a job, and should never be. Open source is an opportunity to try new things and approach new problems.

If you are interested in discovering opportunities in open source and properly highlight your success in open source, then I encourage you to try OpenSauced.

Moneyball for engineers

Brian Douglas — Wed, 06 Sep 2023 17:22:15 +0000

A social post that went viral recently stated that if you are junior and not contributing to your green squares, you have no chance of getting a job. The tweet forced many developers with jobs to respond, but they need to respond to how hard it is to get a job today as a junior or laid-off mid-level developer.

Right now, green squares represent someone's work in open source. Squares are not a representation of a developer's resume, and to further make the point, it is also confirmed by the defunkt co-creator of the contribution graph himself.

// Detect dark theme var iframe = document.getElementById('tweet-1687944148949811200-732'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1687944148949811200&theme=dark" }

So if the contribution graph is not a measurement of one's skill, are we left to become Creator X influencers in hopes of a giant paycheck from Elon instead of that sweet 6-figure engineering money?

image credit devagrawal09 on x.com

Building influence is a beautiful way to stand out, but in a market trending towards more layoffs, we can agree that an X following is not an excellent measurement of a developer's skill.

I suggest we shift focus to Moneyball, a term popular because of Brad Pitt.

Moneyball for Engineers

The concept of Moneyball emphasizes the use of advanced statistical analysis, particularly sabermetrics, to identify undervalued and overlooked players in Major League Baseball. The Oakland Athletics popularized this concept in 2002 to win 103 games.

Like baseball, programming can apply frameworks to speed up the paths to success, ultimately leading to a sooner endgame. Developers looking at contribution graphs with a lot of green squares to one without a lot of greens is simply pattern matching. For a while, that was a great way to hire for your startup until it wasn't.

The problem is that green squares are like home runs; the more you have, the more you are noticed, but once anyone looks closely, the deepest green of squares could be nothing but performance-enhancing cron jobs.

// Detect dark theme var iframe = document.getElementById('tweet-1687912460848939008-963'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1687912460848939008&theme=dark" }

Green squares are a framework and they no longer hold value because they encourage the wrong metrics. Just like the introduction of the pitch clock, players need to adapt to stay relevant. Open source continually adapts and shifts with industry trends.

For those not aware, In September 2022, Major League Baseball announced a new pitch timer that would significantly increase the speed at which the game is played.

With new tools, languages, and frameworks coming out all the time—even the newest developers are months from achieving greatness with mentorship from suitable project veterans.

What's better than green squares?

At OpenSauced, we have been working on a way to highlight a developer's skill and expertise. Just like looking at the back of the baseball card for stats, you should see the highlights of the developer pretty quickly. This is only our first pitch at this, but it is broader way to showcase your contributions (in open source).

At this point, we can say that the data helps to show where people are participating, but the highlights show what they’re most proud of.

Highlights allow contributors to share:

The work they’re most proud of.
Their ability to clearly communicate their work and accomplishments.
The ability to identify their most impactful work.
They variety of work they’re doing. (Do you need a utility player? Someone that can write, create good issues, and PR like a boss? Or do you want someone who swings for the fences and is dependable for creating features in high-stakes situations?)

If you find your profile lacks contribution, get some quick hits by checking our #100daysofOSS challenge to level yourself up quickly.

We’ve seen it time and again. Open source is more than code—it's a journey of growth and opportunity. Your contributions reverberate far beyond lines of code; they forge connections, foster mentorship, and move you towards new and unexpected pathways. So, keep collaborating, innovating, and contributing—because the world of open source is not just about code but the opportunities it unlocks for your personal and professional journey. For example, Sunday’s open source journey that led to his role at OpenSauced.

Events like Hacktoberfest emphasize getting enough contributions within the month to earn a reward, but we need to develop the idea of a tangible reward. Part of it is the career, but it takes the journey to get there. You grow in skills, have the opportunity to learn together, build your reputation, and expand your network so that you’re never without a chance, support, and personal fulfillment.

Look beyond the fences of open source and put yourself in a place to knock it out of the park.

oss.fyi/100days

Practical advice for finding GitHub issues to work on

Brian Douglas — Wed, 19 Jul 2023 16:53:41 +0000

There is countless advice on finding projects and, eventually, GitHub Issues to work on, but it's mainly repeated content. I want to approach this with a new lens and focus on practical advice to make your next meaningful contribution to open source.

Though prevalent advice, never look for good first issues first. Instead, connect with people.

The best first contribution is saying "hello" in Discord. So for the sake of this guide, I'd recommend working on projects where you can chat with the maintainers and contributors. This cuts out a lot of noise and gets you focused on projects where you can get meaningful mentorship. Some small projects don't have discords and communities, and that's ok. I suggest focusing efforts on areas you can contribute, so if you are looking for projects to contribute, look at places with many active contributors and note what they are actively working on.

In OpenSauced, you can create a custom insight page for projects you want to connect to. Check out that guide here.

Practical Steps to Find Your Next Contribution

Now if you already have the context of the project and the community, you are in a great place to start contributing. For the rest of this article, we will focus on practical advice on finding what to work on next. For those who want to know the context up front, below are the contribution areas I will recommend:

Running the project locally
Improving the developer experience
Establishing Credibility by Enhancing Documentation
Considering performance & accessibility

For the sake of providing practical advice, my examples will use the Astro project, but you should choose a project you are interested in for this exercise.

withastro / astro

The web framework for content-driven websites. ⭐️ Star to support our work!

Running the project locally

This is a crucial step for anyone making code contributions or updating documentation about how to run and use the project and is often overlooked. It is impressive to meet a vegan butcher, but that is the outlier, not the norm. Be normal and try using the project first. By running the project locally, you learn more about the project, experience, and any challenges or surprises you might face.

Make it a challenge to clone the project and run the test suite. Astro provides an "Open in Codespaces" button in the CONTRIBUTING.md, which gets there as fast as possible. If you get stuck or do not have context on a concept from that experience, find a person in the contributor community to share that context.

The core project can be daunting, which is fine as well. There are countless Astro examples that you can perform the same tasks in.

MicroWebStacks / astro-examples

Astro design patterns examples, client-server state management, markdown, caching

Improving the Developer Experience

By using the project you're more likely to be able to improve the developer experience. Find any and every way to use Astro in a side project and run through the examples in the docs guide section. Astro already has a great guide and tutorials section that has been developed after months of feedback from folks like you. But the thing there is that after months things change.

Try walking through the guides to gain knowledge about building an Astro project. If you learn something, share those insights with the community via DEV post. Your experience is unique, and it can be very hard to know what it's like learning a new technology the first time.

DevEx and OSS- Elevating Developer Experience through Open Source Collaboration

BekahHW for OpenSauced ・ Jul 3 '23

#devex #career #opensource #devrel

Very few beginner guides for projects exist because many beginners believe that experienced community members already possess their insights. But the beginner experience can only be shared once, making it the most valuable insight a new community member can provide.

Most maintainers need more time for community support as the project grows. Community support and triage is one of the best ways to level up and learn ways to improve the developer experience for the project.

Establishing Credibility by Enhancing Documentation

In the case of Astro, they have a docs site that includes instructions on how to use the project. There are two approaches to documentation that I'll cover here, documentation that improves how the information is shared and the necessary context provided and documentation that has to do with running and using the code.

If you're adding to or revising the documentation that doesn't require you to have knowledge of the codebase, make sure you provide a clear reason for the revision or introduction to new information in the documentation. The maintainer should be able to see from the issue your write or your Pull Request description, which this is an important update to the documentation.

For example, if you're reorganizing the documentation, provide a clear description of why the reorganization is necessary and will improve the developer experience.

If you're making a contribution, I strongly suggest using the project first. If you haven't used due to a lack of context limitation, consider leveling yourself with context through a conversation with a community member or contributor.

While using the project, note any unclear installation steps and weirdness in your environment. If you are running into errors, this is an opportunity to open an issue to confirm if this is isolated to you and your environment or impacting others.

Search the issues for existing conversations before opening any new issues. Read through merged pull requests to understand the project's history and why some decisions were made. This is a great way to learn who are the decision makers too.

Some issues regarding developer experience would be enhancements for the docs sites—one regarding improving Firebase Deploy.

Stop looking at large projects and starting in a place that needs your help even more, smaller projects. Starting in a smaller project's README will likely lead to you finding areas for providing value much faster than searching endlessly through open issues in a large project. Support the little projects with your time if you have it.

note: If you say you will do something, provide an update at the end of the week. If you can't complete it, unassign yourself and provide an update for why.

If you do not experience issues, that is great. There are several technologies that Astro works alongside, and only some cases are covered in the documentation. Using the technology will eventually lead to discovering issues and perhaps good first issues you can approach.

When writing this article, the Astro docs site has a recipe section, which includes instructions on how to deploy to various services. There is no section on how to deploy to Digital Ocean within that recipe section.

I'll leave this for the reader's exercise, but that would be where I'd start: building a project in Astro,
deploying the project to a production cloud host, and

leaving notes for the next person in a findable location-probably the documentation.

Considering performance & accessibility

Once you have established credibility through content and building with Astro, I'd consider a meaningful change. I recommend not trying to add any new features but instead showing you care by looking into ways to improve the project's performance and accessibility.

Astro has some integrations in accessibility and performance. Similar to the previous sections, the tool is the best way to understand.

This requires time and even gives you a deeper understanding of the project without adding any new libraries, audit pages, and boot speeds. Identify if the project meets all standards in its documentation pages. Be genuinely helpful in places most others overlook.

The goal here is to be intentional and not simply run a lighthouse audit with any practical or actionable advice. I suggest running an audit through an Astro example site or one you have built. Look for places for improvement where individuals learn how to use Astro.

The documentation also has a section on how to build Astro integrations. Integrations and add-ons are a great place to explore providing value. Often, these enhancements live outside the repo you are trying to contribute, which makes for a great place to experiment and find things to work on.

https://astro.build/integrations

Find an existing Astro example and leverage integration to identify areas of improvement by running a quick audit to provide that actionable insight.

That wraps up this guide, but let's continue. You should look for ways to make an impact in open source beyond the green square. Consider pledging 100 days to this path and check out the #100daysOfOSS.

#100DaysOfOSS: Growing Skills and Real-World Experience

BekahHW for OpenSauced ・ Jul 12 '23

#opensource #github #career #challenge

If you have any other tips for how to start contributing. Leave a comment with them below.

Highlight Your Open Source Contributions

Brian Douglas — Thu, 29 Jun 2023 15:07:58 +0000

Having a portfolio of work to lean on is critical in this job market. The challenge folks face is highlighting their work on projects showcasing their ability to work successfully within organizations.

I share practical ways to showcase your skills and open-source contributions in this post.

Make open-source contributions

Open-source projects provide a public way to showcase your technical skills and expertise. Some guides and articles provide a path to contributing already. If you need an introduction to contributing, please check out this post from Bekah below:

Open Source 101: A Beginner's Guide to Getting Started

BekahHW for OpenSauced ・ Jun 21 '23

#opensource #beginners #codenewbie #learning

Years ago, I worked at a boot camp, crafted an apprenticeship for finding open-source projects to work on, and even mentored students to contribute to projects for the first time. I learned from that experience that finding good first issues and projects to work on takes most of the energy when contributing.

I suggest following a different path entirely. Find someone who has contributed to open source and talk to them directly. In fields requiring technical skill, an apprenticeship is the best setup for learning a trade. If you want to contribute to TypeScript projects, find someone who contributes to TypeScript projects and ask them questions.

OpenSauced provides a chrome extension to discover GitHub users making contributions, and we are working on features to make those connections more accessible in the future. For now, reach out to folks for a quick DM or Zoom call, but I caution you to be intentional. I cannot overstate this enough; human interaction can take so much further beyond endless repo spelunking.

If you've already contributed to an open-source project, congrats. You are the perfect person for a new contributor to chat with. Please do us a favor and comment in the reply with your contribution. Please share your story so that we can highlight it with you.

Summarize your contribution with a pull request description.

Your opportunity to shine is highlighting the knowledge you learned while solving a problem. I have seen a lot of first-time contributions, and I have also done a lot of technical screens for engineering candidates. My ask is always, “Please tell me about your approach.” The explanation is not for me but for you. We can confirm that code works thanks to AI and automated testing libraries, but I can’t ensure you know why and how the code works unless you explain it in the description.

Most contributions happen in a vacuum, and after all that effort and work, you may never mention or reference it again—what a loss!

Green squares eventually fade, and the contribution calendar looks hella empty on January 1st every year. Instead of forgetting your good prune git history, please share it. There is a way to highlight that contribution that makes you more discoverable and quickly recalled when presenting your accomplishments in a job interview or reciting commits during a conference talk.

If you do not know what to put in your PR description, consider checking out Sunday's post:

Leveraging OpenSauced AI to Generate Compelling PR Descriptions

OGBONNA SUNDAY for OpenSauced ・ Jun 7 '23

#opensource #openai #github #productivity

There is a belief that the code is the best description, and there is no real need for a pr description. As developers, we sometimes must remember to celebrate wins and share stories about code merging. From my experience, the best developers I have worked with are the ones that educate me about the code they write. I get better, and the team gets better because of it.

Share your highlights with the world.

After the contribution is merged, consider writing a DEV post about the experience. In the OpenSauced platform, we offer a feature called highlights, which you can consider the step before you DEV post.

https://insights.opensauced.pizza/feed/199

I also mentioned reaching out to folks who have contributed already. The Highlights feed is that list for you. You filter based on a project today, but we hope to have an updated experience for sourcing top contributors soon.

(the updated experience)

At OpenSauced, we are looking to break the barrier for contributors in open source with our newest feature, Open Sauced Highlights, ushering in a new phase of Social Coding.

Where an average contributor may contribute to one project during their career, we see an opportunity to highlight those contributions and share your experience with others. We would love to see your highlights, whether you are starting in open-source or the core maintainer of analog.

Start by linking them below.

A Rounded Solution to Image Handling on the OpenSauced Dashboard

Brian Douglas — Wed, 17 May 2023 21:46:54 +0000

This post is about the journey we took to improve the OpenSauced Dashboard, which provides valuable insights on open-source contributions.

Last October, we had an alpha launch of the new OpenSauced Insights dashboard. This launch was to coincide with the biggest open-source hackathon, Hacktoberfest. Our goal was to provide insights and reports on the number of contributions accepted, merged, and even spam. Since then, the dashboard has evolved beyond Hacktoberfest data and now includes GitHub avatars representing active and open GitHub Pull Requests in the last 30 days.

If you’d like to see your open source contributions connect your GitHub account to OpenSauced.

Challenges Faced

At the beginning, our team encountered challenges in sourcing and manipulating GitHub avatars to display a scatter plot e-chart on the dashboard. We struggled to find a suitable solution, especially when it came to handling a large number of images efficiently.

As part of this challenge, GitHub has an aggressive rate limit when you're not authenticated when requesting resources, like avatars from a URL. We needed to fetch the avatar, manipulate them, and then cache them. Because our product was meant to be public, we would attract a lot of usage, and it could cost real money quickly.

Solution: Leveraging nivo and Cloudinary

To overcome these challenges, the team turned to the nivo chart library for visualizations and Cloudinary for image manipulation and caching 271k images. We successfully integrated nivo charts into our dashboard, thanks to its rich set of data visualization components built on top of d3 and React.

By leveraging Cloudinary's image manipulation capabilities and caching strategy, we were able to round the avatars and seamlessly integrate them into the dashboard.

Today this works thanks to nivo and Cloudinary, but that journey included a lot of trials and testing for the perfect solution.

Nivo is an open-source library that provides a rich set of data visualization components built on top of the awesome d3 and React libraries.

plouc / nivo

nivo provides a rich set of dataviz components, built on top of the awesome d3 and React libraries

nivo provides supercharged React components to easily build dataviz apps it's built on top of d3.

Several libraries already exist for React d3 integration but just a few provide server side rendering ability and fully declarative charts.

Installation

In order to use nivo, you have to install the @nivo/core package and then choose some of the scoped @nivo packages according to the charts you wish to use:

yarn add @nivo/core @nivo/bar

Features

Highly Customizable
Motion/Transitions, powered by react-spring
Interactive Components Playground
Exhaustive Documentation
SVG Charts
HTML Charts
Canvas Charts
Server Side Rendering and HTTP API
Patterns & Gradients
Theming
Responsive Charts

Discussion

Join the nivo discord community.

Packages & components

nivo is comprised of several packages/components, for a full list, please use the Components Explorer.

Guides

Backers

Donations are welcome to help improving nivo [Become a backer]

Open Collective Sponsors

…

View on GitHub

Cloudinary is a hosted solution to manipulate and cache images for reuse.

Handling Image Processing with Apache E-charts

Before adopting nivo and Cloudinary, we initially used Apache E-charts (specifically a React wrapper called echarts-for-react) to handle image processing and loading. This approach proved extremely slow, and it was quite the process in figuring out a better solution while we had a real-time constraint.

The Journey to Finding Solutions

We faced a challenge being able to provide images on the page that were sourced directly from GitHub. The avatars needed could be cached and manipulated to match our rounded image design. The total number of displayed contributors during the event was around 150k, and today close to 300k contributors are represented as contributions in the most popular open source repositories on OpenSauced.

The e-charts for React solution gave us no access to the images when rendered, and provided limited options to edit the chart after it was displayed. We built our product in Figma designs first and were excited at the opportunity to have rounded images. Still, our e-chart library would only allow plain & squared images, and also any manipulation of the image was the challenge.

[design]

[reality]

There comes a time in every developer's career where you are presented a design that may be just out of reach or out of scope. The simplest request around the images broke our charts and required the entire team to brainstorm solutions.

You can see that brainstorming in our now closed issues.

Comment for #373

bdougie commented on Sep 16, 2022

Hey another thought here. What if we add cloudinary processing the images and pass those urls? This would give us the ability transform (border and round) the images, as well as cache them some where.

Alternatively, we could use imagemagick (cli tool for image transforms) + supabase storage to do the same for free.

@brandonroberts have you done anything like this before?

View on GitHub

Solution 1: JavaScript Approach

Our first attempt was manually rounding the images using a quick lib function I threw together.

function applyBorderRadius(imageElement) {
  imageElement.style.borderRadius = '50%';
}

// Get the image element
var image = document.getElementById('myImage');

// Apply the 50% border radius
applyBorderRadius(image);

It's always good to start with an approach, even if it is wrong.

This first solution needed to be corrected and didn't work because the images were limiting the e-chart with images on a scattered chart. We could not get direct access to the elements to manipulate after the fact.

We needed a way to manipulate the images before sending to the chart.

Solution 2: Imagemagick for Rounding Images

ImageMagick is a fun open-source platform for displaying, creating, converting, modifying, and editing images. I had some experience working with ImageMagick at a previous employer and quickly found a solution to round the images before sending to the chart.

But when I found a stackoverflow answer doing something similar, I opted to use that instead.

https://images.weserv.nl/?url=https://www.github.com/bdougie.png?size=60?v=4&h=300&w=300&fit=cover&mask=circle&maxage=7d

Link to this solution

This was working, but we still needed to solve the caching issue.

I really wanted to try out building a service to use ImageMagick + the new Supabase storage to do this, but I wasn't willing to maintain that solution and we only had a little time to explore more unique tools.

(If you want to build a service like this, find me, and I would love to be a beta tester.)

We needed a way to cache the images before sending to the chart and started looking at tools or services to make this easier.

Solution 3: Leveraging Cloudinary for Image Manipulation and Caching

To solve the caching issue and optimize image processing, we explored different tools and services.

Cloudinary offers image manipulation and a caching strategy. They also have a generous free tier--but for full transparency, I'll point out that our initial amount of data for Hacktoberfest was pushed up to the paid tier immediately.

https://res.cloudinary.com/bdougie/image/fetch/f_auto,q_auto/w_400,h_400,c_crop,r_400,g_auto/v1/https://avatars.githubusercontent.com/u/5713670

Link to Cloudinary solution

You can see the PR with the solution live as well.

feat: Leverage cloudinary for round images #467

bdougie posted on Sep 30, 2022

What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑‍💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description

This PR is intentionally set up to replace cloudinary in the future. As Vortex has point out this solution will eventually cost real money. The trade off is that we will eventually make real money from this product and using that to pay for this, balance out.

Details

Adds cloudinary url to edit and cache avatars on the fly.
Only github.com urls can be edited. I am enforcing this on the cloudinary side.

Related Tickets & Documents

fixes #373

Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[x] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

Complete this issue https://github.com/open-sauced/insights/issues/468

[optional] What gif best describes this PR or how it makes you feel?

View on GitHub

The solution was building a wrapper around using the GitHub avatar as the imageUrl.

// lib/utils/roundedImages

const roundedImage = (imageUrl: string, cloudName: string | undefined) => {
  return cloudName
    ? `https://res.cloudinary.com/${cloudName}/image/fetch/c_fill,g_face,h_300,w_300,bo_20px_solid_white,r_max/f_auto,e_shadow/${imageUrl}`
    : imageUrl;
};

// components/organisms/Dashboard/dashboard.tsx

import roundedImage from "lib/utils/roundedImages";

scatterChartData = prs.map(({ updated_at, linesCount, author_login }) => {
      const author_image = author_login.includes("[bot]") ? "octocat" : author_login;

      const data = {
        x: calcDaysFromToday(new Date(updated_at)),
        y: linesCount,
        contributor: author_login,
        image: roundedImage(`https://www.github.com/${author_image}.png?size=60`, process.env.NEXT_PUBLIC_CLOUD_NAME)
      };
      return data;
    });
  }

Link to code

The interaction with Cloudinary is all URL based, allowing us to pass the GitHub user id as an option on the fly. The same id is also used to recall the cached image, meaning we have had caching by default. We also did not need to build any new infrastructure for this.

With the initial 150k user profiles cached, we immediately needed to pay $90 per month for the pro tier, which we felt is reasonable and predictable for us.

We are still on the same Cloudinary plan today, mainly due to the inertia and the fact that we still need to be ready to build and maintain something not core to our product. So far, Cloudinary is caching 271k image transforms for us.

This scenario is a classic build vs buy scenario where we could build our own caching and image storage on S3, but the tech debt imposed on a solution like that was not our priority. The $90 was also not going to put us into debt either.

Migration to nivo Charts

In December, we made the switch from Apache E-charts to nivo charts due to its modern features and active community. The decision was driven by the outdated state of E-charts and the limited contributions it received. We plan to contribute upstream to nivo to improve its integration and interaction with images.

We have an active conversation in the nivo discussions about this and other feature enhancements. The maintainer has been really responsive, and we look forward to contributing upstream to support the project.

Support a popover like behavior for tooltips #2201

OgDev-01 posted on Dec 15, 2022

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Currently working on a project and making use of the scatterplot chart. But discovered some limitations with the tooltip provided

Tooltip can't be hovered on

https://user-images.githubusercontent.com/62995161/207777072-97967a39-3b3c-4507-b978-2164cc2df77c.mov

Describe the solution you'd like A clear and concise description of what you want to happen.

A behavior similar to GitHub hovercard where we can hiver on the tooltip itself

https://user-images.githubusercontent.com/62995161/207776852-7d605c29-e78c-459f-b99f-f5a1b83e2fde.mov

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

View on GitHub

If you have any thoughts or comments about our approach or have alternative solutions to share, we welcome your input. Let's continue learning from each other and enhancing our open-source projects.