Operately is an open-source company operating system for coordinating goals, projects, and teams. It provides a full collaboration suite including spaces (groups), goals with OKRs, project management with milestones and tasks, check-in cadence, retrospectives, discussions, document and file management (Resource Hubs), KPI tracking, and people management. The system is built as a monolith with a Phoenix (Elixir) backend serving a custom TurboConnect API (mutation/query protocol) and a React/TypeScript single-page application frontend with a reusable component library (turboui). It also offers a CLI tool, Model Context Protocol (MCP) integration for AI agents, and extensive background job processing via Oban for notifications, email delivery, search indexing, and billing operations. The architecture follows a clean domain-driven design with operations (Ecto.Multi transactions), activity logging (event sourcing with embedded schemas), an access control system with hierarchical groups and bindings, and a rich content editor with link enrichment and blob storage. The codebase is well-tested with both backend (ExUnit, Wallaby) and frontend (Jest, React Testing Library) tests, and includes a demo data builder for development. The enterprise edition (ee/) extends the core with SaaS admin capabilities, billing management via Polar, site messages, and feature flags. The system has evolved significantly with over 115 data migrations, indicating active development. While the core architecture is solid and many patterns are reusable, there are some incomplete features (e.g., stubbed notification handlers, missing email templates) and occasional code duplication between internal API and MCP tool layers. Overall, it demonstrates strong engineering craftsmanship with practical trade-offs for an open-source SaaS application.
DockYard/elixir-mail is an Elixir library for building, parsing, and rendering email messages according to RFC 2822 and related MIME standards. It provides a composable API to create simple and multipart email messages, handle various transfer encodings (Base64, Quoted-Printable, 7bit, 8bit, binary), and parse incoming email into structured data. The library is structured around a core `Mail.Message` struct with separate modules for encoding, parsing, rendering, and MIME type lookup. It does not require any external runtime dependencies beyond the Erlang/OTP standard library.
Anoma is an Elixir/OTP implementation of the Anoma protocol - a distributed operating system for intent-centric applications. The codebase implements a full node architecture with multiple supervised engines: Mempool (transaction submission/ordering), Ordering (consensus sequencing), Executor (parallel transaction execution), Storage (Merkelized key-value store with RocksDB/Mnesia), Shard (partitioned KV store with watermark-based concurrency), IntentPool/Solver (intent matching and composition), Logging (event persistence and replay), and Transport (gRPC/IntraNode networking with proxy-based remote node communication). The system uses Nock/Noun as its core computation model (via anoma-lib), with a Cairo backend for shielded/zero-knowledge transactions. Transactions are submitted as jammed Nock nouns, executed in isolated workers, and results flow through an event-driven architecture (event_broker). The node supports distributed operation via gRPC transport with automatic peer discovery and advertisement. Key architectural patterns: CQRS-style engines (casts for mutations, calls for queries), typed event definitions with filters (defevent macro), supervisor hierarchies with dynamic child management, and a replay mechanism that validates persisted state on restart by spinning up a mock node. The codebase follows an "examples over tests" philosophy - extensive executable examples in lib/examples/ serve as both documentation and integration tests.
Firezone is a zero-trust network access platform providing secure remote access through VPN-like tunnels. The production system consists of a cloud-based management portal (Elixir/Phoenix), data-plane components (Rust gateways and relays), and native clients for macOS/iOS, Android, Windows, and Linux. The portal manages multi-tenant accounts, identity (OIDC, SAML, email OTP, X.509), access policies, device posture, and logs. It exposes a REST API (PortalAPI) for CRUD operations and WebSocket channels for real-time client/gateway connectivity. The Rust core (connlib) handles ICE/STUN/TURN connectivity, WireGuard tunnels, and eBPF-accelerated packet routing. PostgreSQL is used for persistence with logical replication for change data capture, Oban for background job processing, and Redis for caching/presence. External dependencies include identity providers (Entra, Okta, Google Workspace), device management systems (Intune, Defender, SentinelOne, etc.), log sinks (Splunk, Datadog, Elastic, S3), and billing (Stripe). The architecture separates the web admin interface (PortalWeb), REST API (PortalAPI), and internal ops (PortalOps) into distinct endpoints. Data-plane components (gateway, relay) communicate via WebSockets with the API to receive policy updates. Clients connect to relays using ICE/STUN/TURN. The system uses Phoenix PubSub for real-time updates and Postgres logical replication to propagate changes to connected clients and gateways. Key entry points: PortalWeb.Endpoint (admin UI), PortalAPI.Endpoint (REST/WebSocket for clients and gateways), PortalOps.Endpoint (ops dashboard). Rust binaries: firezone-gateway, firezone-relay, firezone-headless-client, firezone-gui-client. Mobile apps: Firezone iOS/macOS (Swift), Firezone Android (Kotlin).
This is an IntelliJ IDEA plugin providing comprehensive Elixir language support. It implements a full IDE integration: lexer/parser for Elixir, BEAM bytecode decompiler, debugger with line breakpoints and variable inspection, EEx/HEEx template support, code insight (completion, navigation, refactoring, inspections), SDK management for Elixir/Erlang, and integration with external tools (Credo, Dialyzer, mix format). The architecture is a monolith within the IntelliJ Platform, with generated PSI from Grammar-Kit and hand-written Kotlin/Java modules for resolvers, annotators, formatting, and debugger backend. The codebase demonstrates strong engineering practices: read-lock discipline, coroutine-based concurrency, modular operator interfaces, and systematic test coverage (parser definition tests, variable oracle tests, formatting tests). It is actively maintained with frequent releases tracking IntelliJ Platform API changes. The repository is not a data or research project; it is a production-quality IDE plugin.
Symphony is an autonomous AI agent orchestration service written in Elixir/Phoenix, designed to manage coding agents (like OpenAI's Codex) that resolve issues from project trackers. In production, it polls Linear, GitHub, GitLab, Jira, or Asana for new work, creates isolated per-issue workspaces, launches Codex agents with provider-native tools, manages retries and backoff, and provides live observability via a terminal dashboard and optional web UI. The architecture follows OTP best practices: a supervisor tree with GenServers for the orchestrator state machine, polling loop, status dashboard, and tracker adapters. Key entry points include the CLI (`SymphonyElixir.CLI.main`), the Phoenix web endpoint, and Mix tasks for code quality checks. Data flows are event-driven: poll tracker -> normalize to Issue struct -> dispatch via AgentRunner -> create workspace -> run Codex turns -> cleanup. The system is explicitly experimental ("engineering preview") but demonstrates strong engineering in its adapter pattern, configuration design, and test infrastructure.
This is a personal dotfiles repository for macOS, automating the setup of a developer environment. It is not a traditional application but a configuration management system using dotbot to symlink config files and Homebrew to install software. The repository manages shell configuration (zsh with oh-my-zsh and zplug), editor settings (VS Code, nano, hyper), browser hardening (Firefox/Zen with arkenfox user.js), macOS system preferences, and a curated set of CLI tools and applications. The core entry point is a bash install script that runs dotbot pipelines. The codebase is well-organized, follows minimalism and security principles, and is actively maintained by a single developer. It demonstrates thoughtful patterns for fzf integration, Docker-based AI agent runners, and peripheral auto-launching, though it remains a personal configuration rather than a reusable library.
Katbin is a pastebin service (pastebin/paste.rs-style) built on Cloudflare Workers with Hono, D1 (SQLite) via Drizzle ORM, and a Vite + React frontend styled with Tailwind CSS. It supports paste creation with syntax highlighting (highlight.js), markdown rendering, raw paste access, and configurable expiration. The service includes usage analytics with documented visitor limits, differentiated rate limiting (missing raw pastes are limited separately from existing ones), and admin routes that enforce authentication before executing any queries. Deployment is fully automated via GitHub Actions with separate production and staging environments, including D1 migration management through wrangler. The codebase demonstrates strong engineering practices: type-safe database access, careful analytics implementation with explicit visitor limit documentation, and security-conscious route design. The test suite covers API error handling, analytics edge cases, and rate limiting behavior.
Honey Potion is a compiler framework that translates a subset of the Elixir programming language into eBPF (extended Berkeley Packet Filter) programs, targeting both tracepoints and XDP. The system works as an Elixir library (published on Hex as `honey`) where users write eBPF logic in Elixir using macros like `@sec`, `defmap`, and `fuel`. At compile time, `__before_compile__` triggers a pipeline: static analysis, optimization (constant propagation, dead code elimination, type propagation), AST-to-C translation, boilerplate generation, and C compilation via `make`/`clang`/`llc`/`bpftool`. The generated C code includes a custom runtime with heap, tuple pool, and string pool implemented using BPF maps to overcome eBPF's stack and memory constraints. The repository includes 20+ example programs (system monitors, packet filters, data structure demos) and a comprehensive benchmark suite comparing hand-written C eBPF programs to Honey-generated ones, supporting a published research paper. Although classified as an application (a compiler library), the project has strong research characteristics with reproducible artifact scripts, optimizer variants, and performance comparisons.
This repository is a curated list of interesting open source projects organized by programming language. It contains markdown files with links and descriptions for each language. There is no application code, data pipelines, or analytical models. It serves as a reference directory for developers seeking open source projects to contribute to or learn from. The repository is well-maintained with recent updates and a large community following.