diff --git a/app/[slug]/page.tsx b/app/[slug]/page.tsx
index bd1fbe6..4806b77 100644
--- a/app/[slug]/page.tsx
+++ b/app/[slug]/page.tsx
@@ -253,7 +253,7 @@ export default async function BlogPostPage({ params }: PageProps) {
                   className="h-11 w-11 shrink-0 overflow-hidden rounded-full ring-1 ring-neutral-200 transition-colors hover:ring-neutral-400 dark:ring-neutral-800 dark:hover:ring-neutral-600"
                 >
                   <Image
-                    src="/ossium_logo.webp"
+                    src={post.avatar ?? "/ossium_logo.webp"}
                     alt={post.author}
                     width={44}
                     height={44}
@@ -263,7 +263,7 @@ export default async function BlogPostPage({ params }: PageProps) {
               ) : (
                 <div className="h-11 w-11 shrink-0 overflow-hidden rounded-full ring-1 ring-neutral-200 dark:ring-neutral-800">
                   <Image
-                    src="/ossium_logo.webp"
+                    src={post.avatar ?? "/ossium_logo.webp"}
                     alt={post.author}
                     width={44}
                     height={44}
diff --git a/content/posts/README.md b/content/posts/README.md
index 27d3d73..e2eae60 100644
--- a/content/posts/README.md
+++ b/content/posts/README.md
@@ -23,6 +23,7 @@ publishedAt: 2026-07-11
 updatedAt: 2026-07-11
 author: ossium
 authorUrl: https://ossium.in
+avatar: /logo/opencode-logo-dark.png
 featured: false
 draft: false
 image: /demo/oss_landingpage.webp
@@ -39,6 +40,10 @@ answerSummary: "Only for type=question - short answer for FAQ rich results."
 | `howto` | Step-by-step workflows |
 | `question` | FAQ / “What is…” pages (adds FAQ JSON-LD when `answerSummary` is set) |
 
+## Author avatars
+
+- `avatar` is optional. If omitted, the post page shows the ossium logo as the author avatar.
+
 ## Tips for ranking
 
 - One primary keyword intent per post  
diff --git a/content/posts/best-new-open-source-launches-of-2026.md b/content/posts/best-new-open-source-launches-of-2026.md
new file mode 100644
index 0000000..e6ca6c5
--- /dev/null
+++ b/content/posts/best-new-open-source-launches-of-2026.md
@@ -0,0 +1,45 @@
+---
+title: "Best New Open Source Launches of 2026"
+description: "An honest roundup of open source projects that gained serious traction in 2026, grouped by AI coding tools, local models, self-hosted apps, databases, and dev tools."
+type: article
+category: tools
+tags: [new open source projects, open source launches 2026, ai coding tools, local models, self hosted apps]
+keywords: [best new open source launches 2026, new open source projects 2026, open source ai tools 2026, self hosted apps 2026, open source databases 2026]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Every year produces a handful of open source projects that go from a repo link on Hacker News to something people actually build on. This is a curated look at the ones that gained real traction in 2026, grouped by category. One honest caveat up front: I am not going to pin an exact launch date on every project. Some of these shipped years ago and hit their stride in 2026, and for those I say they gained traction recently rather than invent a release date.
+
+## AI coding tools
+
+The most visible launches this year were coding agents. [Cline](https://github.com/cline/cline) matured from a VS Code extension into a general agent with tool permissions, and its model-agnostic design means it runs on local models just as easily as on paid APIs. [OpenHands](https://github.com/All-Hands-AI/OpenHands) pushed autonomous, multi-file development further, with an agent framework that people are embedding into their own pipelines rather than just using as a chat tool.
+
+[Aider](https://github.com/Aider-AI/aider) did not launch in 2026, but it deserves a mention because it is still the reference implementation for how a terminal agent should handle git diffs. And [Qwen Code](https://github.com/QwenLM/qwen-code) shows how far open weights have come: a capable coding model and agent released as weights you can actually run yourself. There is more depth on the local side in [our coding LLM post](/what-is-the-best-local-llm-for-coding-in-2026).
+
+## Local models and open weights
+
+The model space in 2026 is not about one flagship release. It is about small, capable models that run on consumer hardware. The Qwen family stayed dominant for size-to-quality ratio, DeepSeek kept pushing reasoning models as open weights, and Meta kept iterating on Llama. One genuinely open (not just open weights) release worth watching is [OLMo](https://github.com/allenai/OLMo) from the Allen Institute for AI, because it publishes the training data and recipes along with the weights, which is still rare.
+
+Be precise about the terminology here: most of these are open weights, not open source in the OSI sense. The weights are downloadable and usable, but training data and often the training code are not public. That distinction matters and is worth a read in [how open source licensing works](/how-open-source-licensing-works).
+
+## Self-hosted apps
+
+Self-hosting had a strong 2026. [Immich](https://github.com/immich-app/immich) became the default Google Photos alternative for people who run their own servers, with steady releases improving search and face grouping. [n8n](https://github.com/n8n-io/n8n) went from a niche automation tool to a genuine Zapier competitor, helped by its fair-code license and a huge library of integrations. [PocketBase](https://github.com/pocketbase/pocketbase) keeps growing because one binary gives you auth, a database, and file storage, which is a remarkably pleasant starting point for side projects.
+
+Open WebUI continued to be the front end of choice for local LLM setups. If you want a broader list, the [31 new open source tools](/31-new-open-source-tools) post covers a wider sweep.
+
+## Databases
+
+DuckDB did not launch this year, but it is impossible to leave out of any 2026 list because it became the default tool for analytical queries on local files, to the point that data folks reach for it before CSV libraries. [SurrealDB](https://github.com/surrealdb/surrealdb) kept improving its multi-model approach, and the vector database field stayed crowded but healthy, with [Qdrant](https://github.com/qdrant/qdrant) and [LanceDB](https://github.com/lancedb/lancedb) both shipping meaningful updates. On the dataframe side, [Polars](https://github.com/pola-rs/polars) has been eating pandas' lunch for speed and stays one of the fastest-moving data projects around.
+
+## Developer tools
+
+In dev tooling, the Astral projects were the story of the year. [uv](https://github.com/astral-sh/uv) effectively replaced the entire Python tooling workflow for a huge share of developers, and [Ruff](https://github.com/astral-sh/ruff) did the same for linting and formatting. [Bun](https://github.com/oven-sh/bun) kept pushing the all-in-one JavaScript runtime, and [Biome](https://github.com/biomejs/biome) established itself as the fast replacement for the aging prettier-and-eslint combo. [oxc](https://github.com/oxc-project/oxc) is the one to watch underneath, since its Rust-based compiler and linter components are increasingly used as building blocks by the tools above.
+
+## Reading the list
+
+None of this is a guarantee that any project will stay on top. Software trends are short, and 2026 has already seen forks and rewrites overtake once-dominant tools. Judge these on your own machine, check the license, and pick what fits your workflow rather than what has the most stars this week.
diff --git a/content/posts/best-open-source-ai-ml-frameworks.md b/content/posts/best-open-source-ai-ml-frameworks.md
new file mode 100644
index 0000000..86c15b1
--- /dev/null
+++ b/content/posts/best-open-source-ai-ml-frameworks.md
@@ -0,0 +1,45 @@
+---
+title: "Best Open Source AI/ML Frameworks"
+description: "PyTorch, TensorFlow, scikit-learn, JAX, Hugging Face Transformers, LangChain, Ollama and vLLM compared honestly, including the difference between open weights and OSI open source licenses."
+type: article
+category: tools
+tags: [best open source ai frameworks, open source machine learning, pytorch, transformers, ollama, vllm, open weights]
+keywords: [best open source ai ml frameworks, open source machine learning frameworks, pytorch vs tensorflow, ollama vs vllm, open weights vs open source]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Licensing matters more in AI than anywhere else, because "open source AI" now covers two very different things: code you can legally ship and modify, and model weights that come with a document telling you how you may use them. The two are frequently confused, and the confusion has real cost when you go to production.
+
+## Deep learning frameworks
+
+PyTorch is the default for research and for most production deep learning. BSD-3 licensed, a Python-first design that beats anything else for iterating on a model, and the ecosystem around it, Hugging Face, Lightning, distributed training tooling, is the largest in the field. If you are starting today, start here.
+
+TensorFlow remains a serious production choice, Apache 2.0, especially where you already rely on its serving and deployment stack, TFX, TensorFlow Serving, and Keras for prototyping. Its research mindshare has shrunk, but it is not a legacy product. It is the right call when your team or your infrastructure is already committed to it.
+
+## Classic machine learning
+
+scikit-learn, BSD-3, is not a deep learning tool and does not want to be one. For structured data, tabular problems, regression, classification, clustering, feature engineering, it is still the first thing to reach for and often the last thing you need. A huge share of real business ML is a well-built scikit-learn pipeline, not a neural network.
+
+JAX is the research alternative, Apache 2.0, built around XLA compilation and functional transforms. It dominates the bleeding edge of new model architectures and runs happily on TPUs. Its audience is people doing novel research, and its cost is that the API is less forgiving than PyTorch. Choose it for research ambition, not for shipping a recommendation model.
+
+## The model layer
+
+Hugging Face Transformers, Apache 2.0, is less a framework and more the interface the entire open model ecosystem standardised on. One API, thousands of pretrained models, and the default way to load and fine-tune open weights. Almost every open model ships a Transformers implementation. If you work with open models at all, you will use it.
+
+LangChain, MIT, sits on top of models and chains together retrieval, prompts, tools, and agents for LLM applications. It is the most popular orchestration library and its API churn is a documented problem: examples from last year break this year. Use it where its integrations genuinely save you work, and do not assume the abstractions will survive a major version.
+
+## Running models locally
+
+Ollama, MIT, is the fastest way to run open models on a laptop or a single GPU. It wraps model runtimes like llama.cpp behind a simple CLI and an OpenAI-compatible API, so a 7B model that answers your coding questions is a one-command install. It is not built for high concurrency or careful throughput tuning.
+
+vLLM, Apache 2.0, is that production answer: a high-throughput inference server for LLMs, with continuous batching and PagedAttention, designed to serve many concurrent requests efficiently on GPUs. If you are putting an open model behind an API that real users hit, vLLM is the standard starting point. It wants a proper GPU deployment and its own operational care.
+
+## Open weights versus open source
+
+This is the accuracy point. Model weights like Llama, Qwen, and DeepSeek are released under their own licenses, for example the Llama Community License, which are not OSI-approved open source licenses. They typically restrict commercial use above certain scale, forbid building competing models, or require special terms for big companies. The weights are open in the sense that you can download them. They are not open source in the OSI sense, and calling them that is how companies end up with a surprise legal conversation after launch.
+
+The frameworks and libraries above are genuinely open source under permissive licenses. The models you run on them often are not. [Read the license](/how-open-source-licensing-works) on both before you build a product. The framework choice is a skill decision. The weights choice is a legal one, and it is the one most teams skip.
diff --git a/content/posts/best-open-source-alternatives-to-popular-paid-software.md b/content/posts/best-open-source-alternatives-to-popular-paid-software.md
new file mode 100644
index 0000000..8936078
--- /dev/null
+++ b/content/posts/best-open-source-alternatives-to-popular-paid-software.md
@@ -0,0 +1,38 @@
+---
+title: "Best Open Source Alternatives to Popular Paid Software (Photoshop, Office, Slack, etc.)"
+description: "Working open source replacements for Photoshop, Microsoft Office, Slack, Adobe Premiere, Jira, Zoom, Notion, and SurveyMonkey, with an honest look at what each swap costs you."
+type: article
+category: tools
+tags: [open-source-alternatives, free-software, gimp, libreoffice, mattermost]
+keywords: [open source alternatives to paid software, gimp vs photoshop, libreoffice vs microsoft office, open source slack alternative, kdenlive vs premiere pro]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+There is a working open source replacement for almost every paid tool on your laptop. The hard part is not finding one, it is understanding what the swap costs. An open source tool is rarely a drop-in clone. It usually trades polish, ecosystem, or setup time for price and control. Here is the honest version of the common swaps, with a table for quick comparison.
+
+| Paid tool | Open source alternative | What you give up | What you gain |
+|---|---|---|---|
+| Adobe Photoshop | GIMP, Krita | Adobe's polish, the camera raw pipeline, the huge tutorial ecosystem | No subscription, full control of the source; Krita is genuinely excellent for illustration |
+| Microsoft Office | LibreOffice, OnlyOffice | Pixel-perfect fidelity on complex documents, deep cloud collaboration | Real file format compatibility, no license fees; OnlyOffice self-hosts with collaborative editing |
+| Slack | Mattermost, Rocket.Chat, Zulip | The app store, hosted reliability, mobile polish | Data on your own servers, unlimited message history, Zulip's threaded model |
+| Adobe Premiere | Kdenlive, Shotcut | Some pro finishing features, Premiere's plugin ecosystem | No Creative Cloud fee; DaVinci Resolve is free but proprietary, not open source |
+| Jira | Plane, Leantime | The plugin ecosystem, enterprise reporting | A cleaner UI, no per-user pricing, modern and fast |
+| Zoom | Jitsi Meet, BigBlueButton | Video quality at extreme scale, some host controls | Meetings on your own infrastructure, no time limits, encryption you control |
+| Notion | AppFlowy | Polished sync, a giant template marketplace | Local-first data, offline, no lock-in |
+| SurveyMonkey | Formbricks | Enterprise reports, a huge question library | Self-hosted forms, unlimited responses, data stays under your control |
+
+A few of these swaps deserve more than a row in a table.
+
+Design and media is where expectations go wrong. GIMP carries a reputation for its old interface, but for print and web work it does the job, and recent versions have improved. If you paint or draw, Krita is better than GIMP for illustration and holds its own against paid apps. For video, decide what you actually need. DaVinci Resolve is excellent and free, but it is not open source; the code stays closed and the studio tier is paid. If open source is a hard requirement, Kdenlive and Shotcut cover cutting, color, and export for most creators. What you lose is Resolve's node-based color grading, the reason most people use it.
+
+Office is a matter of tolerance. LibreOffice has been around long enough to read and write docx and xlsx without drama in most cases. OnlyOffice adds a web interface built for teams, and the community edition self-hosts cleanly. Both give up the last few percent of fidelity on complex documents, dense tables, and heavily formatted client deliverables. For internal documents nobody notices. Test on real files before you promise anything to a client.
+
+Chat is where the data argument does the real work. Slack hides message history behind a paywall and keeps your data on its servers. Mattermost is the closest clone, channels, threads, integrations, and it runs fine on a small server. Rocket.Chat is heavier but has a long track record, including in Indian government projects. Zulip organizes everything into topics rather than a scrolling wall, which sounds like a gimmick until your team actually lives in it.
+
+Jira is the swap that surprises people. Plane is fast and modern, closer to Linear in feel than Jira, which makes it popular with small teams that never liked Jira. Leantime is lighter still. What both lack is the ecosystem: thousands of plugins and enterprise reporting. A ten-person startup will rarely miss it; a fifty-person org under a strict audit might.
+
+The rule for switching: if the tool holds your data and you use it daily, migrate carefully and keep a test period. If you open it occasionally, the switch is low risk. And read the license before you commit a workflow to any tool, several "free" products are closed-source freeware rather than open source. My guide to how open source licensing works explains how to tell the difference.
diff --git a/content/posts/best-open-source-analytics-tools.md b/content/posts/best-open-source-analytics-tools.md
new file mode 100644
index 0000000..4037437
--- /dev/null
+++ b/content/posts/best-open-source-analytics-tools.md
@@ -0,0 +1,45 @@
+---
+title: "Best Open Source Analytics Tools"
+description: "Web analytics, product analytics, and BI are different jobs. Matomo, Plausible, Umami, GoAccess, PostHog, Metabase and Apache Superset compared for self-hosting, with a focus on privacy."
+type: article
+category: tools
+tags: [best open source analytics, open source analytics, self hosted analytics, matomo, plausible, posthog, metabase]
+keywords: [best open source analytics tools, self hosted web analytics, matomo vs plausible, open source product analytics, self hosted bi tools]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+The most common analytics mistake is installing the wrong category of tool. Web analytics answers "what pages did people view and where did they come from." Product analytics answers "which users did what, in what order, and how many came back." BI answers "what do the numbers in my database mean." Different questions, different tools, and no single open source project does all three well.
+
+## Web analytics
+
+Matomo is the closest thing to a self-hosted Google Analytics and it is GPLv3. You install it on PHP and MySQL, drop a JavaScript tag on your site, and get the full picture: referrers, goals, e-commerce tracking, even session recording and heatmaps through paid plugins. It is thorough and it is heavy. The database grows, the archiving cron needs to run, and a large site needs a real server. If you want Google Analytics parity on your own hardware, this is the tool.
+
+Plausible is the lightweight alternative, AGPLv3, with a single sub-kilobyte script and a dashboard that fits on one screen. It is cookieless by design, which makes it nearly painless under GDPR and gives you one honest number per page instead of a thousand. It is deliberately not a replacement for GA4's reporting depth, and the self-hosted version lags the paid cloud in convenience. For a marketing site or a personal blog, that tradeoff is usually correct.
+
+Umami sits in between, MIT licensed, Postgres-backed, fast, with a clean dashboard and a little more depth than Plausible without Matomo's weight. It is my default pick for a small team that wants something better than a counter without running a reporting platform.
+
+GoAccess is the odd one out and my favourite for a single server. It is MIT licensed and does not touch your pages at all: it parses nginx or Apache access logs and renders a terminal or HTML report in seconds. Zero JavaScript, zero cookies, zero database. Install it, point it at your log file, and you have real visitor numbers immediately. It is the fastest "install and go" analytics on this list, with the limit that it only knows what your logs record.
+
+## Product analytics
+
+Product analytics is a different animal because it needs identity: events tied to a user, funnels, retention, and sessions that survive a page reload.
+
+PostHog is the serious open source option here, MIT licensed at the core with enterprise components under a separate license. It does event capture, autocapture, funnels, session replay, feature flags, and experiments, all self-hostable. It is genuinely impressive and genuinely hungry: high event volume means real storage and compute, so budget for that before you adopt it. If your SaaS is past the point where "did anyone sign up today" is the whole dashboard, PostHog is the tool.
+
+Matomo also covers the basics of product analytics with its goals and e-commerce tracking, and it is worth saying explicitly that product analytics is not the same as "add the analytics script." It means you have decided which events matter, and you are paying attention to retention and funnel data, not page views.
+
+## BI
+
+Business intelligence queries your data wherever it lives and turns it into dashboards people can actually read.
+
+Metabase is the friendliest BI tool you can self-host, AGPLv3, connecting to Postgres, MySQL, ClickHouse, and a long list of others. Non-technical users can click through questions, and anyone can write SQL. For a small company that wants "our revenue by month, by channel, by region" without hiring a data team, Metabase is usually the answer.
+
+Apache Superset is the heavier option, Apache 2.0, with a SQL lab, rich chart types, and a real modelling layer. It can do more than Metabase and demands more: a proper deployment, more configuration, and more willingness to learn. If your reporting needs outgrow Metabase, Superset is the natural open source upgrade path.
+
+## The privacy angle
+
+The reason to self-host any of these is that your visitor data never leaves your server. That matters under GDPR, under India's DPDP Act as it phases in, and for the simple practical reason that your analytics feed your own product decisions. Log-based tools like GoAccess avoid consent banners entirely, cookieless tools like Plausible nearly so, and a self-hosted Matomo or PostHog keeps raw behaviour data inside your own Postgres. None of it is magic. Pick the category first, then the tool, then host it properly, because an analytics server that goes down quietly is worse than no analytics.
diff --git a/content/posts/best-open-source-chat-communication-apps.md b/content/posts/best-open-source-chat-communication-apps.md
new file mode 100644
index 0000000..9c2400a
--- /dev/null
+++ b/content/posts/best-open-source-chat-communication-apps.md
@@ -0,0 +1,59 @@
+---
+title: "Best Open Source Chat/Communication Apps"
+description: "Open source chat apps compared: Mattermost, Rocket.Chat, Zulip, Element and Matrix, Jitsi Meet, BigBlueButton and Jami, with self-hosting and federation explained."
+type: article
+category: tools
+tags: [open-source, communication, chat, self-hosting, matrix]
+keywords: [best open source chat apps, open source slack alternative, self hosted chat, zulip, mattermost, matrix element]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Every team defaults to Slack or Teams until the first time the admin gets a bill for history limits or the client refuses to put data on a US cloud. Open source chat solves both problems, but the tradeoffs are different from what the marketing pages suggest. Self-hosting means you own the servers and the ops burden. Federation means your server can talk to other servers, which changes how you think about accounts and rooms entirely.
+
+## Mattermost: the Slack clone that grew up
+
+Mattermost gives you Slack-style channels, threads, search, and integrations, plus a long list of admin controls and audit features. The server core is MIT licensed, though newer enterprise features now sit under a source-available license, so check what your planned features cost before committing. It runs well on a small VPS and is the least surprising choice for a team that wants Slack without Slack. The friction: you maintain it, and mobile notifications require a push notification server that runs outside your network.
+
+## Rocket.Chat: full-featured and heavier
+
+Rocket.Chat (MIT) is the other big Slack alternative. It packs in channels, omnichannel customer support, video calls, and a marketplace, which makes it attractive to organizations that want one platform. It is also noticeably heavier than Mattermost and the UI can feel cluttered. Choose it when you need the support-desk features built in. Choose Mattermost when you just want clean team messaging.
+
+## Zulip: the one that changes how you communicate
+
+Zulip (Apache-2.0) is organized around topics, not just channels. Every message in a channel belongs to a topic, so you can read in a logical order instead of scrolling a timeline. For async teams, especially open source communities spread across time zones, this genuinely reduces noise. The desktop and mobile apps are solid, and the self-hosted install is straightforward. The tradeoff is cultural: it works only if the team actually uses topics, and teams that refuse will find it worse than a plain chat.
+
+## Element and Matrix: federation is the whole point
+
+Matrix is a protocol for decentralized real-time communication, and Element is the main client. Your homeserver can talk to other homeservers, so a user on your server can chat with someone on any other Matrix server, the way email works. That makes it the right answer for organizations that want sovereignty without isolation. The real cost is in the details: server components like Synapse need monitoring, end-to-end encryption occasionally confuses shared devices, and bridging to Slack or WhatsApp is more tinkering than out-of-the-box. When federation or encryption really matters, nothing else on this list competes.
+
+## Jitsi Meet: video calls you can host
+
+Jitsi Meet (Apache-2.0) is a browser-based video conferencing server. No install for users, decent quality, and good scalability on a single well-configured server. For a company doing internal calls, it is the most practical open source choice. It trails Zoom on large meetings and participant controls, and echo issues show up on weak connections, something Indian networks make you painfully aware of.
+
+## BigBlueButton: built for classrooms
+
+BigBlueButton (LGPL-3.0) is video conferencing aimed at online teaching: shared whiteboard, breakout rooms, polls, and recording. It powers many universities and edtech companies precisely because those features exist. Outside education, its interface feels dated. Use it when you are running classes or webinars; Jitsi is the better general-purpose call tool.
+
+## Jami: the decentralized private option
+
+Jami (GPL-3.0) is peer-to-peer calling and messaging, with no central server at all. Calls and messages go directly between devices when possible, which is a different threat model than self-hosting a server you control. The cost is reliability: without a server holding messages, delivery depends on devices being online. It is the choice for privacy-first conversations, not for a business communication platform.
+
+## Picking one for your team
+
+The short version:
+
+| App | Best for | License |
+|-----|----------|---------|
+| Mattermost | Slack replacement | MIT (core) |
+| Rocket.Chat | Chat + support desk | MIT |
+| Zulip | Async teams, open source communities | Apache-2.0 |
+| Element / Matrix | Federation and encrypted chat | Apache-2.0 |
+| Jitsi Meet | Self-hosted video calls | Apache-2.0 |
+| BigBlueButton | Online classes, webinars | LGPL-3.0 |
+| Jami | Private peer-to-peer calls | GPL-3.0 |
+
+A team replacing Slack wants Mattermost or Rocket.Chat. A distributed open source project wants Zulip for async work and Matrix for the community to federate. An edtech startup wants BigBlueButton. The one thing every self-hosted option shares is maintenance: you now own updates, backups, and the 2 a.m. outage, so factor that into the decision. Before you move a whole team, understand the [licensing implications](/how-open-source-licensing-works), since AGPL-style obligations differ from permissive ones.
diff --git a/content/posts/best-open-source-cms-platforms.md b/content/posts/best-open-source-cms-platforms.md
new file mode 100644
index 0000000..3e099cf
--- /dev/null
+++ b/content/posts/best-open-source-cms-platforms.md
@@ -0,0 +1,47 @@
+---
+title: "Best Open Source CMS Platforms (WordPress Alternatives)"
+description: "Open source CMS options compared honestly: WordPress, Ghost, Strapi, Directus, Keystone, Umbraco and Drupal. When a traditional CMS still wins, and when headless or static makes more sense."
+type: article
+category: tools
+tags: [best open source cms, open source cms, wordpress alternatives, headless cms, strapi, directus, ghost cms]
+keywords: [best open source cms, wordpress alternatives, headless cms open source, strapi vs directus, self hosted cms]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Most "WordPress alternatives" articles are junk because they compare a blog platform to an e-commerce suite and call the difference a winner. The real question is what job you need done: a marketing site your team edits, a newsletter, an admin UI over your own data, or content piped into an app.
+
+## WordPress (GPL)
+
+WordPress is still the right answer for most brochure sites, blogs, and small business sites. GPLv2 licensed, thirty years of plugins, and a maintenance culture that everyone understands. The costs are the two you stop noticing: plugin bloat that turns a fast site slow, and a security update treadmill that you cannot skip. If the site is your revenue, budget for either managed hosting or someone who patches it monthly. WordPress is bad at exactly one thing: being a clean backend for a custom frontend, which is what the headless options below exist for.
+
+## Ghost (MIT, with a caveat)
+
+Ghost is a Node.js publishing platform focused on newsletters, memberships, and subscriptions. The core is MIT licensed and self-hostable, so it is genuinely open source today. The caveat is historical: for years, flagship features like memberships shipped in the paid product first and only reached the open source codebase later, so a lot of people rightfully called it source available rather than open source. The model is now more transparent, with some newer features like web analytics shipped as separate open source services, but the company still funds itself through Ghost(Pro) hosting. If you want a fast blog with built-in newsletters, Ghost is excellent. Just know the exact feature set of the self-hosted build before you assume parity.
+
+## Strapi (MIT)
+
+Strapi is a headless CMS: you define content types in an admin panel, content teams write, and your frontend pulls everything over REST or GraphQL. MIT licensed. It is the default answer for teams that want an admin for non-developers plus a React or Next.js frontend they control. The tradeoffs: you build the entire frontend yourself, and the plugin marketplace is uneven. A content type with three fields and an image is trivial. Anything with complex workflows is a development project.
+
+## Directus (source available, converts to GPLv3)
+
+Directus turns an existing SQL database into a content platform and API, so your content lives in Postgres or MySQL and the admin is a layer on top. The license is the part you must read. Directus started GPL, went Business Source License, and with v12 moved to MSCL, a source-available license that is free under $5M revenue and 50 employees, restricts building a competing product, and converts each version to GPLv3 after four years. That is a workable deal for most companies, but it is not MIT, and the enforcement model changed between versions. [Know your license](/how-open-source-licensing-works) before you standardise a product on it.
+
+## Keystone (MIT)
+
+Keystone is a schema-first headless CMS for TypeScript developers. You define your lists in code, it generates the database schema, an admin UI, and GraphQL/REST APIs, and it uses Prisma underneath. MIT licensed, maintained by Thinkmill. It suits product teams who want content stored with their app's code and dislike pointing and clicking a CMS into existence. The cost is that content editors get whatever admin UI the schema implies, and customising it takes real work.
+
+## Umbraco (MIT)
+
+Umbraco is the .NET entry, MIT licensed, with twenty years of history and a big agency ecosystem in Europe. It is a traditional coupled CMS with strong editorial tools, media handling, and a reputation for being flexible without being scary. If your team is already on .NET, it is the least foreign CMS you will find. Outside the .NET world it rarely gets considered, which is its real limitation.
+
+## Drupal (GPL)
+
+Drupal is the most powerful and most demanding option here. GPLv2+, famously capable of modelling complex content relationships, permissions, and multilingual sites, and famously a project where a developer can spend months learning the mental model. It is the right choice for large institutional sites where structure and governance matter more than shipping speed, and rarely the right choice for a startup.
+
+## When WordPress is still fine
+
+Keep WordPress for a marketing site or blog where non-developers need to edit pages and you can afford routine maintenance. Go headless, Strapi or Keystone or Directus, when your content feeds a custom frontend or an app and you have a development team anyway. And if nobody needs to log in and edit, skip the CMS entirely and use a static site with markdown files. That is a genuinely underrated option that saves you the maintenance entirely, and you can track the projects behind it on ossium. Choosing the wrong category costs far more than choosing the wrong tool inside a category.
diff --git a/content/posts/best-open-source-crm-software.md b/content/posts/best-open-source-crm-software.md
new file mode 100644
index 0000000..da9ecfa
--- /dev/null
+++ b/content/posts/best-open-source-crm-software.md
@@ -0,0 +1,53 @@
+---
+title: "Best Open Source CRM Software"
+description: "A practical comparison of open source CRM options: Odoo, ERPNext, EspoCRM, SuiteCRM, Twenty and Mautic. What each costs in effort, when to self-host, and where they fall short of Salesforce and HubSpot."
+type: article
+category: tools
+tags: [best open source crm, open source crm, crm software, odoo, erpnext, twenty crm]
+keywords: [best open source crm, open source crm software, erpnext vs odoo, self hosted crm, free crm software]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Every CRM vendor bills per user per month, and the bill climbs fast. A twenty seat sales team at $25 a seat is over $6,000 a year before add-ons. That is why open source CRM keeps getting evaluated, and it is also why most evaluations stop at the download. The software is free. The operating cost is not.
+
+## Odoo Community
+
+Odoo is an ERP with a CRM module, which is its biggest strength and its biggest trap. The CRM itself is fine, but the reason people pick Odoo is that a lead can flow into a quote, an order, invoicing, and inventory without any middleware. If you run a product business, that pipeline is genuinely useful.
+
+The Community edition is LGPL and free. The catch is that you will be fighting the framework. Odoo models, records, and views follow their own conventions, and the moment you need behaviour the studio does not expose, you are writing Odoo code, not the Python you already know. Most small teams get better value paying Odoo or a partner for hosted support than self-hosting and learning the framework alone.
+
+## ERPNext
+
+ERPNext is the other full ERP on this list, built on the Frappe framework and driven by Frappe Technologies, an Indian company. If your business touches GST, Indian accounting, HR, or manufacturing, ERPNext has those modules and they are localised properly, which is rare in open source. It is GPLv3 licensed.
+
+Who it suits: SMBs that will adopt the whole system, not just the CRM. Who it does not suit: anyone who wants a thin sales tracker. ERPNext is opinionated. Everything lives in one Frappe app and deviating from its model takes real effort. For a Mumbai services firm that wants one system for leads, invoices, and payroll, ERPNext is the most complete answer on this list.
+
+## EspoCRM
+
+EspoCRM is a lightweight PHP CRM that does sales, marketing, and customer service without pretending to be an ERP. It is AGPLv3 licensed. Setup is genuinely easy, MySQL plus PHP, and it stays fast on modest hardware. The tradeoff is a small ecosystem: fewer extensions, fewer integrations, and a community small enough that you sometimes answer your own questions. If your need is tracking leads and emails for a ten person team, it is hard to beat on effort versus payoff.
+
+## SuiteCRM
+
+SuiteCRM is the community fork of SugarCRM and carries that history with it. It is AGPLv3. It covers sales, marketing, and service, and it has the integrations and add-on market that more than a decade of development brings. It also has the UI to show for it. The interface feels dated, and the codebase is heavy enough that a sloppy self-host becomes a security chore. SuiteCRM suits organisations that need its breadth and have someone willing to keep it patched.
+
+## Twenty
+
+Twenty is the youngest project here, AGPLv3, a modern TypeScript CRM that looks and behaves a lot like a self-hosted Salesforce or HubSpot. It is API-first, with custom objects and a workflow editor. It is the most pleasant CRM to use on this list and the least proven: fewer integrations, less battle testing, and a roadmap that can still shift. For a startup that wants a modern CRM from day one and can tolerate early-adopter roughness, it is worth a serious look.
+
+## Mautic
+
+Mautic is not a CRM. It is marketing automation, GPLv2 licensed: email campaigns, lead scoring, and nurturing sequences that plug into a CRM. Teams that expect Mautic to replace Salesforce get confused, because it answers a different question. The practical pairing is Mautic for campaigns plus one of the CRMs above for pipeline, and that pairing is a real integration project, not a weekend.
+
+## Self-host or pay
+
+Do the math on who does the work. Self-hosting a CRM on a small Indian VPS costs a few hundred rupees a month in compute. The real cost is upgrades, backups, SSL, and patching. If you have an engineer who can own that, self-hosting is cheaper per user than any SaaS. If you do not, the subscription you avoided comes back as your own salary in troubleshooting time. ERPNext has a first-party hosting option for exactly this reason, and Odoo does too. Neither is "free", but both are cheaper than hiring someone to run the stack.
+
+## Where open source CRM falls short
+
+Open source CRM is perfectly good at pipeline management. It is weak where Salesforce and HubSpot are strong: the app marketplaces, the Gmail and LinkedIn integrations, the AI scoring, and the guarantee that a change works tomorrow. Those come from thousands of paying customers and a roadmap you can hold someone to. With open source, the roadmap is a GitHub repo and the support team is often just you.
+
+Read [how open source licensing works](/how-open-source-licensing-works) before you build on an AGPL license, since running it as a service has obligations that permissive licenses do not have.
diff --git a/content/posts/best-open-source-database-systems.md b/content/posts/best-open-source-database-systems.md
new file mode 100644
index 0000000..522f792
--- /dev/null
+++ b/content/posts/best-open-source-database-systems.md
@@ -0,0 +1,56 @@
+---
+title: "Best Open Source Database Systems"
+description: "Open source databases grouped by use case: PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis and Valkey, ClickHouse, DuckDB and Neo4j, with accurate license notes including SSPL."
+type: article
+category: tools
+tags: [best open source databases, open source database, postgresql, sqlite, clickhouse, duckdb, redis valkey]
+keywords: [best open source databases, postgresql vs mysql, open source nosql, clickhouse vs duckdb, redis license valkey]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+People choose databases like they choose religions, so let me skip the theology and group them by job. Transactional databases handle your core reads and writes. Analytical databases answer big questions over lots of rows. Embedded databases live inside your app. Caches and search are their own categories. Pick the job first, then argue about the tool.
+
+| Database | Best for | License |
+|---|---|---|
+| PostgreSQL | Default transactional database | PostgreSQL License |
+| MySQL / MariaDB | Legacy teams, managed providers | GPLv2 |
+| SQLite | Local, embedded, single-file storage | Public domain |
+| MongoDB | Flexible documents, JSON-shaped data | SSPL 1.0 |
+| Redis / Valkey | Cache, queues, counters | BSD / RSAL-SSPL |
+| ClickHouse | Columnar analytics at scale | Apache 2.0 |
+| DuckDB | Analytics inside your app | MIT |
+| Neo4j | Graphs and relationships | GPLv3 |
+
+## Transactional
+
+PostgreSQL is the boring, correct choice for most new projects. The PostgreSQL license is permissive, the feature set is enormous, JSONB covers most "noSQL" needs, and full-text search handles basic search queries. It will not be the fastest at any one thing, and it will be the least wrong at everything. If you have no strong reason otherwise, start here.
+
+MySQL and MariaDB are the same family. MySQL is GPLv2 under Oracle, available with commercial licensing, and everywhere in managed hosting. MariaDB is the community fork, also GPLv2, and a drop-in replacement that kept the original developers. The honest difference for most teams is ecosystem and providers, not features. Choose MariaDB for community momentum or MySQL when your cloud provider makes it the path of least resistance.
+
+MongoDB is the document store, and its license is the thing to remember. It is SSPL 1.0, which is not OSI-approved open source: you can read and modify the code, but offering MongoDB as a managed service under SSPL has serious source-sharing obligations, which is why every cloud provider runs its own fork or compatible engine. Use it when JSON-shaped, schema-flexible documents are genuinely the right model. It is not a database you should default to.
+
+## Cache and key-value
+
+Redis was the canonical answer until the licensing change: 7.2 and earlier are BSD-3, the 7.4 Community Edition moved to RSALv2/SSPLv1, and Redis 8 added AGPLv3 as a third option. The practical consequence is that Valkey, the Linux Foundation fork under BSD-3, is now the safe open source choice for cache, queues, and counters, and most cloud providers back it. If you need the latest Redis features, read the [license terms](/how-open-source-licensing-works) carefully. For plain caching, Valkey is the sane default.
+
+## Analytical
+
+ClickHouse is the heavyweight analytical engine, Apache 2.0, built for columnar queries over billions of rows. It shines for event data, observability, and any "select over everything we have ever logged" workload, and it is the common backend for self-hosted analytics. It wants real servers and real RAM.
+
+DuckDB is the embedded analytical answer, MIT licensed, a columnar database that runs inside your process and can query Parquet and CSV files directly. For an analyst, a script, or an app that needs local analytical speed, it replaces a whole data stack. It is not designed for many concurrent users writing to it, so treat it as a powerful engine, not a server.
+
+## Embedded
+
+SQLite is in the public domain, which settles most license questions, and it is the most widely deployed database on earth by a wide margin. For local data, desktop apps, edge devices, and anything that fits in one file, it is the correct answer and nothing else comes close. Its limits, no distributed writes, one writer at a time, are well understood and rarely the actual bottleneck.
+
+## Graph
+
+Neo4j community edition is GPLv3, which matters because the product is under commercial licensing for production and enterprise use. Its real strength is relationship-heavy queries, fraud networks, knowledge graphs, recommendations, that a SQL join pyramid handles painfully. For anything where the graph is the point, nothing else on this list works as well. For everything else, PostgreSQL with a few recursive CTEs gets you further than you expect.
+
+## Search
+
+Full-text search deserves its own line. PostgreSQL's built-in FTS and the trigram indexes handle small to medium search workloads with zero extra infrastructure. When you outgrow that, look at dedicated engines, and read their licenses too: Elasticsearch moved to SSPL, while OpenSearch and Meilisearch remain permissively licensed alternatives. The pattern across this list is consistent. The database is rarely the real bottleneck, but the license is a decision you make once and live with for a decade.
diff --git a/content/posts/best-open-source-design-tools.md b/content/posts/best-open-source-design-tools.md
new file mode 100644
index 0000000..acc9d87
--- /dev/null
+++ b/content/posts/best-open-source-design-tools.md
@@ -0,0 +1,47 @@
+---
+title: "Best Open Source Design Tools"
+description: "Open source design tools that actually work: GIMP, Krita, Inkscape, Penpot, Blender, Excalidraw and tldraw, with honest tradeoffs for each."
+type: article
+category: tools
+tags: [open-source, design, gimp, inkscape, penpot, blender]
+keywords: [best open source design tools, open source design software, gimp alternatives, open source figma alternative, free vector graphics software]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Most people in India start design work on a budget laptop and end up reaching for a cracked copy of Photoshop. Before you go down that road, know that the open source stack now covers almost every serious design job, from photo retouching to UI mockups to 3D models. The catch is that none of these tools drop in like Adobe. Each has a learning curve and a specific thing it does badly, and knowing those limits matters more than knowing the menus.
+
+## GIMP: the raster editor that never quite matched Photoshop
+
+GIMP (GPL) has been the free answer to Photoshop for two decades. It handles photo retouching, compositing, and batch editing fine, and it gets fast once you stop expecting Adobe's keyboard layout. What annoys people: the interface still feels dated, CMYK support is weak, and plugin quality varies wildly. If you do simple edits, poster work, or web images, it is free and it works. If you do color-managed print work, you will fight it. For real photo work, most people end up choosing between GIMP and Krita.
+
+## Krita: painting, not photo editing
+
+Krita (GPL) is built for digital painting and illustration. The brush engine is genuinely good, stroke stabilization is there, and it runs decently on 8GB laptops, which matters more in India than in the US where everyone assumes 32GB. It is a poor choice for photo manipulation, so do not force it into that role. If you paint thumbnails, do concept art, or draw UI sketches, Krita is the single best free tool for it.
+
+## Inkscape: vector graphics without the subscription
+
+Inkscape (GPL) covers SVG editing, logos, icons, and technical diagrams. If you are coming from Illustrator, the transition is annoying because the tool model differs, but the output is standard SVG that works everywhere, including in print workflows and laser cutting files. Large files with hundreds of nodes will slow it down, and there is no real native app feel on mobile, so plan for desktop-only work.
+
+## Penpot: the closest open source Figma
+
+Penpot (MPL-2.0) is a browser-based UI/UX design tool and the most credible open source alternative to Figma. You can self-host it, which matters for teams in regulated industries or for agencies that do not want client work sitting on a US cloud. Collaboration is real: multiple people work in the same file, and developers can inspect and export CSS, SVG, or PNG directly. It trails Figma in polish and plugin depth, but for wireframes, component libraries, and handoff it is genuinely usable. A solo developer mocking up a side project will not miss much.
+
+## Blender: 3D, and a lot more
+
+Blender (GPL) is the one open source design tool with no credible paid equivalent at its level. Modeling, sculpting, animation, rendering, even video editing and compositing all live inside it. The cost is the learning curve and the hardware. A dedicated GPU with 8GB of VRAM makes life dramatically easier; on integrated graphics, basic modeling works but renders crawl. For product mockups, motion graphics, or game assets, the months of frustration are worth it.
+
+## Excalidraw and tldraw: whiteboards that stay out of your way
+
+For diagrams, brainstorming, and architecture sketches, Excalidraw (MIT) and tldraw (MIT) beat every heavyweight tool. Excalidraw's hand-drawn look is now a style people copy deliberately, and both run in the browser with real-time collaboration and self-hosting options. tldraw is more of a platform, with embeddable components and an open SDK, so you can build whiteboard features into your own app. Neither is a design tool in the Photoshop sense. Both are the tools I actually open most days.
+
+## Photopea: free, but not open source
+
+Photopea runs in the browser, opens PSD files, and is free with ads. It is also closed source, so it does not belong on a list of open source tools. Keep it bookmarked for the day a client sends a PSD and you just want to export it once.
+
+## Picking one to learn first
+
+If you only learn one, pick based on the job: Inkscape for logos and icons, Penpot for UI work, Krita if you paint, GIMP if you edit photos, Blender for anything 3D. The software is free; your time is not, so learn one properly instead of collecting five. If you plan to bundle or redistribute any of these in a product, [check how open source licensing works](/how-open-source-licensing-works) first, because the GPL, MPL, and MIT each place different obligations on you.
diff --git a/content/posts/best-open-source-devops-ci-cd-tools.md b/content/posts/best-open-source-devops-ci-cd-tools.md
new file mode 100644
index 0000000..b72a0d6
--- /dev/null
+++ b/content/posts/best-open-source-devops-ci-cd-tools.md
@@ -0,0 +1,67 @@
+---
+title: "Best Open Source DevOps & CI/CD Tools"
+description: "Open source DevOps and CI/CD tools that teams actually self-host: GitLab, Jenkins, Woodpecker, Gitea, Ansible, Argo CD, Prometheus and Grafana, with accurate licensing."
+type: article
+category: tools
+tags: [open-source, devops, ci-cd, kubernetes, self-hosting]
+keywords: [best open source devops tools, open source ci cd tools, self hosted ci cd, gitlab ce, woodpecker ci, terraform license]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Most Indian startups run builds on whatever CI the git hosting platform gives them. That works until the queue grows or the bill does. When you outgrow that, the open source layer of the DevOps stack is surprisingly complete: self-hosted git hosting, runners, config management, and observability all have solid options. The caveat is that the licensing landscape shifted in the last few years, so a tool that used to be MIT might now be source-available or AGPL.
+
+## GitLab CE: the all-in-one self-hosted platform
+
+GitLab Community Edition (MIT) is the most complete self-hosted package: git hosting, MRs, built-in CI, container registry, and dashboards in one install. The reason teams choose it is that the CI runs on your own runners, so build minutes stop being a metered cost. The tradeoff: it is heavy. A small instance needs 8GB of RAM to feel comfortable, and upgrades between major versions can be tedious. GitLab also stopped releasing some new features under the CE license, so the product has an open core shape now.
+
+## Jenkins: old, ugly, and everywhere
+
+Jenkins (MIT) has been around for twenty years and it shows. The UI is dated, and configuration often ends up as a pile of plugins and Groovy scripts that nobody fully understands. But it is still the most flexible automation engine that exists, and almost every legacy build system in a bank or a large enterprise runs on it. If your job expects Jenkins, learn it even if you would rather not run it yourself.
+
+## GitHub Actions: great, but not self-hosted open source
+
+GitHub Actions is free on the hosted tier for public repos and small private ones, and it is genuinely good. It is also not open source in the same way the other tools here are: the engine runs on GitHub's infrastructure, and while the workflow YAML is open, the product is proprietary. Fine to use, but you do not own the pipeline. If you want the same feel with ownership, look at Gitea or Forgejo with their native Actions support.
+
+## Gitea and Forgejo: git hosting plus CI in one binary
+
+Gitea (MIT) and its fork Forgejo (MIT) are lightweight, self-hosted git servers that run in a single binary with a small footprint. Both now support GitHub Actions-compatible workflows, so you can get a decent CI without standing up a separate runner cluster. A 2GB VPS handles a small team comfortably. This is usually where self-hosters land between GitLab's weight and plain GitHub.
+
+## Drone and Woodpecker CI: container-native pipelines
+
+Drone (Apache-2.0) builds each step as a Docker container, which keeps pipelines clean and cacheable. It was the go-to for years, but development slowed after Harness took over, and the community forked it into Woodpecker CI (Apache-2.0). For simple YAML pipelines where every step is a container, either works; Woodpecker has the momentum now and an easy migration path from Drone.
+
+## Ansible: config management without agents
+
+Ansible (GPL-3.0) manages servers over SSH without installing agents, which makes it the fastest way to script a homelab or a production fleet. Playbooks are YAML, so the barrier is low, but that same simplicity bites you: complex Ansible setups get slow and hard to debug, and there is no built-in state tracking beyond what you write. For reproducible deploys across a handful of servers it remains the pragmatic default.
+
+## Terraform, and why OpenTofu exists
+
+Terraform (MPL-2.0) is still the most common infrastructure-as-code tool. HashiCorp switched it to the Business Source License (BSL) in 2023, which forbids competing with their paid offering, so Terraform is now source-available rather than open source. The community forked it into OpenTofu (MPL-2.0), which tracks the same providers. If you are starting fresh and open source purity matters, start with OpenTofu; if you already run Terraform, the practical difference for daily use is small.
+
+## Argo CD: GitOps for Kubernetes
+
+Argo CD (Apache-2.0) is the standard GitOps controller: your cluster state lives in git, and Argo keeps the cluster in sync with it. Rollbacks become reverting a commit, which is a real quality-of-life improvement. It is only worth the complexity if you actually run Kubernetes. On a plain VM stack, it solves a problem you do not have.
+
+## Prometheus and Grafana: the observability baseline
+
+Prometheus (Apache-2.0) scrapes metrics and stores them with a powerful query language, and Grafana (AGPL-3.0, since its move from Apache in 2021) turns them into dashboards. Together they are the de facto open source monitoring stack. The cost is maintenance: storage grows, rules accumulate, and dashboards drift. Grafana's AGPL license also means you should treat it like a real dependency, because what you ship alongside it matters.
+
+| Tool | Category | License |
+|------|----------|---------|
+| GitLab CE | Git hosting + CI | MIT (core) |
+| Jenkins | Automation / CI | MIT |
+| GitHub Actions | Hosted CI | Proprietary (hosted) |
+| Gitea / Forgejo | Git hosting + CI | MIT |
+| Drone / Woodpecker | Container CI | Apache-2.0 |
+| Ansible | Config management | GPL-3.0 |
+| Terraform | IaC | BUSL (source-available) |
+| OpenTofu | IaC | MPL-2.0 |
+| Argo CD | GitOps | Apache-2.0 |
+| Prometheus | Metrics | Apache-2.0 |
+| Grafana | Dashboards | AGPL-3.0 |
+
+Pick the stack that matches your scale: Gitea plus Woodpecker for a small team, GitLab CE when you want one box for everything, Argo CD once Kubernetes is real. And before you standardize on any of these, the [guide to open source licensing](/how-open-source-licensing-works) explains what each license actually allows you to do with the code.
diff --git a/content/posts/best-open-source-directories-and-curated-lists.md b/content/posts/best-open-source-directories-and-curated-lists.md
new file mode 100644
index 0000000..3b636a1
--- /dev/null
+++ b/content/posts/best-open-source-directories-and-curated-lists.md
@@ -0,0 +1,29 @@
+---
+title: "Best Open Source Directories and Curated Lists You Should Bookmark"
+description: "The best open source directories and curated lists to bookmark: awesome lists, Free Software Directory, LibHunt, awesome-selfhosted, Open Source Alternatives, and ossium's own directory."
+type: article
+category: tools
+tags: [open-source, directories, curated-lists, awesome-selfhosted, tools]
+keywords: [open source directories, curated open source lists, awesome lists, awesome-selfhosted, best open source websites]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+The directories you bookmark say more about your workflow than any productivity app. Open source discovery is fragmented, and each directory is built for one kind of question. Get the right one for your question and you save hours. Here are the ones that have earned a place in my bookmarks, and when each is the right stop.
+
+**Awesome lists.** The family of awesome-* repositories on GitHub is the single most dependable curated source in open source. Communities maintain one list per topic, and the good ones are ruthless about dropping dead projects. The catch is consistency. Some lists are meticulously maintained, others are one person's browser bookmarks from 2019. Check the last commit date on the list itself before you trust it. Use when: you want a human-curated shortlist for a category.
+
+**awesome-selfhosted.** A special case worth its own line, because it answers the question most people actually have: is there a self-hosted alternative to this tool? It covers everything from note taking to monitoring, organized by category, and it is one of the most actively maintained lists in the ecosystem. Use when: the constraint is "runs on my own server."
+
+**Free Software Directory.** The FSF's database of packages that respect user freedom, with an explicit bias toward copyleft and a strict "no proprietary dependencies" stance. Use when: the license is a hard requirement and you want software that is clean by that standard. Do not use when you need a current popularity ranking, the data is thorough but not trendy.
+
+**LibHunt.** Ranks open source libraries by GitHub stars, grouped by topic, with alternatives and comparisons. Its "best X libraries" style lists are a fine way to get oriented, and its trending pages capture what is moving. The ranking is just star math, so treat it as a map of popularity, not quality. Use when: you need a baseline list of candidates for a category.
+
+**Open Source Alternatives.** An index of open source substitutes for popular commercial software, from Slack alternatives to Photoshop alternatives. Its value is breadth across product categories rather than depth. Use when: you know the commercial tool you want to escape and need a starting candidate list.
+
+**ossium.** This is a directory of a different kind. It does not just list projects, it tracks trending repos and lets you filter by programming language and license before you open a single repository page. That changes the flow. In a plain directory you scroll and click. On ossium you set your filters, compare candidates side by side, and track the ones you are considering. Use when: you have criteria, stack, license, self-hosted, maintained, and you want the list narrowed before the browsing starts. If you are starting from zero, the [beginner discovery guide](/how-to-find-open-source-projects-for-beginners) walks through the whole workflow.
+
+The rule of thumb: curated lists for learning a category, license-driven directories when the license is the point, star-based rankings for a first candidate list, and a filterable tracker like ossium when you are actually choosing between candidates. They are not competitors. They are four stops in the same search.
diff --git a/content/posts/best-open-source-ecommerce-platforms.md b/content/posts/best-open-source-ecommerce-platforms.md
new file mode 100644
index 0000000..251c93e
--- /dev/null
+++ b/content/posts/best-open-source-ecommerce-platforms.md
@@ -0,0 +1,51 @@
+---
+title: "Best Open Source E-commerce Platforms"
+description: "WooCommerce, Medusa, Saleor, Sylius, PrestaShop, Bagisto and Magento Open Source compared for real storefronts, with honest notes on payment gateways, hosting, and maintenance costs in India."
+type: article
+category: tools
+tags: [best open source ecommerce platforms, open source ecommerce, woocommerce, medusa, saleor, magento open source]
+keywords: [best open source ecommerce platform, open source ecommerce india, woocommerce vs medusa, self hosted ecommerce, magento open source vs woo]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+E-commerce is where open source is least "free." The software costs nothing, and then you pay for hosting, a payment gateway, someone to maintain it, and your own time keeping the checkout working. Before comparing tools, accept that the ongoing costs are the product. The platform just decides how big those costs are.
+
+## WooCommerce (GPL)
+
+WooCommerce is a plugin on WordPress, GPLv2, and it is the fastest path from zero to a working store that most teams will find. Themes and plugins cover every need, thousands of developers can maintain it, and a small store on good shared hosting plus a Razorpay or Cashfree plugin is live in a day. The cost is the long tail: plugin conflicts, performance decay, and a security patch routine that is non-negotiable on a store that handles payments. It suits the shop owner, less the engineering team.
+
+## Medusa (MIT)
+
+Medusa is a headless commerce platform, MIT licensed, built in Node and TypeScript with an API-first design and a storefront you build yourself. Its strength is that the checkout, cart, inventory, and order logic are cleanly separated from the frontend, so you can ship a custom storefront on any stack. The cost is that there is no ready storefront to switch on. You are hiring for it. Medusa suits a team that already builds web apps and wants commerce as a service layer rather than a turnkey site.
+
+## Saleor (BSD-3)
+
+Saleor is the GraphQL-first commerce platform, BSD-3-Clause, built on Python and Django. Its schema-first approach is its identity: the entire commerce API is generated from a GraphQL schema, which is powerful and exacting. For teams that want full control over the frontend and like GraphQL, it is the cleanest codebase in this list. The cost is the same as Medusa: you build the storefront, you own the operations, and Saleor's own hosted platform is where the polished parts live. A solo shopkeeper should not start here.
+
+## Sylius (MIT)
+
+Sylius is a Symfony-based commerce framework for PHP, MIT licensed, aimed at developers building custom, mid-size commerce platforms. It has a solid admin, a strong plugin system, and a long history behind agencies that use it for client work. It is not a download-and-configure store. It is a foundation you extend, and the extension work is real engineering. Sylius makes sense when you are building a bespoke store with specific catalogue, pricing, or multi-vendor requirements, and you have PHP developers available.
+
+## PrestaShop (OSL 3.0)
+
+PrestaShop is the PHP store platform that is huge in Europe and rare in India, licensed under OSL 3.0. It is more of a finished store than the frameworks above: themes, modules, a decent admin, multi-currency and multi-language support out of the box. The tradeoffs are the same as WooCommerce with a smaller ecosystem: module quality varies, and the community is lighter in Asia. It is a fine choice if your audience and integrations are European.
+
+## Bagisto (MIT)
+
+Bagisto is a Laravel-based commerce platform built by Webkul, an Indian company, MIT licensed. That provenance matters in practice: it is the platform here with the most familiar learning path for Indian PHP and Laravel developers, with local payment gateways and tax configuration well documented. It is more finished than Sylius and less turnkey than WooCommerce. For an Indian team that wants Laravel rather than WordPress, and wants the core commerce features already built, Bagisto is the honest recommendation.
+
+## Magento Open Source (OSL 3.0)
+
+Magento Open Source is the free layer of Adobe Commerce, licensed under OSL 3.0, and it is the most powerful and most demanding platform here. It handles huge catalogues, multi-store, complex pricing, and enterprise workflows, and it punishes you for the privilege: a real deployment needs serious hosting, Redis and Elasticsearch or OpenSearch in front, and a developer who knows the platform. Adobe's investment goes into the commercial product, so community updates are slower and the support burden is yours. Choose it only when your requirements are genuinely enterprise scale, and budget accordingly.
+
+## An Indian example
+
+Take a small D2C brand in Jaipur selling home decor, a few hundred orders a month, one founder and a designer. The correct answer is almost always WooCommerce or Bagisto with Razorpay or Cashfree. The founder gets a working store in a week, UPI and cards work through the gateway plugin, and the maintenance bill is a few thousand rupees a month in hosting plus a developer on retainer for updates. The same brand with a two person engineering team, and a subscription model plus a custom app planned for next year, should be looking at Medusa or Saleor instead, because the storefront is the app and the commerce engine is the boring part they want under control.
+
+## The real costs
+
+Payment gateways are where the money leaves: Razorpay, Cashfree, PayU, and Instamojo all charge per transaction, and integration is a plugin on WooCommerce and a project everywhere else. Hosting is cheap until it is not, a flash sale is the fastest way to learn this. Maintenance is the number everyone skips, platform updates, security patches, and gateway API changes add up to a standing monthly bill in developer time. Open source e-commerce saves you the licence fee and makes you the product owner. That is a good trade only if you are prepared to be one.
diff --git a/content/posts/best-open-source-note-taking-apps.md b/content/posts/best-open-source-note-taking-apps.md
new file mode 100644
index 0000000..1a326e0
--- /dev/null
+++ b/content/posts/best-open-source-note-taking-apps.md
@@ -0,0 +1,47 @@
+---
+title: "Best Open Source Note-Taking Apps"
+description: "Open source note-taking apps compared: Joplin, Standard Notes, SiYuan, AppFlowy, Logseq and Trilium, covering markdown files, sync, and mobile support."
+type: article
+category: tools
+tags: [open-source, note-taking, productivity, markdown, knowledge-management]
+keywords: [best open source note taking apps, joplin, logseq, standard notes, open source notes app, markdown notes]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+The first question is not which notes app, it is whether your notes are plain files or rows in a database. That single choice decides sync, portability, and how locked in you are. Most people do not think about it until the day they want to leave the app. The open source options below split cleanly along that line, and knowing which side you belong on saves months of switching later.
+
+## Obsidian: the elephant, correctly labeled
+
+Obsidian is the most popular notes app among developers, and its local markdown files are a big part of that appeal. It is also proprietary: free for personal use, but closed source, so it does not belong on a list of open source tools. If you want that exact feel with source you can audit, Logseq and the markdown-based options are the open source path. If you just want the app and do not care about the license, Obsidian is fine. Just do not call it open source, its own site does not either.
+
+## Joplin: the safe default
+
+Joplin (AGPL-3.0) is a plain-markdown note app with solid end-to-end encrypted sync and, critically, real mobile apps for Android and iOS. Notes live in local markdown folders, so even your export is just files. Sync works with your own Nextcloud, WebDAV, or S3, which means no company cloud is required. It is not flashy: no graph views or block magic. What it gives you is a note system that will still work in ten years. For most people this is the correct first choice.
+
+## Standard Notes: encryption as the feature
+
+Standard Notes (AGPL-3.0) is built around end-to-end encryption, with sync to their servers or your own self-hosted server. Every note is encrypted before it leaves the device. The price of that model: core editing is plain text, and advanced features like markdown preview, editors, and themes sit behind a paid subscription, which is a common complaint. Use it when your notes genuinely need to stay private, for credentials-adjacent material or sensitive work. Use Joplin when you want features without a paywall.
+
+## SiYuan: blocks with markdown underneath
+
+SiYuan (AGPL-3.0) is a block-based knowledge base, similar in spirit to Notion and Obsidian's newer features. Content is organized into blocks, you can link and embed them, and there is a built-in graph view. The interesting part: SiYuan stores content as markdown files even though the editing model is block-based, so you are not locked into a proprietary database. It is Chinese-developed, well maintained, and the community is active. The UI is dense, and exporting to plain markdown loses some block structure, but for a self-hosted personal knowledge base it is genuinely capable.
+
+## AppFlowy: Notion's open source cousin
+
+AppFlowy (AGPL-3.0) is a local-first Notion alternative built in Rust and Flutter. Databases, boards, and rich documents work well, and the mobile apps are decent. The tradeoff is the same as with Notion: it stores data in its own database format rather than plain files, so your notes are less portable than markdown. If your workflow depends on databases and structured pages, AppFlowy covers it. If you live in markdown, Joplin or SiYuan is lighter.
+
+## Logseq: outlines, graphs, and AGPL
+
+Logseq (AGPL-3.0) is an outliner with bidirectional links and a graph view, built for the knowledge-management crowd. Notes are markdown files on disk, which is the good part. The aggravating part is that the app shifted its sync features behind a paid service and the project moved away from a strict open source model on parts of the product, which annoys people who picked it for the license. For daily journaling and linked thinking it is excellent. For plain notes with reliable sync, Joplin annoys less.
+
+## Trilium: powerful, and the original is in limbo
+
+Trilium (AGPL-3.0) is a hierarchical note app with a rich editor, inline images, and powerful note relationships. The original open source project remains AGPL, but the author has moved forward development to a closed-source successor called Trilium Next. That split makes the open source version a maintenance question mark, so adopt it knowing the project's direction changed. For a personal wiki with heavy structure it was one of the best; just weigh the uncertainty.
+
+## How to pick
+
+If you want files you own and sync you control, Joplin is the safe call and SiYuan if you want block editing. If privacy is the whole point, Standard Notes. If you think in outlines and graphs, Logseq. If you need Notion-style databases locally, AppFlowy. And if you plan to self-host any of these alongside other services, [the tools worth trying in 2026](/10-open-source-tools-worth-trying-in-2026) is a useful next read.
diff --git a/content/posts/best-open-source-project-management-tools.md b/content/posts/best-open-source-project-management-tools.md
new file mode 100644
index 0000000..043d981
--- /dev/null
+++ b/content/posts/best-open-source-project-management-tools.md
@@ -0,0 +1,57 @@
+---
+title: "Best Open Source Project Management Tools"
+description: "A comparison of self-hosted project management tools: Plane, Focalboard, Leantime, Taiga, Wekan, Vikunja and OpenProject. Strengths, tradeoffs, licenses, and a difficulty table."
+type: article
+category: tools
+tags: [best open source project management, open source project management, plane, taiga, vikunja, openproject]
+keywords: [best open source project management tools, self hosted project management, plane vs taiga, vikunja vs wekan, open source kanban]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Project management is where "open source is free" collides with "your time is not." The tools below all run fine for a small team, but difficulty scales with features. A kanban board is a weekend deploy. A full portfolio and budgeting tool is a running responsibility.
+
+| Tool | Best for | Self-host difficulty |
+|---|---|---|
+| Plane | Modern product teams, Linear style | Medium |
+| Focalboard | Personal and small-team kanban | Easy |
+| Leantime | Teams that hate PM tools | Easy |
+| Taiga | Agile Scrum/Kanban with a community | Easy to medium |
+| Wekan | Open source Trello | Easy |
+| Vikunja | Simple task and project tracking | Easy |
+| OpenProject | Budgets, Gantt, governance | Hard |
+
+## Plane
+
+Plane is the most modern tool here: issues, cycles, modules, and a spec-workflow that product teams recognise from Linear or Jira. The community edition is AGPLv3, and the project moves fast, which is a feature until it is a problem. Upgrades are regular and occasionally breaking. If your team wants a fast, opinionated tracker with views, Plane is the one. If you need stability over motion, wait a release cycle before committing.
+
+## Focalboard
+
+Focalboard came out of Mattermost as a Trello-style board tool, MIT licensed, with both a personal desktop edition and a server edition. It is genuinely easy to run and pleasant to use. The caveat is real: Mattermost refocused its effort in 2024 and Focalboard's future has been quiet since. It still works and is fine for personal kanban, but I would not build a company process on a project with an unclear roadmap. Check the repo's activity before you rely on it.
+
+## Leantime
+
+Leantime is deliberately different. It markets itself as a project management tool for non-project managers, covering everything from ideas to launch, with goals and strategy maps rather than just tickets. It is AGPLv3. If your team has people who bounce off Jira, Leantime's focus on "what are we trying to achieve" rather than "where is this ticket" lands well. The tradeoff is that it is less precise for teams that genuinely want sprint mechanics.
+
+## Taiga
+
+Taiga has been the agile community workhorse for over a decade: Scrum, Kanban, issues, and a clean UI that was modern before "modern PM" was a marketing category. It is AGPLv3 after moving from MPL in 2021, so check the [licensing](/how-open-source-licensing-works) page if you plan to offer it as a service. Taiga suits open source communities, student teams, and agencies that run real sprints. Its weaknesses are the classic AGPL ecosystem ones: fewer integrations than SaaS trackers, and the community edition lags the enterprise edition.
+
+## Wekan
+
+Wekan is the most direct open source Trello: lists, cards, checklists, swimlanes, and a Meteor-based app that is MIT licensed. It is simple to self-host with Docker. For a small team that only needs kanban and nothing else, it is hard to fault. The tradeoffs: Meteor hosting is a niche skill if you need to debug it, and the UI is showing its age.
+
+## Vikunja
+
+Vikunja is a Go backend with a clean frontend that does lists, kanban, Gantt, and calendar views from the same tasks, plus sharing and a public API. It is AGPLv3 and about the easiest proper project tracker to run, a single binary plus a database. Its strongest fit is personal productivity and small teams that want task management without an approval workflow or dashboards. If you need Jira-grade reporting, it is not that.
+
+## OpenProject
+
+OpenProject is the heavyweight: Gantt, budgets, timesheets, document management, and a governance model built for public sector and consulting. It is GPLv3. It does more than everything else here, and it shows in operations. The Rails stack wants a real server, regular maintenance, and a good look at memory usage. Choose it when you need project budgeting and portfolio reporting, and skip it when a kanban board would do.
+
+## Choosing
+
+For a product team that wants speed and modern UX, start with Plane. For a non-technical team, Leantime. For a simple board, Vikunja or Wekan. For budgets and reporting, OpenProject. Before you self-host anything, spend an hour reading the license and the GitHub activity, because AGPL tools come with service obligations and young projects come with churn. A tracker you maintain badly is worse than the SaaS subscription you were avoiding.
diff --git a/content/posts/best-open-source-projects-for-first-time-contributors.md b/content/posts/best-open-source-projects-for-first-time-contributors.md
new file mode 100644
index 0000000..6a8edcd
--- /dev/null
+++ b/content/posts/best-open-source-projects-for-first-time-contributors.md
@@ -0,0 +1,57 @@
+---
+title: "Best Open Source Projects for First-Time Contributors (Good First Issue Guide)"
+description: "Real open source projects that welcome beginners, plus how to evaluate a good first issue before you claim it. Practical picks for your first contribution."
+type: guide
+category: contribution
+tags: [open-source, beginners, good-first-issue, first-contribution, github]
+keywords: [best open source projects for beginners, good first issue, first open source contribution, beginner friendly open source, open source projects for first time contributors]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Finding a project that will actually accept your first PR matters more than the project's popularity. A massive repo with thousands of open issues can still take weeks to respond. A small, active project with a written contribution guide is often a better first stop.
+
+This is a list of real projects with a reputation for being welcoming to newcomers. Check the current state of their issue trackers before you pick one, because maintainers change and so do their moods.
+
+## freeCodeCamp
+
+The curriculum platform. It has a huge codebase, but the community is famously patient with beginners and there is always documentation work, translations, and bug fixes that are genuinely useful. Their open source handbook is a good read on its own.
+
+## Flutter
+
+The UI toolkit from Google. The docs repo and the samples repo are beginner friendly in a way the core framework is not. Fixing a broken sample or improving documentation gets you familiar with the ecosystem without needing to understand the engine internals.
+
+## Open Food Facts
+
+A community project that catalogues food products from barcodes. It touches web, mobile, and data processing, and the maintainers welcome people who want to contribute to a product that has real public benefit. Tasks often include data fixes and small feature work.
+
+## Public Lab
+
+An environmental research community with open source hardware and software. If you like the idea of contributing to something with a purpose beyond code, this is a strong candidate. The maintainers are used to mentoring contributors from non-traditional backgrounds.
+
+## Kubernetes docs
+
+The documentation repo is huge, but it is well structured and the SIG Docs community actively helps newcomers. Doc fixes, localization, and diagram corrections are the usual entry points. You will learn a lot about how a large project manages contributions, even if you never touch the core.
+
+## How to evaluate a project before you claim an issue
+
+A good first issue is not just one with the label. Ask three questions.
+
+Is the project active? Check the last commit on the default branch and whether maintainers respond to issues within a reasonable window. A project with a good first issue label but no activity in six months will teach you nothing.
+
+Is the issue scoped? The best first issues describe a small, contained change with a clear definition of done. If the issue reads like a vague feature request, pass.
+
+Is there a contribution guide? A CONTRIBUTING.md that explains how to set up the environment, run tests, and open a PR is a strong signal the maintainers care about your time. Projects that expect you to figure out everything from a stale README will waste your evening.
+
+## Where to find these projects
+
+GitHub search with the `good first issue` label is the obvious starting point, but it returns a noisy list. Tools that rank projects by activity and filter by label make this faster. Whatever you use, sort by recent activity rather than stars. A project that merged a PR last week is a better bet than one that peaked two years ago.
+
+## The mindset that makes it work
+
+Your first contribution is not a test of how impressive you can be. It is a test of whether you can follow a process. Read the contribution guide, ask a clarifying question on the issue before you start if anything is unclear, keep the change small, and be ready to revise after review. Maintainers will forgive a rough first PR if you are responsive.
+
+Pick one project from this list, find a genuine issue, and start there. The second contribution is easier than the first, and it stays that way for a while.
diff --git a/content/posts/best-open-source-security-pentesting-tools.md b/content/posts/best-open-source-security-pentesting-tools.md
new file mode 100644
index 0000000..f757cfa
--- /dev/null
+++ b/content/posts/best-open-source-security-pentesting-tools.md
@@ -0,0 +1,51 @@
+---
+title: "Best Open Source Security & Pentesting Tools"
+description: "Open source security and pentesting tools that are actually used: Metasploit, Nmap, Wireshark, OWASP ZAP, John the Ripper, Hashcat, OpenVAS, Semgrep and Trivy."
+type: article
+category: tools
+tags: [open-source, security, penetration-testing, scanning, devsecops]
+keywords: [best open source security tools, open source pentesting tools, owasp zap, nmap, wireshark, metasploit, trivy]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A company pays you to break into its own systems, and a court calls it a crime when you do it without permission. That line is the whole job. Every tool in this list is a weapon when pointed at the wrong target, and in India the Information Technology Act treats unauthorized access seriously. Use these only on systems you own or have written authorization to test. With that out of the way, this is the open source kit most pentesters and security engineers actually keep installed.
+
+## Metasploit Framework: the exploit platform
+
+Metasploit (BSD) is the framework everyone starts with. It bundles thousands of exploits, payloads, and post-exploitation modules, plus a console that automates a lot of the mechanical work. Real-world use: validating a specific CVE in a test environment, generating a payload for a lab exercise, or pivoting inside a compromised demo network. It is heavy and noisy; modern detection stacks flag Metasploit traffic quickly, so treat it as a learning and lab tool, not a stealth capability.
+
+## Nmap: the network mapper
+
+Nmap is the first thing to run on any engagement. Port scanning, service and version detection, OS fingerprinting, and scripting all come in one command-line tool, and it runs on Windows, Linux, and macOS without fuss. A typical flow: scan the host range, identify open ports, run service detection, then let the scripting engine dig deeper. Every other tool on this list ends up targeting whatever Nmap tells you is there.
+
+## Wireshark: packet-level truth
+
+Wireshark (GPL-2.0) captures and dissects network traffic. When an app behaves strangely and the logs are silent, the packets do not lie. It is the tool for debugging authentication flows, spotting plaintext credentials on the wire, and confirming whether a service is really doing what it claims. The learning curve is real: you need to understand protocols before the filter bar makes sense. Still, it is the one tool that pays off in both security work and ordinary debugging.
+
+## OWASP ZAP: the web app scanner you can own
+
+For web application testing, OWASP ZAP (Apache-2.0) is the open source answer. It does active and passive scanning, proxy interception, fuzzing, and automated crawls, and it integrates into CI pipelines so you can run baseline scans on every build. It is less polished than Burp Suite Professional, and false positives need manual triage. Burp's free Community edition is popular too, but it is not open source and it blocks automation, so for repeatable work ZAP is the better base.
+
+## John the Ripper and Hashcat: password cracking
+
+These two solve the same problem differently. John the Ripper (open source) is a CPU-focused cracker with good autodetection of hash formats and a gentler learning curve. Hashcat (MIT) is GPU-first and dramatically faster once you have a decent graphics card, but it expects the hash format to be right. Use both to check whether the password hashes sitting in a breach dump are weak. Practical tip for Indian engineers: build your wordlists with local context, because common Indian passwords differ from the US-focused default lists.
+
+## OpenVAS: vulnerability scanning that wants resources
+
+OpenVAS, now part of Greenbone's community edition, is the main open source vulnerability scanner. It compares what it finds against a large feed of CVEs and produces a report of what needs patching. The honest review: it is powerful and exhausting. It needs a dedicated VM with decent RAM, the feed updates are heavy, and it will generate thousands of findings that require triage. For a small team, a managed scanner or a focused subset of plugins is often more realistic than running the full instance.
+
+## Semgrep: SAST that developers tolerate
+
+Semgrep (LGPL-2.1) is a static analysis tool that finds security issues in code without running it. Unlike older SAST products, the rules are patterns you can read and write, so it fits naturally into code review and CI. It catches real bugs like SQL injection and unsafe deserialization early, and the false positive rate is low enough that developers do not immediately rage-quit. This is the tool to add before the pentester finds your bugs.
+
+## Trivy: scanning your containers and dependencies
+
+Trivy (Apache-2.0) scans container images, filesystems, and git repos for known vulnerabilities in dependencies, and it also checks IaC files for misconfiguration. It is fast, it runs in CI as a single binary, and it gives you an SBOM of what is in your image. For teams pushing Docker images to production, Trivy in the pipeline catches the CVE before it ships. Combine it with Semgrep and you have covered both source-level and dependency-level risk.
+
+## What the stack looks like in practice
+
+A realistic engagement sequence: Nmap to map the surface, Wireshark when you need proof of what is on the wire, ZAP against the web app, Metasploit only where you need a known exploit in a lab, and John or Hashcat on any hashes you legitimately obtained. On the development side, Semgrep and Trivy run in CI so the scanning happens before release, not after a breach. If you are new to the field, start with Nmap and Wireshark and learn the protocols first; the exploit tools make more sense once you understand the traffic. For finding projects where these skills are in demand, check [the tools worth trying in 2026](/10-open-source-tools-worth-trying-in-2026) and the [contributor tool stack](/best-tools-for-open-source-contributors).
diff --git a/content/posts/best-open-source-self-hosted-apps-for-home-labs.md b/content/posts/best-open-source-self-hosted-apps-for-home-labs.md
new file mode 100644
index 0000000..c6ca861
--- /dev/null
+++ b/content/posts/best-open-source-self-hosted-apps-for-home-labs.md
@@ -0,0 +1,55 @@
+---
+title: "Best Open Source Self-Hosted Apps for Home Labs"
+description: "A practical open source home lab starter set: TrueNAS, Portainer, Jellyfin, Immich, Vaultwarden, Homepage, Pi-hole, AdGuard Home and Gitea, with honest hardware and maintenance expectations."
+type: article
+category: tools
+tags: [open-source, self-hosting, home-lab, docker, homelab]
+keywords: [best open source self hosted apps, home lab apps, self hosted homelab, jellyfin, immich, vaultwarden, pi hole]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A home lab is just a computer you own running software you control, usually in a corner of the house or on a cheap cloud VPS. The point is not the hardware, it is replacing monthly subscriptions for photos, streaming, passwords, and file storage with services you run yourself. The honest framing: you save money and gain control, and you pay for both with your evenings, because self-hosted software is never maintenance-free.
+
+## Where to start: the hardware question
+
+Do not buy anything yet. A home lab begins with whatever you already have: an old laptop with 8GB of RAM, a used mini PC, or a Raspberry Pi 4 or 5 for lightweight tasks. If you want a dedicated box, a used business mini PC with an SSD is the sweet spot in India, cheap to buy and to run. The one thing you need to accept is that you will eventually lose a drive, so backups are part of the setup, not an afterthought.
+
+## The base layer: Docker and Portainer
+
+Docker is how most self-hosted apps ship these days, one command and the app runs. Portainer gives it a web UI where you can manage containers, stacks, and volumes without memorizing every flag. Together they turn a bare Linux install into something a non-Docker-expert can run. This is the correct first step for most people. Skip the fancy orchestration for now; a single box with Docker Compose files is easier to back up and debug than a mini Kubernetes cluster you will regret.
+
+## TrueNAS: when you grow into real storage
+
+TrueNAS is a storage OS built on ZFS, with filesystems, snapshots, and replication that protect data properly. It is what you run when your media and backups matter. The cost is real: it wants a machine with enough RAM (8GB minimum, more is better), a bit of discipline around drive configuration, and patience while you learn ZFS concepts. Start with Docker on a normal OS. Move to TrueNAS when the data volume justifies a dedicated box.
+
+## Jellyfin: your own Netflix
+
+Jellyfin (GPL-2.0) streams your media library to TVs, phones, and browsers with no subscription and no account phone-home. Point it at a folder of movies and shows, and clients handle the rest. It also supports hardware transcoding on most GPUs, which matters on Indian internet speeds where a laptop might need to transcode to a weaker stream. The maintenance task nobody mentions is metadata and library cleanup; every few months you will fix titles and posters.
+
+## Immich and PhotoPrism: the Google Photos problem
+
+Your photo library is the most expensive thing in your life by subscription count. Immich (AGPL-3.0) is the closest open source equivalent to Google Photos: automatic backup from your phone, face recognition, search, and a decent mobile app. It updates fast and occasionally breaks something in the process, so keep it on the latest release. PhotoPrism (AGPL-3.0) is the older, more stable alternative with good search and timeline views, though development is slower. Pick Immich for active development and mobile-first use, PhotoPrism if you want fewer surprises.
+
+## Vaultwarden: the password manager that protects itself
+
+Vaultwarden (GPL-3.0) is a lightweight, community-maintained server for Bitwarden clients. Your passwords, TOTP codes, and secrets live on your hardware instead of a company cloud, and the official Bitwarden apps work against it directly. Note that it is a reimplementation, not an official Bitwarden product, so keep your vault backups separate from the server itself. This is the highest-value app in the whole home lab: it earns its keep every single day.
+
+## Homepage and Homarr: dashboards to keep order
+
+Once you run ten services, you need a map. Homepage and Homarr are self-hosted dashboards that show your apps, their status, and quick links in a browser tab. Homepage is config-driven and developer-friendly; Homarr is drag-and-drop and closer to an app launcher. Both are small, and both solve the real problem of remembering which port your stuff lives on. Add one early, because the list grows faster than you expect.
+
+## Pi-hole and AdGuard Home: network-wide ad blocking
+
+A DNS-level ad blocker stops ads on every device in your house before they reach the browser, no extensions needed. Pi-hole and AdGuard Home both do this and are light enough for a Raspberry Pi Zero W. AdGuard Home has an easier setup with its own dashboard and built-in filters; Pi-hole has the bigger plugin and blocklist ecosystem. Both are the kind of quiet improvement that makes a home lab feel worth it within a week.
+
+## Gitea and Forgejo: your own git server
+
+Gitea (MIT) and its fork Forgejo (MIT) run a GitHub-style server in a single small binary. Use them for private repos without monthly limits, or as the home for your dotfiles, scripts, and notes. Forgejo even includes built-in Actions-compatible CI, so you can run builds on your own hardware. For a solo user this is one of the easiest wins on the list.
+
+## The maintenance reality
+
+Here is what nobody tells you before you start: updates will occasionally break a service, your SSD will fill up with logs and backups, and you will spend a Sunday evening debugging why Immich stopped connecting. The habits that keep a home lab alive are boring: read changelogs before updating, keep Compose files in git, and do regular backups to a second disk. If that sounds acceptable, start with Portainer, Pi-hole, and Vaultwarden, then add services as you build confidence. For the tool-specific choices here, the [licensing guide](/how-open-source-licensing-works) explains which obligations come with the AGPL apps you are running.
diff --git a/content/posts/best-open-source-video-editing-software.md b/content/posts/best-open-source-video-editing-software.md
new file mode 100644
index 0000000..8418bab
--- /dev/null
+++ b/content/posts/best-open-source-video-editing-software.md
@@ -0,0 +1,45 @@
+---
+title: "Best Open Source Video Editing Software"
+description: "Open source video editors compared by ease of use and features: Kdenlive, Shotcut, OpenShot and Olive, plus what hardware you really need for 1080p and 4K."
+type: article
+category: tools
+tags: [open-source, video-editing, kdenlive, shotcut, openshot]
+keywords: [best open source video editing software, free video editor, kdenlive vs shotcut, openshot review, linux video editor]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Every second video in India is shot on a phone and edited on whatever the neighbor recommended, which usually means a pirated copy of a paid editor or CapCut with a watermark. Open source editors have closed most of the gap, and for a small YouTube channel or a freelancer they are enough. The honest part of this list is hardware: 1080p editing is fine on a mid-range laptop, but 4K without proxies will make any free software crawl, no matter which one you pick.
+
+## Kdenlive: the best all-rounder
+
+Kdenlive (GPL) is a timeline-based editor that feels like the open source Premiere. It has multiple tracks, transitions, keyframing, effects, and proxies built in, and it handles the common workflow well: cut, add titles, music, export. For a beginner it is a bit much at first, but the layout is logical and there are enough tutorials for a full course. It is the editor I recommend first, especially on Linux where it behaves best. The downsides are the same as every complex free tool: occasionally weird crashes on certain hardware and effects that need manual research.
+
+## Shotcut: great on weak laptops
+
+Shotcut (GPL-3.0) uses a non-destructive clip-based workflow, which is different from Kdenlive's timeline model and takes getting used to. Its real strength is performance: it starts fast and runs well on modest hardware, which is the realistic situation for most students and first-time editors. If your laptop has 8GB of RAM and integrated graphics, Shotcut will be usable where heavier editors will not. Filter placement and audio editing are fiddly, but the tradeoff is worth it on an underpowered machine.
+
+## OpenShot: the easiest to learn
+
+OpenShot (GPL-3.0) is the friendliest of the three. Drag clips, drop them, done. A teenager can edit their first video in an hour. The cost is depth: effects, keyframing, and complex multi-track work are limited, and it can get sluggish with long timelines. Use it to learn editing, then move to Kdenlive or Shotcut when you hit its ceiling. For short social clips it stays perfectly adequate.
+
+## Olive: promising, still not finished
+
+Olive (GPL-3.0) is a professional-looking editor with a node-based workflow, and it has been in active development for years. It has real potential and a great interface, but the project's momentum has been inconsistent, so treat it as an experiment. Do not make it your production tool yet. If you like what you see, keep an eye on releases, because a stable Olive would be the most modern open source option on this list.
+
+## DaVinci Resolve: not open source, but worth mentioning
+
+DaVinci Resolve is the editor most people compare against, and it is genuinely excellent: free, with color grading that beats everything here. It is also proprietary freeware, not open source, so it does not belong on a list of open source software. That distinction matters if you care about [how open source licensing works](/how-open-source-licensing-works) or self-hosting your tools. If you just want the best free editor and accept closed source, Resolve wins. If open source matters, Kdenlive is your answer.
+
+## What hardware you actually need
+
+Here is the realistic math. For 1080p at 30fps, a modern i5 or Ryzen 5 with 16GB RAM and any half-decent GPU is comfortable in Kdenlive or Shotcut. For 4K, you need either a beefy machine or proxies, which both Kdenlive and Shotcut support well. On 8GB RAM, stick to 720p or 1080p short clips and close the browser while editing. A real example: a small YouTube channel run on a budget laptop, an i5 with 8GB, edits talking-head videos in Shotcut with 720p proxies for any 4K phone footage, exports in under an hour, and has not spent a rupee on software. That is a normal outcome, not a lucky one.
+
+## Export settings people get wrong
+
+The common mistake is exporting everything as the highest quality possible and then complaining the upload takes forever. Learn the presets: YouTube handles compressed H.264 at a reasonable bitrate fine, and you will not notice the difference. Matching frame rate to source footage also prevents the stutter you get from mismatched 30fps and 60fps clips. These two settings fix more beginner issues than any editor choice does.
+
+Start with OpenShot if you are brand new, move to Kdenlive or Shotcut after a few videos, and skip Olive until it stabilizes. The software is free, so your only real investment is the time to learn the timeline properly.
diff --git a/content/posts/best-platforms-to-discover-open-source-projects.md b/content/posts/best-platforms-to-discover-open-source-projects.md
new file mode 100644
index 0000000..c3b98e5
--- /dev/null
+++ b/content/posts/best-platforms-to-discover-open-source-projects.md
@@ -0,0 +1,36 @@
+---
+title: "Best Platforms to Discover Open Source Projects in 2026"
+description: "A practical comparison of GitHub Explore, GitLab, ossium, Sourcegraph, and other open source discovery tools, with what each is genuinely good at and where it falls short."
+type: article
+category: tools
+tags: [open-source, discovery, github, ossium, sourcegraph]
+keywords: [best platforms to discover open source projects, open source discovery tools, github explore alternative, sourcegraph, gitlab explore]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+There are more ways to find open source software in 2026 than any developer needs, and they are not interchangeable. Each platform answers a different question. GitHub Explore shows you what is currently noisy. ossium tracks what is trending and lets you filter it. Sourcegraph searches inside the code itself. Reach for the wrong one and you will spend evenings on repos that do not fit what you actually wanted to do. Here is what each one is genuinely good at.
+
+**GitHub Explore** is the default starting point. It sits inside GitHub, so every trending repo links straight to its issues, stars, and forks. The trending page updates daily, and the topics and collections sections are hand-curated. It is best for a quick browse, the "what are people excited about this week" use case. The shortfall is that the feed is star-heavy. A repo that is popular with a hype community drowns out something with slow, steady traction. And it only covers GitHub, which is most of open source but not all of it.
+
+**GitLab Explore** covers the GitLab ecosystem, which holds a lot of serious corporate open source and the self-hosted crowd. Its explore page has trending projects, popular topics, and per-user starred projects. It is the right place when you know a project migrated away from GitHub, or when you want to see what the non-GitHub half of the world builds. The tradeoff is volume. GitLab simply has less traffic, so discovery there is quieter and less current.
+
+**ossium** is built for discovery rather than hosting. It pulls GitHub data and surfaces trending repos, then lets you narrow by programming language and license before you ever open a repository page. That matters more than it sounds. Star counts tell you a project is popular and almost nothing about whether it is MIT or GPL, maintained, or a match for your stack. ossium gets those facts up front, and its compare and track features exist because discovery is rarely a one-step lookup. If you are hunting for a self-hosted tool or an AI library with a specific license, this is where you start. The tradeoff is that the data comes from GitHub, so ossium is a view of GitHub, not a replacement for it. The [comparison with GitHub Explore](/ossium-vs-github-explore) goes into the difference in detail.
+
+**Sourcegraph** does the opposite of everything above. It is a code search engine. You can search across millions of repositories for an exact function, a usage pattern, or an example of how a dependency is actually imported. This is the tool when you want to see how a project is implemented, not what its README claims. Its weakness is that it is a research tool, not a browsing tool. You go there with a question, not to discover what exists.
+
+Two smaller ones are worth knowing. **Hacker News** is not a directory, but its front page and Algolia search are the best early warning system for projects about to get popular. Read the comments, they will tell you what is broken. **LibHunt** ranks libraries by GitHub stars and groups them by topic, which makes it useful for "best X library in category Y" questions, even if the ranking logic is basically a popularity chart. Related to that point, [this licensing explainer](/how-open-source-licensing-works) covers the terms you should be checking once the ranking gives you a candidate.
+
+| Platform | What it is best at | Tradeoff |
+|---|---|---|
+| GitHub Explore | Fast daily trending browse inside GitHub | Star-heavy feed, GitHub only |
+| GitLab Explore | Discovery in the GitLab ecosystem | Quieter, lower volume |
+| ossium | Filtering by language and license, comparing, tracking | Data is a GitHub view |
+| Sourcegraph | Code-level search across millions of repos | Research tool, not a browse tool |
+| Hacker News | Early signal on rising projects | Unstructured, noisy |
+| LibHunt | Library rankings by category | Basically a popularity chart |
+
+The practical workflow is to use them in sequence. Start with ossium when you have criteria in mind, use GitHub Explore for a general scan, then open Sourcegraph to check the code before you commit to a project. That covers most of what discovery actually is.
diff --git a/content/posts/can-i-use-open-source-software-commercially.md b/content/posts/can-i-use-open-source-software-commercially.md
new file mode 100644
index 0000000..e2f0bd1
--- /dev/null
+++ b/content/posts/can-i-use-open-source-software-commercially.md
@@ -0,0 +1,28 @@
+---
+title: "Can I Use Open Source Software Commercially?"
+description: "Can open source software be used commercially? Permissive licenses allow it with attribution; copyleft adds source-sharing conditions. What Indian SaaS businesses need to know."
+type: question
+category: beginners
+tags: [open source, commercial use, licensing, mit, gpl, agpl]
+keywords: [can i use open source commercially, open source commercial use, gpl commercial use, agpl for saas, mit license commercial, open source license for business]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+answerSummary: "Yes, open source can be used commercially; permissive licenses let you sell and close your code, while copyleft licenses require you to share source or provide it to users under certain conditions."
+---
+
+Short answer: yes, in almost every case. Open source is not "free for personal use only", and most licenses explicitly permit commercial use. What a license actually controls is your obligations, and those differ a lot between the two big families.
+
+Permissive licenses, MIT, Apache 2.0, BSD, are the easiest to build a business on. They let you use, modify, and redistribute the software in any product, including a closed-source commercial one, and sell that product for whatever you want. You do not have to publish your changes. Your only real obligations are keeping the copyright notice and not claiming you wrote it. Apache 2.0 additionally grants a patent license, which is valuable if you distribute software and hold patents. A small Indian software company can take a permissively licensed library, bake it into a product, sell subscriptions, and never open a line of their own code. That is entirely legal and is how a huge share of commercial software works.
+
+Copyleft licenses, GPL, LGPL, and AGPL, are the ones that carry conditions. GPL lets you use and even sell the software commercially, but if you distribute a modified version to others, you must release your modifications under GPL so recipients get the source too. Internal use is safe: if you run GPL software inside your company and never hand it out, no obligation kicks in. LGPL is the library-friendly version; you can link it into a closed product without open-sourcing your application, as long as you share any changes you make to the library itself.
+
+AGPL is the one that surprises Indian SaaS founders most. It adds a network clause: if you run modified AGPL software as a service that people interact with over the internet, the users of that service are entitled to the source. Distribution no longer requires handing over a file, running it counts. So building a hosted product on a modified AGPL database or server without publishing source is a violation.
+
+A concrete example: a Pune startup building an invoicing platform for small businesses. They use an MIT-licensed PDF library for invoices, an Apache-licensed web framework, and an AGPL-licensed search engine they modified to add Hindi and Marathi indexing. The MIT and Apache parts are done, keep the notices. The search engine is the problem; because they modified it and run it as a service, they must publish their changes. Options: publish the modifications, and they lose nothing, since users of the service are not competitors for a search engine they barely touched, or use an unmodified version, or switch to a permissive alternative. Most teams pick the last two without realizing the first one is often fine.
+
+Where people go wrong: assuming GPL bans commercial use (it does not, "commercial" never appears as a ban in the license), assuming code on GitHub is free to use with no license at all (wrong, no license means no permission), and assuming compliance is about money (it is about source). Another common trap is mixing licenses. If you combine GPL code into an MIT project, the combined work may have to ship under GPL, which poisons the permissive posture.
+
+So, for a commercial product: permissive licenses are effectively friction-free with attribution. Copyleft requires you to plan for source sharing if you distribute or, for AGPL, if you run it as a service. Neither prevents you from making money. Read the license before you commit, decide early which family you want in your stack, and revisit when you add dependencies. The full comparison is in [our licensing explainer](/how-open-source-licensing-works).
diff --git a/content/posts/companies-hiring-for-open-source-contributions.md b/content/posts/companies-hiring-for-open-source-contributions.md
new file mode 100644
index 0000000..6f43695
--- /dev/null
+++ b/content/posts/companies-hiring-for-open-source-contributions.md
@@ -0,0 +1,55 @@
+---
+title: "Companies Hiring for Open Source Contributions (2026 List)"
+description: "A practical list of companies that publicly value open source contributions, from Red Hat and GitLab to Postman and Zoho, and what a candidate can actually do."
+type: article
+category: career
+tags: [open source jobs, companies hiring contributors, open source careers, github, india]
+keywords: [companies that hire open source contributors, red hat open source careers, gitlab contributor jobs, postman open source, open source jobs india]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+No company has a "we hire GitHub contributors" sign, but some hire like one. Red Hat built its whole business on the model, and GitLab and Grafana Labs run on products their own engineers maintain. This list covers who publicly talks about contributions, and what that actually means for a candidate. The honest version comes at the end.
+
+## Red Hat
+
+Red Hat's founders have said for decades that contributors make the best employees, and it is structurally true, since the company ships RHEL, Fedora, and a large share of Kubernetes-related code. What to do: contribute to Fedora packaging, Kubernetes components, or any project Red Hat maintains. Their engineering interviews read like open source reviews, because they are.
+
+## Canonical
+
+Canonical, the company behind Ubuntu, has the same DNA. It sponsors community work on Ubuntu, and many staff are long-time package maintainers. What to do: get involved in Ubuntu packaging, snapcraft, or the LXD and MAAS projects. Contribution history is visible in the community, and it helps the conversation with a recruiter.
+
+## GitLab
+
+GitLab is open core, all-remote, and famously community-driven. It ran a paid contributor program for years, and a good number of its engineers came from the contributor pool. What to do: fix real issues in GitLab itself. The codebase is open, the issue tracker is public, and your contribution is literally a patch to the hiring company's product.
+
+## Grafana Labs
+
+Grafana, Loki, and Prometheus are the modern observability stack, and Grafana Labs hires people who understand them deeply. A merged PR to Grafana is visible to the team that maintains it. What to do: contribute to the Grafana dashboards ecosystem, Loki, or Tempo. This is the kind of company where your GitHub history is your resume.
+
+## Elastic and MongoDB
+
+Both companies built huge communities around Elasticsearch and MongoDB, and both relicensed to source-available licenses to stop clouds from reselling them. The controversy does not change the hiring picture. Their forums, issues, and conferences are staffed by people who came through community contributions. What to do: solve real support questions, submit accepted PRs, and show up in the community discussions.
+
+## Automattic and WordPress
+
+WordPress runs a third of the web, and Automattic hires from its contributor community and sponsors events worldwide. It is also a global company that hires remote engineers from India, which matters for how a contribution gets weighted. What to do: contribute to WordPress core or plugins, attend WordCamps, and build on the ecosystem.
+
+## Google, Meta, and Microsoft
+
+None of these hire you for a contribution, and their pipelines are standard interviews. But the open source angle helps inside. Google runs [Summer of Code](/what-is-google-summer-of-code-gsoc) and lives in Chromium and Kubernetes. Meta owns React and PyTorch, and hiring managers there read contributor history. Microsoft owns GitHub and TypeScript, and the .NET Foundation is a real path into the ecosystem. What to do: treat these as long games, a serious contribution is a strong talking point in a normal interview.
+
+## Databricks
+
+Databricks employs a large share of Apache Spark committers, and Spark is effectively governed from inside the company. What to do: contribute to Apache Spark or Delta Lake. The bar is high, and the payoff is a company where deep Spark knowledge is the core skill.
+
+## The Indian picture
+
+Postman was founded in India and grew into a global API company by serving the developer community first; it maintains an open source presence and hires engineers who understand the API ecosystem. Razorpay open sources pieces of its stack and runs a public engineering blog that doubles as a contribution signal. Zoho is not an open source company in the Red Hat sense, but its engineering teams build on and occasionally contribute to open source, and its hiring is more practical than credential-driven. The IT services giants, TCS, Infosys, and Wipro, all have open source programs and Apache project involvement, so an Apache committer title is worth something there.
+
+## The honest version
+
+Most of this is visibility, not a formal guarantee. No recruiter gets a bonus for finding your merged PR, and none of these companies will email you because you contributed. What actually happens is softer: you are easier to find, you have better stories for interviews, and people inside the company already know your name. That is a real edge, and it is worth having, as long as you do not expect a job offer to fall out of a pull request. If you are new to this, start with the basics in the [GitHub contribution guide](/how-to-contribute-to-open-source-on-github) and the list of [tools for open source contributors](/best-tools-for-open-source-contributors).
diff --git a/content/posts/history-of-open-source-from-gnu-to-github.md b/content/posts/history-of-open-source-from-gnu-to-github.md
new file mode 100644
index 0000000..18f5f9f
--- /dev/null
+++ b/content/posts/history-of-open-source-from-gnu-to-github.md
@@ -0,0 +1,31 @@
+---
+title: "History of Open Source: From GNU to GitHub"
+description: "A short narrative history of open source: Unix and hacker culture, Richard Stallman and GNU, Linux, the term 'open source' and Netscape, Apache, GitHub, and where AI fits in now."
+type: article
+category: tools
+tags: [open-source, history, gnu, linux, github]
+keywords: [history of open source, richard stallman gnu, linus torvalds linux, open source movement, gnu to github]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Open source did not start at GitHub. It started in a world where software came attached to hardware and the people who wrote it were expected to share. In the 1960s and 70s, at places like MIT and Bell Labs, code circulated freely between researchers. Unix, written at Bell Labs in 1969, was passed around with its source code, and a generation of programmers grew up reading and improving it. That culture, often called hacker culture, assumed the source was part of the package.
+
+Then computing went commercial. By the 1980s, vendors sold binary-only software signed with nondisclosure agreements, and sharing became illegal. Richard Stallman, a researcher at MIT's AI Lab, watched the shift and refused to accept it. In 1983 he announced GNU, a recursive acronym for "GNU's Not Unix", a plan to build a complete Unix-compatible operating system that everyone could use freely. He also wrote a license for it, the GNU General Public License, which used copyright itself to guarantee freedom: anyone could use, modify, and redistribute the software, but modified versions had to be shared under the same terms. That trick became known as copyleft.
+
+In 1985 Stallman founded the Free Software Foundation to fund and protect the project. GNU grew steadily, a compiler here, a text editor there, but a crucial piece was missing: the kernel, the core that talks to the hardware.
+
+That piece arrived in 1991 from a 21-year-old Finnish student, Linus Torvalds, who built a Unix-like kernel for his own PC and posted it to a newsgroup. He released it under the GPL, and the combination of GNU tools and the Linux kernel gave the world a complete free operating system. Linux spread because it was open: thousands of people could fix bugs, add drivers, and build distributions. The internet had finally made that kind of collaboration possible at scale.
+
+By the late 1990s, "free software" had a marketing problem. The word "free" was read as price, and the movement's moral framing made businesses nervous. In 1998 a group of advocates, including Eric Raymond and Bruce Perens, coined the term "open source" to describe the same approach with the emphasis on practical benefits: better code through many eyeballs, faster bug fixes, no vendor lock-in. The meeting where the term was picked was itself a response to a shock. Netscape, the leading browser company, had just released its browser's source code to fight off Microsoft. That event, in January 1998, is what made companies pay attention.
+
+Around the same time, the web had quietly built its own open source success story. The Apache web server, started in 1995 from a series of patches to the NCSA server, grew to dominate the early web. The name itself is a joke, "a patchy server", which tells you everything about how the project felt then. By 1999 Apache served more sites than all proprietary competitors combined. Open source had proven it could run the infrastructure of the new internet.
+
+The next decade industrialized the model. Red Hat went public in 1999, and enterprises began trusting Linux and open source databases. The bigger shift was tooling. Git, released by Torvalds in 2005 to manage the Linux kernel, changed how version control worked. Then GitHub launched in 2008 and made Git social. Suddenly contributing to an open source project meant fork, edit, pull request, review, merge, a workflow so clean it became the default way software teams work everywhere, not just in open source. GitHub did not invent open source, but it turned it from a philosophy into an everyday practice for millions of developers.
+
+That is where the corporate takeover happened, and quietly. The companies that once feared open source are now its biggest funders. Google, Microsoft, and Meta run enormous open source programs, and much of the modern internet's infrastructure, Kubernetes, React, PostgreSQL, is open source. Open source became the default for new software in a way Stallman in 1983 could not have imagined.
+
+The newest frontier is AI. The live argument is about open models and open weights: Meta released Llama openly while others keep models closed. In 2026 that debate, over whether the inner workings of an AI model should be public, echoes the 1980s fight over source code almost exactly. The players have changed, and the question is the same, whether the people who use a technology are allowed to understand it. If you want to be part of it, my guide to finding open source projects for beginners is where to start today.
diff --git a/content/posts/how-contributing-to-open-source-boosts-your-developer-career.md b/content/posts/how-contributing-to-open-source-boosts-your-developer-career.md
new file mode 100644
index 0000000..69c30a1
--- /dev/null
+++ b/content/posts/how-contributing-to-open-source-boosts-your-developer-career.md
@@ -0,0 +1,48 @@
+---
+title: "How Contributing to Open Source Can Boost Your Developer Career"
+description: "How open source contributions act as public proof of work, teach production code, and open up jobs and speaking opportunities, with the honest limits for Indian developers."
+type: article
+category: career
+tags: [open source career, github profile, developer career, contribution, maintainership]
+keywords: [how open source contribution helps career, github profile for job interview, open source developer career india, does contributing to open source get you a job, open source maintainer career]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A Bangalore recruiter once told me she skips GitHub links because everyone has a profile and nobody has a real project. She is partly wrong. A merged PR into a real project is not the same as a fork of a tutorial, and the difference shows up in interviews. But she is also not completely wrong, so let me be precise about where contributions actually help.
+
+## Public proof of work
+
+A course certificate proves you sat through a course. A merged PR proves you wrote code someone else reviewed, argued about, and accepted. Anyone can see the conversation, the revisions, and how you handled feedback. That is closer to how teams actually work than any exam. It is the strongest signal a resume can carry, and it costs nothing except your time.
+
+## Hiring managers do look, sometimes
+
+Product companies, startups building on open source, and remote-first teams do check. If the company uses Kubernetes, a contribution to a Kubernetes-related project beats a line item on your resume. The recruiters who do not look are mostly in IT services and bulk hiring, which brings me to the honest part later.
+
+## Learning production code
+
+This is the quiet win. Open source codebases have real users, real bugs, real CI, real release processes. You will learn how to read a large codebase, how tests are structured, how maintainers review, and how a release actually ships. That experience is what interviewers are probing with system design questions, and it is nearly impossible to get it from a side project of your own, where you already know every line.
+
+## Building reputation
+
+Maintainers and mentors become references, collaborators, and occasionally co-workers. Speaking at meetups and conferences often starts with a talk about a project you contributed to. Programs like [Google Summer of Code](/what-is-google-summer-of-code-gsoc) and [Hacktoberfest](/hacktoberfest-guide-for-beginners) put you in front of people who matter. A reputation built in public compounds the same way a good credit history does, slowly and then suddenly.
+
+## The opportunities that open up
+
+- Jobs at companies that use the project you contributed to.
+- Speaking invitations once you have shipped something worth talking about.
+- Maintainership, which is a real leadership role with people managing you, and occasionally paid.
+- Referrals, because maintainers get hired all the time and they remember who showed up.
+
+## The honest limits
+
+Here is the part recruiters and tutorials skip. A few small PRs will not get you hired by themselves. Merge a documentation fix into a popular repo and nobody will call you. The value comes from depth: a feature you owned, a bug you hunted, a module you understood better than most of its users. If the goal is a job, pick one project, work on it for six months, and let the work speak. If the goal is learning, that depth is the point anyway.
+
+And the Indian reality: many recruiters at Indian companies do not check GitHub. IT services hiring is driven by certifications and tests, not contribution graphs. Contributions help most when you are interviewing at product companies, at companies that use the project, at international or remote roles, or during your first job search when you have no work experience to point at. Treat contributions as leverage, not a replacement for fundamentals.
+
+## Where to start
+
+If you are early, start small but stay consistent: find a project with a healthy review culture, read its contribution guide, and fix your first issue. The practical workflow lives in the guides on [contributing on GitHub](/how-to-contribute-to-open-source-on-github) and [finding beginner projects](/how-to-find-open-source-projects-for-beginners). Set up your tooling with the [tools for open source contributors](/best-tools-for-open-source-contributors) and treat the work as a habit, not a sprint. The career benefit is real, but it is a byproduct of actually becoming better, not a shortcut around it.
diff --git a/content/posts/how-do-open-source-developers-make-money.md b/content/posts/how-do-open-source-developers-make-money.md
new file mode 100644
index 0000000..e14d965
--- /dev/null
+++ b/content/posts/how-do-open-source-developers-make-money.md
@@ -0,0 +1,32 @@
+---
+title: "How Do Open Source Developers Make Money?"
+description: "How do open source developers make money? Paid support, managed hosting, open core, dual licensing, sponsorships, and the career path. An honest look at what actually pays."
+type: question
+category: tools
+tags: [open source, money, maintainers, careers, github sponsors]
+keywords: [how do open source developers make money, open source monetization, how to make money from open source, open core business model, github sponsors, open source maintainer income]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+answerSummary: "Developers make money from open source through paid support, managed hosting, open-core premium features, sponsorships and donations, or by leveraging contributions for career opportunities; most projects earn nothing directly."
+---
+
+Honest answer first: most open source developers do not make money directly from their open source work. For every project that earns a living, there are thousands earning nothing at all. That is not a complaint, it is just the shape of the economics. What money does exist arrives through a handful of paths, and knowing them helps you decide whether "monetize my project" is even the right goal.
+
+Donations are the simplest and usually the smallest. GitHub Sponsors, Open Collective, and Patreon let users pay maintainers directly. This works best for niche developer tools with a loyal audience; a library that a hundred thousand engineers depend on can bring in real sponsorship money even if no single user pays much. But donations rarely scale, and most projects will never see enough of them to matter.
+
+Sponsored and salaried work is where the serious money lives. Companies that depend on open source pay maintainers to keep it alive, either by hiring them outright or by sponsoring specific features. Red Hat is the canonical example; it built a billion-dollar business selling support and certifications around GPL software, and it pays thousands of developers whose code is free. GitLab similarly employs most of its maintainers while selling paid tiers on top of a free core.
+
+Paid support and consulting is a sibling of the same idea. The software is free, the expertise is not. A company running PostgreSQL in production does not want to debug it alone at 2 a.m., so it buys a support contract, and that contract is what pays the people who maintain it. India's growing open source services companies, which deploy and support open source stacks for clients, run exactly this play.
+
+Managed hosting takes the software and sells the operations. Supabase sells a hosted Postgres platform built on open source, and companies pay to avoid running it themselves. This is the "open core" pattern in practice: a genuinely free core drives adoption, and the money comes from premium features, hosting, and enterprise controls. GitLab, Mattermost, and n8n all follow it.
+
+Dual licensing is rarer but still alive. The same code is offered under two licenses, typically one permissive for commercial customers and one copyleft, and the commercial license is what gets billed. MySQL ran this model under Sun, and Elastic did a variant of it. It requires the author to own every line of the code, which is why you rarely see it in community projects.
+
+Foundations are the least glamorous path. The Linux Foundation, Apache Foundation, and CNCF employ maintainers of critical infrastructure so that operating systems and container runtimes are not one panic away from abandonment. If you maintain something infrastructure-critical, a foundation salary is a real option.
+
+Then there is the career angle, which is the one most Indian developers actually experience. Contributions build a public track record that hiring managers can verify, and that translates into job offers, promotions, and freelance rates far more reliably than any donation. Plenty of people contribute for two years, get noticed through their PRs, and land roles where their open source work is listed as the reason. The money is indirect, but it is the most common payoff in the whole ecosystem.
+
+The realistic summary: most projects earn nothing, and the projects that do earn usually combine several of these paths. If you are starting an open source project with income as the goal, treat it as a long bet. The more reliable returns are reputation and skill. For the motivations people actually cite, [our post on why to contribute](/why-contribute-to-open-source) is worth a read, and if you are just starting, [the guide to finding your first projects](/how-to-find-open-source-projects-for-beginners) covers where to begin.
diff --git a/content/posts/how-open-source-licensing-works.md b/content/posts/how-open-source-licensing-works.md
new file mode 100644
index 0000000..c88d6eb
--- /dev/null
+++ b/content/posts/how-open-source-licensing-works.md
@@ -0,0 +1,59 @@
+---
+title: "How Open Source Licensing Works: MIT, GPL, and Apache Explained"
+description: "A practical explanation of open source licenses (MIT, Apache, GPL, AGPL, LGPL) with the common mistakes developers make and how to check what you can legally use."
+type: guide
+category: tools
+tags: [open-source, licensing, mit, gpl, apache, beginners]
+keywords: [open source licensing, mit license vs gpl, apache license, open source license explained, gpl license for beginners]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A license is the difference between software you can run and software you are allowed to run. Open source only means the source code is readable. The license decides what you may legally do with it. Skip that file and you are building on borrowed ground without knowing the terms.
+
+## Start with the default: no license
+
+Most people assume any code on GitHub is free to use. It is not. Under copyright law, the author automatically holds all rights. If a repository has no license file, you have no permission to copy, modify, or redistribute anything, even for personal projects. I have seen full-time developers lift a utility function from a repo with no LICENSE, drop it into a client's production app, and only discover the problem months later when the author asks for a takedown. There is no polite fix for that conversation.
+
+So the first rule: if it has no license, treat it as "read only, ask first."
+
+## The two families
+
+Every open source license is a variation on two ideas.
+
+Permissive licenses, MIT, BSD, and Apache 2.0, let you use, modify, and redistribute the code, including in closed-source commercial software. Your obligations are light: keep the copyright notice, and don't pretend you wrote it. Apache 2.0 adds a patent grant, which matters if your company holds patents and you want to distribute the code.
+
+Copyleft licenses, GPL, AGPL, and LGPL, use copyright to do the opposite. If you distribute a modified version, you must release your modified source under the same license. GPL v3 also requires you to give recipients the means to run their own builds, and it revokes your patent rights if you sue a GPL user.
+
+| License | Family | Can I use commercially? | Do I share my source? |
+|---|---|---|---|
+| MIT | Permissive | Yes | No |
+| Apache 2.0 | Permissive | Yes | No |
+| LGPL | Weak copyleft | Yes | Only if you modify the library |
+| GPL | Strong copyleft | Yes, but only if you share source on distribution | Yes |
+| AGPL | Copyleft + network | Yes, but you share source even for a service | Yes |
+
+That table misses nuance, so let me fill it in. LGPL lets you link a library into a closed app without open-sourcing your app; it only requires you to release changes to the library itself and allow users to swap in their own version. GPL reaches your whole derivative work. AGPL exists because GPL does not trigger when software runs on a server, it only triggers on distribution. Companies caught on and started running GPL code as a service without sharing anything. AGPL closes that gap: "use it over a network" counts as distribution.
+
+## Where people go wrong
+
+The most common failure is treating "free" as "no conditions." You can charge money for GPL software. You can build a business around it. But you cannot distribute a modified version to customers while keeping the source closed. The cost is the source, not the rupees.
+
+Here is the example I keep running into. A small Indian agency signs a website contract for a Mumbai retailer. A junior dev pulls a GPL-licensed component and embeds it into the site's codebase. The site goes live, and since the code is delivered to the client's servers and in part to the browser, the copyleft obligation kicks in. The client now technically owes the source for the parts derived from that component, which no one mentioned in the invoice. At that stage the fix is a rewrite or a license negotiation, both expensive.
+
+A second common mistake is mixing licenses without checking compatibility. Combine a GPL library with an MIT project and the combined work may need to ship as GPL. That kills the MIT project's permissive posture, and maintainers will reject your PR if you cannot clean that up. It is the reason so many projects specify "no GPL dependencies" in their contribution guides.
+
+Third, rely on tooling instead of memory. NPM and PyPI show the declared license for each package, but metadata is sometimes wrong or missing. The reliable sources are the LICENSE file in the repo and the SPDX identifier on the package page. A minute spent checking beats a month of legal back-and-forth.
+
+Fourth, attribution. Permissive licenses look effortless until you ship and realize you must keep the copyright notice in your distributed copies. One line in a bundled notices file usually satisfies it. Ignoring it is technically a breach even though nobody will chase you over a hobby project. The habit matters when your project grows.
+
+## What to actually do
+
+Before you copy any code: read the LICENSE file, note the SPDX identifier, and write down which license governs what you took. If the project has no license, ask the maintainer or pick a different project. If you contribute, ask yourself whether the project's license matches what you are comfortable releasing, since a merged contribution is typically licensed under the project's terms.
+
+None of this is exotic. Reading a 200-line GPL preamble feels like homework, but the practical summary fits in a paragraph. If the code you use allows closed commercial use, you only need notice and attribution. If it is copyleft and you distribute, plan to share source. If it is AGPL and you run it as a service, plan to share source too.
+
+Pick the license that matches how you actually intend to use the code, check it once at the start, and you avoid the one conversation every developer dreads having with a client.
diff --git a/content/posts/how-ossium-helps-developers-discover-trending-open-source-repos.md b/content/posts/how-ossium-helps-developers-discover-trending-open-source-repos.md
new file mode 100644
index 0000000..087b5e7
--- /dev/null
+++ b/content/posts/how-ossium-helps-developers-discover-trending-open-source-repos.md
@@ -0,0 +1,29 @@
+---
+title: "How Ossium Helps Developers Discover Trending Open Source Repos"
+description: "How ossium makes open source discovery practical: trending repos, language and license filters, project comparison, and tracking, grounded in a real developer workflow."
+type: article
+category: tools
+tags: [ossium, discovery, trending-repos, open-source, filters]
+keywords: [ossium trending repos, discover open source repos, trending open source projects, find self-hosted tools, compare open source projects]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Finding the right open source project is usually a search problem, not a scarcity problem. The repos are all there on GitHub. The difficulty is that the front page of GitHub optimizes for noise. Trending pages reward star velocity, search rewards keywords, and neither rewards the things that matter to someone actually picking a tool: license, maintenance health, language fit. ossium is built around that gap.
+
+Here is what ossium does, in the order you would actually use it.
+
+**Trending repos with context.** The trending section on ossium pulls from GitHub data and presents repos as candidates to evaluate, not just as numbers climbing. You see a project, its stars, its language, and its license in the same view. That context is the point. A repo can be trending and useless for you because it is GPL when you need MIT, or TypeScript when your team is Go. Seeing that before you click saves the classic wasted evening of falling in love with a repo you cannot use.
+
+**Language and license filters.** The two filters do most of the work. Filtering by programming language narrows discovery to what your team can actually maintain and contribute to. Filtering by license settles the commercial question before it becomes a legal one. For a founder in Bangalore evaluating a self-hosted tool, that is the difference between a five-minute search and a three-week adoption. Both workflows are spelled out: [search by language](/how-to-search-open-source-projects-by-programming-language-on-ossium) and [filter by license](/how-to-filter-open-source-projects-by-license-type).
+
+**Project comparison.** Choosing between two candidates is where most decisions stall, because the differences live in a dozen tabs. ossium puts the shortlisted projects side by side, so the comparison is one screen instead of a browser archaeology project. Stars, license, language, activity, the practical facts sit next to each other. This is what turns a list into a decision.
+
+**Tracking.** The final step is follow-up. When you are evaluating a self-hosted CRM for a small team, or an AI library you might build on, the candidate list is not a one-session decision. ossium lets you track repos, so you can check activity over weeks and see whether a project is actually maintained before you commit. That is the information star counts never give you.
+
+A realistic walk through. A developer in Hyderabad is looking for a self-hosted note taking app with encryption. A plain GitHub search returns two hundred repos ranked by stars. On ossium they filter trending by the self-hosted category, exclude copyleft, filter by language, and end up with a shortlist of four. They compare the four side by side, check the maintenance history on each, and track the two finalists for a couple of weeks before choosing. That workflow is the entire reason the tool exists: not to show more repos, but to shrink the list to the ones that fit.
+
+If you are already comfortable with contribution-focused discovery, the [tools for open source contributors](/best-tools-for-open-source-contributors) post covers the adjacent workflow. For the narrower question of how this experience compares to GitHub's own discovery, the [ossium vs GitHub Explore](/ossium-vs-github-explore) writeup has the details.
diff --git a/content/posts/how-to-build-a-community-around-your-open-source-project.md b/content/posts/how-to-build-a-community-around-your-open-source-project.md
new file mode 100644
index 0000000..b03428e
--- /dev/null
+++ b/content/posts/how-to-build-a-community-around-your-open-source-project.md
@@ -0,0 +1,49 @@
+---
+title: "How to Build a Community Around Your Open Source Project"
+description: "Practical steps to build a community around an open source project: documentation, issue hygiene, communication channels, and treating contributors like people."
+type: guide
+category: contribution
+tags: [open-source, community, maintainer, contributors, github]
+keywords: [build open source community, open source community building, attract contributors, maintainer guide, open source project growth]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Community is a byproduct of good systems, not of shouting louder on social media. If your project is well documented and issues are handled properly, people will show up and stay. If it is a pile of code with a README that says "coming soon", no amount of promotion will fix it.
+
+## Documentation is your first community member
+
+The single most effective thing you can do is make the project easy to understand for a stranger. A README that explains what the project does and why it exists, a CONTRIBUTING.md that explains the setup, and a few examples of real usage. When someone lands on your repo and can get started in five minutes, they will come back.
+
+Docs are also the easiest way for new people to contribute. A documentation issue is a low stakes entry point that lets someone fix something, get feedback, and learn the workflow. Projects that starve their docs starve their contributor pipeline.
+
+## Handle issues like they are work, not threats
+
+The way you respond to issues and PRs sets the culture. Acknowledge issues quickly, even with a one line "looks reasonable, will review this week". Ask the clarifying questions early instead of letting a thread rot. When you close something, close it with a reason, not with silence.
+
+The people who open issues and PRs are doing unpaid work for your project. Treat them accordingly. A rude reply gets screenshotted. A patient one gets a repeat contributor.
+
+## Pick one communication channel
+
+You need somewhere people can ask questions that are not formal issues. A GitHub Discussions forum, a Discord server, or a Matrix room all work. What does not work is having four channels with half the conversations duplicated across them.
+
+Start small. A single forum or chat room you actually read is better than a fancy community with a code of conduct and no activity. As you grow, add structure. Do not build the structure first.
+
+## Make the first contribution experience deliberate
+
+New contributors mostly do one of three things: fix a typo, take a good first issue, or implement a small feature they wanted. Make all three easy.
+
+Keep issues small and well scoped. Label the beginner friendly ones. Write a short guide on how to set up the development environment. When a first time contributor opens a PR, review it fast and be specific about what needs to change. A first PR that sits for two weeks teaches the contributor that their time does not matter.
+
+## Be honest about what you can handle
+
+A small community that is well maintained beats a large one that is ignored. You do not need hundreds of active contributors. You need a handful who understand the project and a maintainer who responds.
+
+If you cannot sustain the project, say so. Put a note in the README about how often you can review PRs, or mark the project as seeking maintainers. This is not a failure state. It is honest project management.
+
+## A realistic pace
+
+Community building compounds slowly. You will not see a spike after your launch post, and that is fine. The goal is to have the systems in place so that when the right person finds the project, they stay. That happens one good issue at a time.
diff --git a/content/posts/how-to-build-a-saas-business-on-top-of-open-source.md b/content/posts/how-to-build-a-saas-business-on-top-of-open-source.md
new file mode 100644
index 0000000..3b04f83
--- /dev/null
+++ b/content/posts/how-to-build-a-saas-business-on-top-of-open-source.md
@@ -0,0 +1,48 @@
+---
+title: "How to Build a SaaS Business on Top of Open Source"
+description: "A practical guide to open core and AGPL strategies, what to keep open versus closed, and the licensing and community mistakes that sink open source startups."
+type: guide
+category: tools
+tags: [open source business, open core, agpl, saas, startup, india]
+keywords: [build a saas business on open source, open core business model, agpl license for saas, open source startup india, monetize open source software]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+The pitch writes itself. Build a tool developers want, open the source, charge for hosting. GitLab, WordPress, Sentry, and Supabase all did versions of this, and Appsmith proved the pattern works from India. What nobody tells you is that the line between the free product and the paid product is a legal and community minefield. Most teams get it wrong twice before they get it right.
+
+## Pick a strategy before you write a line of code
+
+Two dominant models exist, and they are not interchangeable.
+
+Open core keeps the base product under a permissive license (MIT or Apache) and sells enterprise features on top. GitLab is the canonical example: the free tier is genuinely useful, the paid tiers add SSO, compliance, and scale features. The risk is that a competitor hosts your open core and charges less, since nothing stops them.
+
+The AGPL route keeps everything open but under a license that triggers on network use. Run a modified AGPL product as a service and you must share your changes. That quietly deters anyone from reselling your software as a closed SaaS. Sentry ran permissive for years, then moved to a source-available license after clouds started selling its own product against it. The catch is that AGPL scares enterprise legal teams, and some of your best customers will say no purely on policy. Whichever route you pick, read the mechanics of these licenses before you commit, the [licensing guide](/how-open-source-licensing-works) covers what actually triggers each one.
+
+## What to keep open, what to keep closed
+
+Keep the developer-facing core open: the thing your users touch, install, and extend. That is your marketing, your distribution, and your talent pipeline. Keep the parts that only matter in a team context closed: SSO, audit logs, compliance packs, advanced monitoring, vertical-specific features. The rule that works in practice: if a hobbyist finds it interesting, open it. If an enterprise pays for it, think twice.
+
+Hosting and managed services are the most natural revenue, because people genuinely do not want to run databases and clusters themselves. Supabase built a real business on "open source Firebase, you host it if you want, or pay us to."
+
+## Licensing pitfalls that actually bite
+
+- Accepting a pull request without a contributor license agreement. The contributor owns their code, and their employer may too. One angry ex-contributor can force a rewrite. Have a CLA from day one.
+- GPL code in a SaaS you want to sell. A permissive core with a single GPL dependency quietly infects your distribution story. Check every dependency's license before you announce anything.
+- Changing the license after users trust you. MongoDB's move to SSPL and Elastic's relicensing worked legally and destroyed a chunk of goodwill. Whatever you choose at the start, assume you are stuck with it.
+- Announcing AGPL as "open source." It is OSI-approved, but many companies treat it as a separate category, so be precise about what your customers get.
+
+## The community pitfalls
+
+Gatekeeping features that the community considers core. Users will fork your project and add the missing feature, and then you have a competitor running your own roadmap. And do not let the open source side starve. Projects that smell like a demo for a paid product stop receiving contributions, and the contribution pipeline is what makes the free distribution channel work.
+
+## The Indian example
+
+Appsmith is the proof. Founded by engineers out of Flipkart, it built an open source low-code platform, kept the core under Apache 2.0, and sold cloud hosting and enterprise features to mid-market companies before anyone in India took the model seriously. A small Bengaluru team can copy the shape: permissive core, hosted product, paid SSO and compliance. The hard part is not the license choice. It is having the patience to grow a community for two years before revenue arrives.
+
+## The honest version
+
+Most open source startups never make enough to pay salaries. The ones that do are the exceptions, and they survive because they decided consciously what to give away and what to sell. Open everything and hosting is your only moat. Close too much and you have a regular SaaS with an awkward GitHub page. Both can work. The teams that fail are the ones that never made the decision at all.
diff --git a/content/posts/how-to-filter-open-source-projects-by-license-type.md b/content/posts/how-to-filter-open-source-projects-by-license-type.md
new file mode 100644
index 0000000..0a36dd2
--- /dev/null
+++ b/content/posts/how-to-filter-open-source-projects-by-license-type.md
@@ -0,0 +1,29 @@
+---
+title: "How to Filter Open Source Projects by License Type"
+description: "How to filter open source projects by license on ossium, why permissive versus copyleft matters for commercial use, and what to check before adopting a project."
+type: howto
+category: tools
+tags: [ossium, licensing, howto, mit, gpl, agpl]
+keywords: [filter open source by license, open source license filter, permissive vs copyleft, mit license projects, gpl vs apache for commercial use]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A license filter is the cheapest legal advice you will ever get. One click on ossium and the GPL projects you can only use under strict conditions disappear, leaving the repos your business can actually build on. Before the click, you need to know what the filter means.
+
+**Why the license is a commercial decision.** Two open source projects can look identical and have opposite terms. Permissive licenses, MIT, BSD, Apache 2.0, let you use the code in closed, commercial products with light obligations: keep the copyright notice, do not claim you wrote it. Copyleft licenses, GPL, AGPL, LGPL, use the license to force you to share source, and the trigger depends on how you use the software. GPL triggers on distribution. AGPL triggers even if you just run it as a service over a network. If your startup sells software or hosts it for clients, that difference is the difference between a legal cost and no cost. The full explainer has the details: [how open source licensing works](/how-open-source-licensing-works).
+
+**Step 1: Set the license filter on ossium.** Open the trending or browse section and apply the license filter before you browse anything. If your product is closed source, filter to permissive licenses only. If you want to see the whole field, leave the filter off, but know what you are looking at. The filter groups projects by license family, so you can go straight to MIT and Apache when your constraint is commercial embeddability.
+
+**Step 2: Read the license for the finalists, not the whole field.** The filter narrows the list. It does not replace reading the LICENSE file of the two or three projects you are actually considering. Filter metadata can be wrong or missing, so the final check is always the LICENSE file in the repository root and the SPDX identifier on the package page. A minute each, before adoption, not after.
+
+**Step 3: Watch the copyleft edge cases.** Three that trip people up. First, AGPL: a self-hosted tool you deploy for a client can trigger the source-sharing obligation even if you never distribute binaries. For Indian agencies hosting tools for customers, this is the surprise license. Second, dependency infection: pull a GPL library into an otherwise MIT project and the combined work may need to ship GPL. Third, no license at all: a repo with no LICENSE gives you no rights under copyright law, treat it as read only. Filtering does not catch these by itself, so checking the dependency tree and the absence of a LICENSE file is part of the same pass.
+
+**An example.** A small Bangalore startup sells a hosted dashboard to Indian retailers. Their constraint is simple: every dependency must allow closed commercial use, and they must be able to deploy instances on client servers without new legal obligations. On ossium they filter trending to permissive licenses, MIT and Apache, and the list immediately excludes the AGPL analytics stack that would have looked perfect otherwise. The license filter did the sorting that a legal review would have done a week later and for a lot more money.
+
+**What to check before adopting.** Four things, in order. The LICENSE file exists and matches the SPDX identifier. The license is compatible with your distribution model. Your dependency tree contains nothing copyleft that you are not prepared to handle. And the project has a license at all, since "no license" is the one case no filter can fix after the fact.
+
+If you want the broader picture of where license fits into picking a project, the [startup selection guide](/how-to-find-the-right-open-source-project-for-your-startup) covers the full checklist.
diff --git a/content/posts/how-to-find-the-right-open-source-project-for-your-startup.md b/content/posts/how-to-find-the-right-open-source-project-for-your-startup.md
new file mode 100644
index 0000000..8c731e0
--- /dev/null
+++ b/content/posts/how-to-find-the-right-open-source-project-for-your-startup.md
@@ -0,0 +1,43 @@
+---
+title: "How to Find the Right Open Source Project for Your Startup"
+description: "A practical process for picking a sustainable open source project for your startup: define the need, check maintenance health, license, community, and docs, then vet before adopting."
+type: guide
+category: tools
+tags: [open-source, startup, licensing, maintenance, self-hosted]
+keywords: [open source project for startup, how to choose open source software, self-hosted crm india, open source license for commercial use, check open source project health]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A startup that adopts the wrong open source project loses the same months a startup that wrote its own software loses, just with extra steps. I have watched a two-person team in Pune pick a self-hosted chat tool that looked perfect, then spend a week fighting a database version pinned four years ago. The fix is not a better tool. It is a better checklist.
+
+## Step 1: Write down the actual need
+
+Before you look at any repo, write one paragraph: what problem this tool must solve, how many people will use it, whether it must be self-hosted, and what your team knows how to maintain. For a small Indian startup, the honest constraint is usually self-hosting, because data stays in-country and the bill stays predictable. That immediately kills a huge share of options and makes the search tractable. A CRM that requires a paid cloud, or a chat tool that phones home, is out before you start.
+
+## Step 2: Check maintenance health, not star count
+
+Stars measure attention. Maintenance measures survival. Open the repository and look at the last commit date, the last release date, and the issue tracker. A project with 20,000 stars and no commit in fourteen months is a museum. Also check the bus factor, how many people actually merge pull requests. A single-maintainer project is not a red flag by itself, but you should know who holds the keys.
+
+## Step 3: Read the license before you love the code
+
+This is the step teams skip, and it is the one that hurts. A permissive license like MIT or Apache lets you embed the software in a closed commercial product. A copyleft license like GPL may force you to share source if you distribute the modified software, and AGPL triggers even when you just run it as a service. If your startup sells software or hosts it for clients, that difference decides whether your business model survives contact with the repo. The full families are explained in [how open source licensing works](/how-open-source-licensing-works). The short version: decide whether the license allows your intended use before you write a single line of integration code.
+
+## Step 4: Look at the community and the docs
+
+Maintenance health from git history tells you the project is alive. The community tells you whether it will stay alive and whether you can get help. Check the response time on issues, whether there is a mailing list, Discord, or forum, and whether questions get answered or ignored. Then open the docs. Not the marketing page, the actual setup docs. If the install page is wrong for the current release, that is a strong signal about how the project treats users.
+
+## Step 5: Vet before adopting
+
+Choose a shortlist, then spend one working day with each candidate. Install it, run it, break it, check the upgrade path. Two practical vetting moves. First, read the changelog for breaking changes and whether the project has a migration path. Second, find the project's stance on security fixes: do they backport patches to old releases, or is every user forced onto the newest version? For a small team, the newest version is often not something you want to be running at 2am.
+
+A working example. A small Indian agency needs a self-hosted CRM for its twelve-person sales team. The constraints: self-hosted, maintainable with the PHP or Python skills in the house, and a permissive license so the client's data and the agency's liability stay clean. That search now has hard filters. Language, license, self-hosted flag, last commit within ninety days. Filtering first saves the entire "nice but wrong" category of project.
+
+## The mistakes people actually make
+
+Three, in order of cost. First, picking a project with no maintainers because it had the most stars and the nicest README. Second, ignoring the license and discovering the copyleft obligation at client delivery time, the single most expensive mistake on this list. Third, trusting star count as a proxy for quality. Stars tell you a project was popular once. They do not tell you it is maintained, documented, or safe to run.
+
+Start with the need, filter hard, read the license, check the pulse of the community, and vet with your hands. Do that and you will adopt fewer projects and keep more of them.
diff --git a/content/posts/how-to-search-open-source-projects-by-programming-language-on-ossium.md b/content/posts/how-to-search-open-source-projects-by-programming-language-on-ossium.md
new file mode 100644
index 0000000..e0fcbf5
--- /dev/null
+++ b/content/posts/how-to-search-open-source-projects-by-programming-language-on-ossium.md
@@ -0,0 +1,35 @@
+---
+title: "How to Search Open Source Projects by Programming Language on Ossium"
+description: "Step-by-step guide to filtering open source projects by programming language on ossium, why it matters for hiring, contribution fit, and maintenance, with a Python example."
+type: howto
+category: tools
+tags: [ossium, howto, programming-language, python, go]
+keywords: [search open source projects by language, ossium language filter, find python open source projects, find go open source projects, ossium how to]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Filtering open source discovery by programming language is the fastest way to cut a 200-repo result down to something real. On ossium it is one dropdown. Here is how the workflow goes.
+
+**Step 1: Open the trending or browse view.** Start on the ossium homepage or the trending section. Set the language filter before you type a single search term. On ossium, trending projects are grouped and filterable by language, so you are looking at Python projects that are actually moving, not Python projects that happen to rank high in a keyword search.
+
+**Step 2: Select your language.** Pick the language from the filter. Two realistic examples. If your team is Python-first, filter to Python and you immediately see the self-hosted tools, AI libraries, and automation projects in that ecosystem. If you are exploring Go, the filter shows you the infrastructure crowd, CLI tools, proxies, and database utilities where Go dominates. The list reorganizes around your stack.
+
+**Step 3: Layer the other filters.** Language is the first filter, not the last. Once you are inside one language, set the license filter to what your use case allows and check activity before you open anything. The combination is what makes the search practical. Python plus AGPL removes the AI libraries you can only use as a research tool. Go plus a permissive license gives you the embeddable infrastructure shortlist. The [license filtering guide](/how-to-filter-open-source-projects-by-license-type) covers that half.
+
+**Step 4: Compare and check before adopting.** The language filter narrowed the field. Now do the real vetting. Put two or three shortlisted repos side by side on ossium, look at license, recent commits, and stars, then open the repositories and read the docs. Nothing about the language filter removes the need to check maintenance. It just removes the need to check maintenance on ninety irrelevant repos.
+
+Why does language filtering matter beyond convenience? Three reasons.
+
+**Hiring and contribution fit.** When you want to contribute to open source, the language determines whether you can actually help. Filtering to a language you know turns a vague browse into a list of projects where your next PR could land. If you are new to this, the [good first issues guide](/what-are-good-first-issues) explains how to find the entry points inside those projects.
+
+**Maintenance familiarity.** A project in a language your team knows can be debugged when things go wrong. A project in an unknown language is a black box with a dependency graph. For a small team, language fit is a maintenance decision, not a preference. A Python self-hosted tool is something a two-person Django shop can keep alive. A Rust tool is not.
+
+**Signal quality.** Languages cluster by domain. Seeing a project's language tells you what it is before you read the README. A Go repo is probably infrastructure. A JavaScript repo is probably web tooling. The filter is a domain filter wearing a language costume.
+
+A full example. A freelancer in Mumbai wants a self-hosted ticketing system to resell to clients. They filter ossium to Python, exclude copyleft licenses, and get a shortlist in one screen. They compare the three candidates, check which one has commits in the last month, and track the two that pass before proposing one to a client. The search that used to take an evening takes fifteen minutes, because every repo in the list already fits the stack and the legal terms.
+
+If you want the broader discovery workflow instead of the filter-specific steps, the [beginner guide](/how-to-find-open-source-projects-for-beginners) covers starting from zero.
diff --git a/content/posts/how-to-start-your-own-open-source-project.md b/content/posts/how-to-start-your-own-open-source-project.md
new file mode 100644
index 0000000..411cbdd
--- /dev/null
+++ b/content/posts/how-to-start-your-own-open-source-project.md
@@ -0,0 +1,51 @@
+---
+title: "How to Start Your Own Open Source Project From Scratch"
+description: "A practical guide to starting an open source project: choosing a license, writing docs, structuring the repo, and avoiding the mistakes that kill a project early."
+type: guide
+category: contribution
+tags: [open-source, github, project-setup, maintainer, beginners]
+keywords: [start open source project, create open source project, open source project setup, github repository setup, open source maintainer guide]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Most open source projects fail for boring reasons: no license, no documentation, and a maintainer who expects people to show up. You can avoid all three without spending much time.
+
+## Pick a license first
+
+The license is the single most important file in your repository. Without one, your code is "all rights reserved" by default, and nobody can legally use it, fork it, or contribute to it in a meaningful way. This sounds bureaucratic, but it is the difference between a project people can adopt and a project people can only look at.
+
+For a new project you want adopted, a permissive license like MIT or Apache 2.0 is usually the right call. If you want derivatives to stay open, use GPL. See the licensing explainer for the details, but do not skip this step.
+
+## Write the README before you announce anything
+
+A good README answers three questions: what does this do, why does it exist, and how do I run it. For a developer audience, that last one is the one they actually check. A project with a five line README and no setup instructions reads as abandoned even if you pushed it yesterday.
+
+Include a clear description, a short usage example, and installation steps. If a new contributor cannot get your project running in ten minutes, they will not contribute.
+
+## Add the contribution scaffolding
+
+Three files turn a repository into a project:
+
+A CONTRIBUTING.md that explains how to set up the environment, run tests, and submit a pull request. If you do not want contributions yet, say so plainly in this file rather than leaving people to guess.
+
+A LICENSE file, which you already handled.
+
+Issue templates and a pull request template. These sound like admin work, but they save you time later by forcing people to give you the information you need.
+
+## Decide on hosting
+
+GitHub is the default because that is where the audience is. GitLab and Codeberg are fine alternatives if you prefer their policies, but you lose a little discoverability. Pick one and stop thinking about it. Moving later is a solved problem with `git remote` and mirrors.
+
+## Put it on a roadmap, not in a heap
+
+One common mistake is dumping a large codebase with no context and expecting people to orient themselves. If you are extracting a library or tool from a bigger project, write a short "why this exists" section in the README and add a basic architecture note. The people who contribute in the first month are the ones who could understand what they were looking at.
+
+## Realistic expectations
+
+Your project will probably have very few users at first, and that is normal. A small project with a responsive maintainer is more attractive to contributors than a large one with a silent owner. Answer questions within a day or two, merge reasonable PRs quickly, and cut a version tag early so people can see the project is being maintained.
+
+If you started a project that only you use, that is still a useful outcome. Plenty of good software begins as a personal tool that someone else happens to find. The infrastructure you build now, the license, the docs, the templates, is what makes that possible when it happens.
diff --git a/content/posts/is-open-source-software-free-forever.md b/content/posts/is-open-source-software-free-forever.md
new file mode 100644
index 0000000..99f7e17
--- /dev/null
+++ b/content/posts/is-open-source-software-free-forever.md
@@ -0,0 +1,28 @@
+---
+title: "Is Open Source Software Free Forever?"
+description: "Is open source software free forever? Licenses cannot be revoked retroactively, but projects can change licensing for future versions. What 'free' actually means and when it ends."
+type: question
+category: beginners
+tags: [open source, free software, licensing, business source license]
+keywords: [is open source software free forever, open source license changes, redis license change, elasticsearch license change, open core vs open source, open source relicensing]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+answerSummary: "The freedom and price of a released version cannot be revoked, but projects can change licensing or go open-core for future versions, so 'free forever' only applies to versions already published."
+---
+
+"Free forever" has two meanings and you need to separate them before this question makes sense. Free as in price and free as in freedom. Both are decided by the license, and the license is what determines how long "forever" actually lasts.
+
+Take price first. Open source software costs nothing to download and use, and once a version is released under an open source license, that license is effectively irrevocable. MIT, Apache, GPL, they all grant permanent rights for the code as published. If you are running version 2.1 of a library, no future decision by the company that built it can take that version away from you. You have the code, the license covers it, and no one is coming to delete it. That part really is forever.
+
+What can change is everything published after that version. Companies exercise this right regularly. Elastic moved Elasticsearch from Apache 2.0 to a source-available license in 2021, mainly so large cloud providers could not resell it as a service. Redis did something similar in 2024, leaving BSD for a dual license that restricts how cloud vendors can offer it. HashiCorp changed Terraform from MPL to the Business Source License in 2023, and the community forked the last open version into OpenTofu. In every one of these cases the old releases stayed usable under their original terms. Nobody lost code they already had. What people lost was the ability to get new features under the old license.
+
+The "open core" model softens this further. GitLab, Supabase, Mattermost, and plenty of Indian startups publish a genuinely free core and sell premium features around it. The core stays free indefinitely, but the product as a whole does not. That is not a bait and switch, it is the business model, and it works because the free core is genuinely useful on its own.
+
+The second meaning, free as in freedom, comes from the Free Software Foundation. Freedom means the right to study, modify, and redistribute the software. That freedom is also permanent for the version you hold, but it only covers what the author actually released. You cannot redistribute a future version under terms the author never granted you, and you cannot expect a relicensed future version to honor the old license.
+
+Where most people get burned is hosted services, not licenses. A SaaS product built on open source software is not free forever for you, the customer. The underlying code's license may be permanent, but your access to the hosted instance depends on the vendor's pricing and terms. If a company doubles its subscription price, the open source license does not protect you. Your protection is that you can self-host the open source version instead. That is exactly what many Indian startups do when a cloud vendor's pricing turns hostile; they take the open source code, deploy it on their own servers, and keep paying only for infrastructure.
+
+So the honest answer: free forever is guaranteed for the code you already have, not for future versions and not for hosted services. Treat an open source dependency as a permanent asset and treat the vendor's roadmap as a forecast. If you are building on software whose license could change, you can hedge by pinning a version you are happy with, contributing to the project so you have some leverage, or simply being ready to fork. For a deeper breakdown of what each license allows, see [our licensing explainer](/how-open-source-licensing-works).
diff --git a/content/posts/is-open-source-software-safe-to-use.md b/content/posts/is-open-source-software-safe-to-use.md
new file mode 100644
index 0000000..efdbff4
--- /dev/null
+++ b/content/posts/is-open-source-software-safe-to-use.md
@@ -0,0 +1,34 @@
+---
+title: "Is Open Source Software Safe to Use?"
+description: "Is open source software safe to use? The honest answer with a practical checklist: maintenance, releases, security history, and dependency hygiene matter more than the label."
+type: question
+category: beginners
+tags: [open source safety, open source security, supply chain, beginners]
+keywords: [is open source software safe, open source security, open source supply chain, open source vulnerabilities, is open source safe for business]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+answerSummary: "Open source is generally safe if the project is actively maintained and you vet dependencies; visibility helps but most projects are not deeply audited, so supply chain hygiene still matters."
+---
+
+Short answer: yes, in most cases, if you check a few things first. Open source is not automatically safer than proprietary software, and it is not automatically less safe either. What you get with open source is the ability to see the code, and whether that makes you safer depends on what you do with it.
+
+The transparency argument is real. When the source is public, anyone can audit it, and popular projects get a steady stream of review from security researchers and curious developers. That is why core infrastructure like OpenSSL, curl, and the Linux kernel is open source; the code is examined by more people than any proprietary team could afford to hire. It has caught real problems over the years.
+
+But visibility is not the same as an audit, and this is where people get the idea wrong. Most open source projects are not deeply audited. A small library with a few thousand downloads might be maintained by one or two people who review the code themselves. The Heartbleed bug lived in OpenSSL's public source for two years before someone found it, and OpenSSL is about as scrutinized as open source gets. Public code can still have vulnerabilities, because having many eyeballs on a project does not mean those eyeballs are looking.
+
+The bigger risk today is the supply chain. When you install a package, you are not trusting one project, you are trusting that project plus every dependency it pulls in. Malicious actors publish typosquatted packages on npm and PyPI that mirror a real package's name and steal credentials or mine crypto on install. Compromised maintainer accounts have pushed backdoored versions of popular packages like event-stream and ua-parser-js, and the damage propagated to thousands of downstream projects. The bad code did not come from the open source model, it came from the dependency chain, and that applies to proprietary ecosystems too.
+
+So the useful question is not "is open source safe" but "is this specific project, with this dependency tree, safe enough for what I am building." A quick checklist covers most of it:
+
+- Is it maintained? Look at the last release, not the last commit. A project with a stale release and an unaddressed security issue in its tracker is a signal.
+- Does it have a security history? Check the project's advisories and CVEs. Projects that disclose and fix fast are a better bet than projects with no process at all.
+- What does the dependency tree look like? Pin versions, use lockfiles, and let a tool like Dependabot or Renovate nag you about outdated packages.
+- Who runs it? A single maintainer is a bus factor of one. Popular projects with multiple maintainers or a foundation behind them are steadier.
+- For anything critical, prefer widely used code. Battle-tested beats clever in security.
+
+Consider a small company in Bengaluru picking a reporting library for a client dashboard. The team can choose between a polished library with a huge download count, regular releases, and a visible CVE history handled quickly, and a newer one with the exact feature they want but one maintainer and no releases in eight months. The first is the safe choice, not because it is open source, but because the signals say it is looked after. The second might be fine for a weekend project; it is a gamble for production.
+
+None of this is unique to open source. Proprietary software has had its share of supply chain attacks and unmaintained internal code. The difference is that open source lets you check before you trust, and that is a genuine advantage if you actually use it. The mistake is treating the label as the audit. It is not. A couple of minutes of checking beats a production incident.
diff --git a/content/posts/open-source-ai-projects-to-watch-2026.md b/content/posts/open-source-ai-projects-to-watch-2026.md
new file mode 100644
index 0000000..0e47ded
--- /dev/null
+++ b/content/posts/open-source-ai-projects-to-watch-2026.md
@@ -0,0 +1,45 @@
+---
+title: "Open Source AI Projects to Watch in 2026"
+description: "A practical rundown of open source AI projects worth watching in 2026: inference engines, frameworks, open weights models, and AI developer tooling."
+type: article
+category: tools
+tags: [open source ai 2026, inference engines, llm frameworks, open weights, ai developer tools]
+keywords: [open source ai projects 2026, open source llm inference, vllm ollama llama.cpp, llm frameworks, open weights models 2026]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+You do not need to know every AI project, just the ones that everything else is built on. This list covers the open source projects worth actually watching in 2026, split into inference engines, frameworks, models, and developer tooling. No benchmarks here, because published numbers change faster than the blog posts reporting them. Judge everything with your own hardware.
+
+## Inference engines
+
+Inference engines are the software that actually runs the model. [VLLM](https://github.com/vllm-project/vllm) is the production workhorse. It is built for throughput, with continuous batching, paged attention, and quantization support, and it is the engine inside many self-hosted serving stacks. Watch for: new kernels for consumer GPUs and better support for small-model serving.
+
+[Ollama](https://github.com/ollama/ollama) is the opposite end of the spectrum, and that is its strength. It trades raw throughput for simplicity: one command pulls a model and runs it. For a developer on a laptop, it is the fastest way to get something working. Watch for: its plugin and tool-calling support, which has been getting better steadily.
+
+[llama.cpp](https://github.com/ggml-org/llama.cpp) deserves its own mention because it is the substrate under a surprising amount of the ecosystem. It runs on plain CPUs, which is why Raspberry Pi demos keep working, and it powers Ollama, the [Open WebUI](https://github.com/open-webui/open-webui) front end, and countless integrations. [TGI](https://github.com/huggingface/text-generation-inference) (Text Generation Inference) from Hugging Face is the one to pick when you are already inside their ecosystem and want optimized serving for Transformers models.
+
+## Frameworks
+
+On the framework side, the hierarchy is stable and boring, which is a compliment. [PyTorch](https://github.com/pytorch/pytorch) is the default for research and for most training. [JAX](https://github.com/jax-ml/jax) stays relevant where you need fast numerics and TPU-style scaling, and [Hugging Face Transformers](https://github.com/huggingface/transformers) is still the lowest-friction way to load a model and talk to it. Watch for: PyTorch's moves to simplify serving, and Transformers staying compatible with the fast-growing set of open weights.
+
+For orchestration, [LangChain](https://github.com/langchain-ai/langchain) and [LlamaIndex](https://github.com/run-llama/llama_index) are the two names people actually use, and their 2026 iteration is mostly about agent workflows rather than chained prompts. Neither is mandatory. Plenty of production systems are plain Python around a vLLM endpoint, and for the core concepts behind all of this, [the 20 most important AI concepts](/20-most-important-ai-concepts-explained-in-just-20-minute) is a better starting point than any framework tutorial.
+
+## Local models and open weights
+
+The models worth watching are the small ones that run on your machine. The Qwen family has stayed ahead of the curve for size-to-quality, DeepSeek keeps pushing reasoning models as open weights, and Meta keeps shipping iterated Llama versions. [OLMo](https://github.com/allenai/OLMo) is the outlier that matters: the Allen Institute publishes training data and recipes alongside the weights, which makes it genuinely open in a way the others are not.
+
+One accuracy point that keeps getting skipped: these are almost all open weights, not open source in the OSI sense. The weights are free to download and run, but training data and training code stay closed, and the licenses carry usage restrictions. That distinction affects what you can legally redistribute and audit. See [how open source licensing works](/how-open-source-licensing-works) for the details, and [the free AI models post](/open-source-llms-in-2026-the-free-ai-models-everyone-will-be-using-while-you-re-still-overpaying) for the practical side of running them.
+
+## AI developer tooling
+
+The tooling layer is where most working developers actually touch AI. [Aider](https://github.com/Aider-AI/aider) remains the reference for terminal pair programming: it edits files and commits changes in small diffs, and it works with local models. [Cline](https://github.com/cline/cline) brings agents into the IDE with explicit tool permissions, [Continue](https://github.com/continuedev/continue) is the leading open autocomplete-and-chat extension, and [OpenHands](https://github.com/All-Hands-AI/OpenHands) targets longer autonomous tasks. If your focus is coding specifically, [the best local LLM for coding](/what-is-the-best-local-llm-for-coding-in-2026) post goes deeper.
+
+For running all of this on a Mac, [MLX](https://github.com/ml-explore/mlx) from Apple is worth watching, and for self-hosted model serving the [LocalAI](https://github.com/mudler/LocalAI) project keeps offering an OpenAI-compatible API over local inference.
+
+## How to follow this space
+
+The honest advice is to pick one project from each category and actually run it. Watch its release notes, not its star count. Engines and frameworks have their hype cycles, but the ones on this list have been here for a while and will still be here next quarter, which is exactly why they are the ones worth your time.
diff --git a/content/posts/open-source-business-models-explained.md b/content/posts/open-source-business-models-explained.md
new file mode 100644
index 0000000..a277570
--- /dev/null
+++ b/content/posts/open-source-business-models-explained.md
@@ -0,0 +1,60 @@
+---
+title: "Open Source Business Models Explained (Open Core, Dual Licensing, and More)"
+description: "How open source companies actually make money: open core, dual licensing, hosting, support, marketplaces, and donations, with real examples and the AGPL and SSPL controversies."
+type: article
+category: tools
+tags: [open source business models, open core, dual licensing, sspl, agpl, monetization]
+keywords: [open source business model, how open source companies make money, open core vs dual licensing, elastic license controversy, sspl license, mongodb license change]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+People assume open source companies survive on donations. Red Hat would disagree, it was clearing a billion dollars a year in subscription revenue long before IBM bought it. The actual models are few, and mostly boring.
+
+| Model | How it makes money | Example |
+|---|---|---|
+| Open core | Free core, paid enterprise features | GitLab |
+| Dual licensing | Same code, two different licenses | MySQL |
+| SaaS / hosting | Run the software for you | WordPress.com, Canonical |
+| Support and consulting | Sell the expertise, not the code | Red Hat |
+| Marketplace | Cut of app, theme, and service sales | WordPress |
+| Donation / foundation | Grants, sponsors, membership | curl, Linux Foundation |
+
+## Open core
+
+The base product is free and permissively licensed. Revenue comes from features that matter only to larger teams: SSO, audit logs, compliance, scaling. GitLab sells the free tier to developers and GitLab Ultimate to the CTO who needs governance. The model is simple, and the weakness is obvious too: any competitor can host your free tier and undercut you, which is why several open core companies have moved to source-available licenses over time.
+
+## Dual licensing
+
+Same codebase, two legal paths. A GPL version for anyone willing to share their changes, and a paid commercial license for companies that must keep their code proprietary. MySQL built its business this way, and it is why so many early web companies run MySQL. The catch is that the "free" side competes with the "paid" side, so the company has to be disciplined about which features stay in the GPL version.
+
+## SaaS and hosting
+
+People will pay to not operate software. WordPress.com runs the same GPL WordPress you can download, but Automattic charges for hosting, domains, and support. Canonical does the same with Ubuntu. This is the cleanest model for permissively licensed projects, because there is no license gymnastics, just a better service than doing it yourself.
+
+## Support and consulting
+
+Red Hat's classic model: the software is free, the certified, patched, supported version is the product. Enterprises pay for someone to answer the phone at 2 AM. The same logic powers most consulting firms that build on open source. It scales with people, not code, so margins are thinner, but the floor is reliable.
+
+## Marketplace
+
+When the project is a platform, the ecosystem becomes the product. WordPress plugins, themes, and managed hosting generate a cut for the platform owner. Automattic runs both sides of this: the open core and the marketplace around it.
+
+## Donations and foundations
+
+curl, the tool every developer on earth has used, runs on sponsors and grants, with its lead maintainer effectively funded by the community. Bigger projects shelter under foundations like the Linux Foundation or Apache, which take corporate membership money and pay for infrastructure and legal protection. This works when the software is ubiquitous and nobody has a reason to compete with it.
+
+## The licensing controversies, accurately
+
+Two license wars shaped the current map. MongoDB wrote the Server Side Public License (SSPL) in 2018 and moved from AGPL to it. The SSPL starts from AGPL's copyleft but goes further: if you offer the software as a service, you must release not just your modifications but the entire stack you use to run it, including management, authentication, and UI. The OSI rejected it as not open source, so MongoDB's code is commonly called source-available instead.
+
+Elastic did something similar in 2021, relicensing Elasticsearch and Kibana from Apache 2.0 to a mix of the Elastic License and SSPL, after Amazon started selling a managed Elasticsearch. The licenses were designed to stop clouds from reselling the products. They worked, and they also removed those projects from the strict open source definition.
+
+AGPL itself is different and OSI-approved. It extends GPL copyleft to network use, so running modified AGPL code as a service means sharing your changes, without the SSPL's demand to release the surrounding infrastructure. The practical difference matters if you are choosing a license for a [SaaS business](/how-open-source-licensing-works).
+
+## The pattern underneath
+
+Every model has the same shape: the code is the marketing, and something around it is the product. Sometimes that something is features, sometimes it is a license, sometimes it is operations. None of them work if the software is not genuinely good, because open source companies compete against free, which is a brutal bar.
diff --git a/content/posts/open-source-maintainer-burnout.md b/content/posts/open-source-maintainer-burnout.md
new file mode 100644
index 0000000..20e54af
--- /dev/null
+++ b/content/posts/open-source-maintainer-burnout.md
@@ -0,0 +1,49 @@
+---
+title: "Open Source Maintainer Burnout: How to Avoid It"
+description: "Why open source maintainers burn out, the warning signs, and practical ways to protect your time without abandoning your project."
+type: article
+category: contribution
+tags: [open-source, maintainer, burnout, mental-health, community]
+keywords: [open source maintainer burnout, maintainer burnout, open source mental health, project maintenance, avoid burnout]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Maintainer burnout is not a personality flaw. It is the predictable result of a project getting popular faster than the person running it can adapt. One person ends up triaging issues, reviewing PRs, fixing releases, and fielding support questions, all in the evenings after their real job. That schedule does not hold.
+
+The research on this is consistent. The number one reason maintainers quit is not technical difficulty. It is the emotional weight of being the default human answer point for strangers who are often rude, entitled, or both.
+
+## The warning signs
+
+Burnout rarely arrives suddenly. Watch for these patterns.
+
+You feel dread opening your notification inbox. This is the big one. If the sight of a new issue makes your stomach drop, you have a process problem, not a volume problem.
+
+You start answering the same questions again and again. When every new user asks the same three setup questions, your docs have failed you, and you are paying the price in time.
+
+You put off reviewing PRs for weeks. That backlog grows and makes everything worse, because each stale PR adds guilt and pressure.
+
+You treat maintainership as an obligation you cannot escape. The project is yours, you think, so you owe it to everyone. You do not.
+
+## What actually helps
+
+Automate the boring parts. Use issue templates so bug reports come with the version, steps to reproduce, and expected behavior. Set up CI so you are not manually checking PRs. Add stale bot rules so old issues get closed instead of rotting silently. None of this is glamorous, but each piece removes a source of drip-drip drain.
+
+Write down your boundaries. A short section in your CONTRIBUTING.md that says "I respond to issues within a week" sets expectations. You can also state the obvious: "this is a side project, not a customer support service." Users cannot be annoyed at you for a policy you wrote down clearly.
+
+Batch your work. Answer issues twice a week instead of every time a notification pings. Review PRs in one sitting. The interruption cost of checking notifications constantly is often worse than the work itself.
+
+## Learn to say no
+
+You are allowed to close issues you do not want to handle. You are allowed to reject a PR that does not match the project's direction. You are allowed to refuse the feature request that would take a month of your time for a use case one person mentioned.
+
+Saying "no, but here is how you could build it yourself" is a perfectly good outcome. The project belongs to you, and the only person who has to be satisfied with its scope is you.
+
+## The graceful exit
+
+If you genuinely cannot sustain the project anymore, you have better options than letting it rot. Ask a trusted contributor to take over. Archive the repository and say it plainly, so people stop opening issues against it. Transfer it to an organization or a foundation if that fits. Or just mark it unmaintained and let someone fork it.
+
+Walking away is not a failure. The code you wrote is still there. The people who learned from it got value from it. Burning out and hating the thing you built is a worse outcome than closing it cleanly and moving on.
diff --git a/content/posts/open-source-software-for-startups.md b/content/posts/open-source-software-for-startups.md
new file mode 100644
index 0000000..5fb14d6
--- /dev/null
+++ b/content/posts/open-source-software-for-startups.md
@@ -0,0 +1,39 @@
+---
+title: "Open Source Software for Startups: Tools That Save You Money"
+description: "Where a startup can safely adopt open source: CRM, analytics, project management, databases, and chat. Includes the real costs of self-hosting: hosting, maintenance, patching, and staff time."
+type: guide
+category: tools
+tags: [startup, self-hosted, opensource-tools, cost-saving, devops]
+keywords: [open source software for startups, self hosted tools for startups, open source crm, cost saving open source, self hosted cost vs saas]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A Bangalore startup with ten people can run almost its entire internal stack on open source software and cut its software bill by a lot. I say "almost" and "a lot" deliberately, because open source is not free the way people imagine. The license is free. The hosting, patching, and the hours your engineers spend babysitting the stack are not. Let me be concrete about where it saves money and where it quietly costs it.
+
+Start with the obvious wins.
+
+CRM. Odoo Community Edition covers CRM, inventory, invoicing, and accounting in one package. ERPNext is fully open source and popular with Indian SMEs precisely because it handles GST, Tally-style accounting, and inventory out of the box. If you only need basic contact and deal tracking, EspoCRM is lighter and easier to run. Odoo CE is the crowd favourite, but be careful: several features sit behind Odoo Enterprise, so check what you actually need before committing.
+
+Analytics. Matomo is a full Google Analytics replacement you self-host, which keeps visitor data on your own server and out of third-party ad networks. Plausible is the lightweight alternative; its whole selling point is privacy and simplicity. For a startup that cares about consent and India's data protection rules, both solve a problem Google Analytics creates: data leaving your control.
+
+Project management. Plane is the modern open source option, issue tracking and project planning with a clean UI that feels like Linear without the subscription. If your team hates Jira, Plane is a genuine refresh.
+
+Database. PostgreSQL covers nearly every startup use case. Hosted versions like Supabase and Neon remove the ops burden entirely, and self-hosted Postgres is a known quantity. Unless you have a real reason to reach for something else, Postgres is the default.
+
+Communication. Mattermost is the Slack-shaped open source tool you can self-host. For internal chat among ten people, a small Mattermost server on a ₹2,000 a month VPS handles it comfortably. Zulip is the thread-first alternative if your team prefers long-form discussion over a scrolling feed.
+
+Now the honest part: the costs that "free" hides.
+
+Hosting. Every self-hosted service needs a server. Ten tools mean either ten tiny VPSes or one bigger one with containers. A reasonable all-in budget in India is ₹5,000 to ₹15,000 a month for a production-grade setup with backups, depending on how much redundancy you want. That is still far below per-seat SaaS fees, but it is not zero.
+
+Maintenance and security patching. This is the cost nobody budgets for. Someone must update the software when security patches drop. For Mattermost or PostgreSQL that means a monthly habit. For a full ERP like Odoo or ERPNext, upgrades can be genuinely painful: minor versions are fine, major upgrades sometimes break custom modules. If a system holds customer data, patching is not optional, it is compliance.
+
+Staff time. The real price of self-hosting is developer hours. Every hour your one infrastructure person spends on the mail server is an hour not building the product. For a ten-person startup that matters. The rough rule: self-host tools that are boring and stable, databases, internal chat, analytics, and consider hosted versions of things that are complex to run, like a full CRM or ERP. Plausible and Mattermost have paid hosted plans; Odoo has a cloud edition. Using those converts an ops cost into a subscription, and sometimes that trade is worth it.
+
+A concrete example. Say the team needs CRM, analytics, chat, project tracking, and a database. The SaaS bill would be roughly a CRM at ₹3,000 per user a month, Slack at ₹850 per user a month, Jira around the same, plus a hosted database. Total lands around ₹50,000 to ₹70,000 a month. The open source stack, ERPNext or Odoo on a VPS, Matomo, Mattermost, Plane, and Postgres, runs at maybe ₹8,000 to ₹12,000 a month in servers plus half a day a month of one engineer's time for patching and backups. The saving is real, around 80 percent in direct spend. The trade is the ops responsibility, and it is a good trade only if someone on the team is willing to own infrastructure.
+
+The decision rule is simple. Adopt open source where the tool is stable and boring. Avoid it where the tool is complex and central to your product, unless you have a person who enjoys running it. And read the license before you adopt: several projects with open source cores have proprietary edges, which matters if you plan to offer the tool as part of a paid product. My guide to how open source licensing works covers which licenses allow commercial use, the note most "open source saves you money" articles leave out.
diff --git a/content/posts/open-source-vs-free-software-vs-freeware.md b/content/posts/open-source-vs-free-software-vs-freeware.md
new file mode 100644
index 0000000..3c20cf1
--- /dev/null
+++ b/content/posts/open-source-vs-free-software-vs-freeware.md
@@ -0,0 +1,35 @@
+---
+title: "Open Source vs Free Software vs Freeware: What's the Difference?"
+description: "The precise difference between open source, free software, and freeware. Freeware is the one people confuse most: free to install does not mean the code is open."
+type: article
+category: beginners
+tags: [open-source, free-software, freeware, licensing]
+keywords: [open source vs free software, freeware meaning, free software vs freeware, open source license types, what is freeware]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Three terms, three different ideas, and most people use them interchangeably. Open source, free software, and freeware all describe software you can get without paying, but they sit in different categories with different legal and philosophical baggage. Here is the clean version.
+
+Freeware is the easy one, and the one people most often confuse with open source. Freeware is proprietary software distributed at no cost. The company keeps the source code private, and you get a license to use the program, usually with restrictions. You cannot see how it works, you cannot modify it, and you cannot redistribute your copy. Google Chrome, WhatsApp, and Zoom are freeware. Free to download, closed code. Freeware is free like a free sample, a marketing decision, not a commitment to openness.
+
+Free software is a movement, not just a licensing category. Richard Stallman defined it in the 1980s and the Free Software Foundation maintains it. The "free" means freedom, not price. Stallman's four freedoms: run the program for any purpose, study and modify the source, redistribute copies, and distribute your modified versions. Software counts as free software if its license grants all four. The point is political: free software exists so users control their computers instead of being controlled by vendors.
+
+Open source is the term a group of people who disliked the political framing came up with. In 1998, Eric Raymond, Bruce Perens, and others took the same body of software and rebranded it around practical and technical benefits, the idea that a visible development process produces better, more reliable code. The Open Source Definition, based on the Debian Free Software Guidelines, lists the criteria: free redistribution, source code available, modifications allowed, no discrimination against people or fields of endeavor, and licenses that do not restrict other software.
+
+The important part: free software and open source describe almost exactly the same set of programs. The GPL, MIT, and Apache licenses all satisfy both definitions. The difference is why people use the terms, not which software they point at. Stallman and the FSF say "free software" and mean a moral position about user rights. The open source movement says "open source" and means an engineering method. Every free software license is also open source, and nearly every open source license is also free software. The disagreements happen at the edges.
+
+Freeware is the odd one out. It is closed source, so it can never be free software or open source. A freeware program can change status later if the company releases its source, but while it ships as freeware, it is proprietary. This is the mistake that keeps happening: a free app is not an open source app. Freeware means priced at zero and nothing more.
+
+A comparison:
+
+| Term | What it guarantees | Example |
+|---|---|---|
+| Open source | Source code is public; a license lets you use, modify, and redistribute it | PostgreSQL, React, Linux |
+| Free software | The same four freedoms, framed as a user-rights movement | GNU utilities, GPL programs |
+| Freeware | Nothing beyond a free price; source stays closed | WhatsApp, Chrome, Zoom |
+
+Apply two questions to any tool. Can I see the source code? Can I modify and redistribute it? Yes to both means open source and almost certainly free software. No to both, but it costs nothing, means freeware. The difference matters when you build: only open source code is legally reusable, and only under its license terms. Freeware gives you nothing to reuse. My guide to how open source licensing works walks through the licenses themselves and what each one allows.
diff --git a/content/posts/open-source-vs-proprietary-software.md b/content/posts/open-source-vs-proprietary-software.md
new file mode 100644
index 0000000..cc8601e
--- /dev/null
+++ b/content/posts/open-source-vs-proprietary-software.md
@@ -0,0 +1,41 @@
+---
+title: "Open Source vs Proprietary Software: Pros and Cons for Businesses"
+description: "A balanced comparison of open source and proprietary software for businesses: cost, control, security, support, and lock-in, with practical guidance on when to pick which."
+type: guide
+category: career
+tags: [open-source, proprietary, business, software-decision, enterprise]
+keywords: [open source vs proprietary software, open source software pros and cons, open source for business, proprietary software, software procurement]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+The "open source is free, proprietary is expensive" framing is wrong, and it has cost a lot of companies real money. Both models have genuine strengths, and the right choice depends on what your business actually needs to do.
+
+## The case for open source
+
+Control is the strongest argument. With open source you can read the code, fix bugs yourself, fork it when the vendor goes in a direction you dislike, and never worry about the product disappearing or the price changing under you. For a business that treats software as part of its core operations, that control is worth a lot.
+
+Cost is real but often misunderstood. There is no license fee, and that is a genuine advantage at scale. But you pay with engineering time instead. Someone has to deploy it, patch it, and fix it when it breaks. A small team can absorb that. A team with no ops people cannot.
+
+Security cuts both ways. The code is visible, which means it can be audited by the community, but it also means attackers can read it. In practice, widely used open source projects are reasonably well vetted because many eyes do look at the code. Niche projects are a different story.
+
+## The case for proprietary
+
+Support is the cleanest argument. When the software breaks, you call someone whose job it is to fix it. You get a contract, an SLA, and a phone number. For businesses where downtime is expensive, that certainty has a price tag, and people pay it happily.
+
+Accountability works in your favor. A vendor with a commercial interest in keeping your account wants you to succeed. You have recourse if things go wrong, which you do not have with a community project that owes you nothing.
+
+The total cost is often easier to predict. A license fee plus a support contract is a known number. Open source is a cost you estimate, and estimates about engineering time are rarely accurate.
+
+## Where the Indian context changes the math
+
+In India, a few things tip the scales. Foreign proprietary licenses are priced in dollars, and currency moves alone can break a budget. Compliance and data residency rules, like the DPDP Act, make self-hosting more attractive for sensitive data, which favors open source. At the same time, reliable in-house engineering talent is scarce at the price small companies want to pay, which makes the support argument stronger than it looks.
+
+There is no universal answer, but the rule of thumb is workable: if the software is peripheral to your business, buy proprietary and move on. If it is central, you want control, and open source starts to make sense even when it costs you more in people.
+
+## The middle path people ignore
+
+Hybrid setups are common and usually the smartest route. Run open source where you have the skills and the stakes justify it, and buy proprietary where you do not. A company can happily run PostgreSQL open source while paying for a proprietary analytics tool. Nobody is forcing you to pick one model for everything.
diff --git a/content/posts/ossium-features-explained.md b/content/posts/ossium-features-explained.md
new file mode 100644
index 0000000..29447f7
--- /dev/null
+++ b/content/posts/ossium-features-explained.md
@@ -0,0 +1,25 @@
+---
+title: "Ossium Features Explained: Discover, Compare, and Track OSS Projects"
+description: "A plain walkthrough of ossium's three features: discovering trending open source repos, comparing projects side by side, and tracking them over time."
+type: howto
+category: tools
+tags: [ossium, features, discover, compare, track]
+keywords: [ossium features, discover open source projects, compare open source projects, track open source projects, ossium trending]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+ossium does three things, and everything on the site hangs off those three. Discover repos worth looking at, compare the shortlisted ones, track the survivors. Each step exists because the one before it leaks time and attention. This is what each pillar actually does.
+
+**Discover.** The discovery layer is the front door. ossium pulls GitHub data and presents trending repos in a form you can actually act on. The two filters matter more than the list itself. Programming language filters to what your team can maintain and contribute to. License filters to what your business can legally use. If you have ever spent an evening falling in love with a trending repo and then realized it is GPL or Swift when you needed MIT and Go, you know what these filters save you. Discovery on ossium is not about showing more repos. It is about shrinking the field to the ones that fit before you open a single repository page.
+
+**Compare.** Discovery produces a shortlist, and a shortlist is where decisions go to stall. The details that separate two candidates, license, language, stars, recent activity, live across a dozen browser tabs. The compare view puts them side by side on one screen, so the differences are visible instead of reconstructed from memory. This is the step that turns browsing into choosing. Two self-hosted tools with similar feature lists stop being interchangeable once you can see that one has commits this month and the other has an issue queue nobody has touched since January.
+
+**Track.** The last pillar exists because picking a project is not a single-session decision, especially for teams adopting something they will run in production. Tracking lets you keep an eye on repos over weeks. You check whether the maintainer answered the open issues, whether releases are still coming, whether the project is alive in the sense that matters: still being worked on. That is the information star counts are structurally unable to give you, because stars measure the past and the present, not the direction.
+
+An example that ties the three together. A developer in Chennai wants a self-hosted file sync tool. They filter discovery to a language they know and a permissive license, and the field drops to a handful of candidates. They compare the top three side by side, and two survive. They track those two for a fortnight, watching commits and issue responses. Only then do they install one and start actually using it. Discover, compare, track, in that order, and the whole arc took a few sessions instead of one rushed evening.
+
+The three pillars map to the way anyone sane evaluates software: get a list, narrow it, then watch before committing. ossium just puts all three steps in one place. If you want the deeper workflow on the discovery step specifically, the [language filtering guide](/how-to-search-open-source-projects-by-programming-language-on-ossium) and the [license filtering guide](/how-to-filter-open-source-projects-by-license-type) cover the details. And if you are weighing ossium against GitHub's own discovery, the [comparison post](/ossium-vs-github-explore) is the neutral version of that discussion.
diff --git a/content/posts/ossium-vs-product-hunt.md b/content/posts/ossium-vs-product-hunt.md
new file mode 100644
index 0000000..e293b0b
--- /dev/null
+++ b/content/posts/ossium-vs-product-hunt.md
@@ -0,0 +1,43 @@
+---
+title: "Ossium vs Product Hunt: Where Should You Launch Your Open Source Project?"
+description: "A practical comparison of launching an open source project on Product Hunt versus Ossium: audience, traffic patterns, and what each platform is actually good for."
+type: article
+category: tools
+tags: [ossium, product-hunt, open-source, launch, discovery]
+keywords: [ossium vs product hunt, launch open source project, where to launch open source, open source project launch, product hunt for developers]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Every new open source project faces the same question a week after the initial push: where do I tell people about this? Product Hunt and Ossium are the two answers people throw around, and they solve different problems.
+
+## Product Hunt is a crowd, not a community
+
+Product Hunt is built around launch day. You get a page, you get upvotes, and if you hit the front page you get a spike of traffic that can be dramatic. For a developer tool, that spike is mostly tourists. You will get a lot of "cool, starred it" and very few people who actually install and use your thing.
+
+The Product Hunt audience skews toward product enthusiasts, founders, and marketers. They are great at telling you whether your landing page makes sense. They are not great at testing your code or filing useful bug reports. The traffic is real but shallow, and it fades fast. A Product Hunt launch is a burst of attention you need to catch and convert in a day.
+
+## Ossium is built for sustained developer discovery
+
+Ossium is a directory and tracking tool for open source projects. The people browsing it are developers looking for software to use, compare, and follow. You do not get a launch day spike, but the audience is the right one.
+
+When someone finds your project on Ossium, they can filter by language and license, compare you against similar projects, and track your updates. That means the person who finds you today might still be following you in six months. The value is in the relationship, not the burst.
+
+## What each one is actually good for
+
+Product Hunt is good when you have something launchable with a story, a demo, and a clear value proposition. It is a marketing event. If you have a clean landing page and a working product, it can get you on a bunch of "best new tools" roundups and give you a social proof bump.
+
+Ossium is good when you have a project you want developers to find long term. A repo that is discoverable by language and license, comparable with alternatives, and trackable will keep surfacing to the exact people who want it. No event required, and the listing does not expire after 24 hours.
+
+## The realistic answer: do both, in the right order
+
+For most projects, the sensible sequence is to make the repository presentable first, list it on Ossium so it has a home developers can find, then do the Product Hunt launch when you have something worth the burst. The Product Hunt spike becomes more valuable when the people who click through land on a project that already looks established.
+
+Do not treat the two as competitors. They are different channels with different audiences, and they both matter. The mistake people make is skipping the boring one, the sustained directory listing, because the exciting one, the launch day, feels better.
+
+## One more thing
+
+None of this helps if the project itself is not ready. Both platforms will punish you equally if your README is empty and the code does not run. Launch platforms are amplifiers, and they amplify whatever you shipped.
diff --git a/content/posts/self-hosted-vs-cloud-hosted-open-source-tools.md b/content/posts/self-hosted-vs-cloud-hosted-open-source-tools.md
new file mode 100644
index 0000000..18365bf
--- /dev/null
+++ b/content/posts/self-hosted-vs-cloud-hosted-open-source-tools.md
@@ -0,0 +1,47 @@
+---
+title: "Self-Hosted vs Cloud-Hosted Open Source Tools: A Practical Guide"
+description: "When to self-host open source software and when to pay for hosted versions. A comparison of cost, effort, security, and compliance, with a realistic decision framework."
+type: guide
+category: tools
+tags: [self-hosting, cloud, open-source, devops, infrastructure]
+keywords: [self-hosted vs cloud hosted, self hosting open source, managed open source, self hosted tools, cloud vs self hosted]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Almost every good open source tool has two ways to use it: run it yourself, or pay someone to run it for you. The gap between these two is where most people make expensive mistakes.
+
+## What self-hosting actually costs
+
+The license is free. That is the part everyone remembers. The parts everyone forgets are the server, the backups, the updates, the security patches, and the late night call when the thing goes down.
+
+Self-hosting is a time commitment that never ends. Every package has a maintenance rhythm, and every update can break something you built on top of it. If you self-host ten tools, you have ten maintenance schedules to manage. This is a job, and it is usually a part time one.
+
+The upside is control. Your data stays on your infrastructure, you can modify the software, and you are not subject to a vendor's pricing decisions. For some workloads, that control is worth real money.
+
+## What cloud hosting actually costs
+
+Hosted versions of open source tools, the "open core" or "managed SaaS" route, flip the trade. You pay a subscription, and in return you get uptime, updates, backups, and a support channel. The vendor absorbs the operational burden.
+
+The costs are subtler. Your data lives on their servers, so you need to be comfortable with where they are hosted and under what jurisdiction. You are also subject to their pricing changes and their product direction. The tool might be open source, but your relationship with it is a commercial one.
+
+## Where compliance enters
+
+Data residency is the factor that quietly decides a lot of decisions. Regulations like India's DPDP Act care about where personal data lives and how it is handled. If your data must stay inside the country, or on your own servers, self-hosting may be the only option that satisfies your compliance obligations. No amount of convenience beats a hard requirement.
+
+## A workable decision framework
+
+Ask three questions in order.
+
+Is this data sensitive enough that I cannot accept it leaving my control? If yes, self-host, whatever the cost.
+
+Do I have the engineering time to maintain this properly? If the answer is genuinely yes, self-hosting is probably the right economic choice. If it is "we can figure it out", you will not, and you should buy the hosted version.
+
+Is this tool critical to my operation? The more critical it is, the more you want reliability over savings. A hosted service with an SLA beats a self-hosted instance managed by whoever is free on a Tuesday.
+
+## The pattern that works
+
+Most mature teams run a mix. Core databases and things with hard data requirements get self-hosted. Everything else gets the hosted version. The money saved by self-hosting the unimportant things is never worth the operational load, and the control gained is irrelevant if you do not need it.
diff --git a/content/posts/state-of-open-source-2026.md b/content/posts/state-of-open-source-2026.md
new file mode 100644
index 0000000..ddbe537
--- /dev/null
+++ b/content/posts/state-of-open-source-2026.md
@@ -0,0 +1,49 @@
+---
+title: "State of Open Source 2026: Key Takeaways"
+description: "An honest assessment of open source in 2026: corporate funding, open weights vs open source AI, licensing fights, maintainer burnout, and supply chain security."
+type: article
+category: tools
+tags: [state of open source 2026, open source licensing, open source ai, maintainer burnout, software supply chain]
+keywords: [state of open source 2026, open source ai debate, open weights vs open source, agpl sspl busl licenses, maintainer burnout open source]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Open source in 2026 is not in crisis, and it is not in a golden age either. It is in the messy middle where the software everyone depends on is funded, governed, and contested in ways that the original community never planned for. Here is how things actually stand, takeaway by takeaway.
+
+## Corporate money flows through foundations now
+
+The most consequential shift of the last few years is that critical infrastructure now lives under foundations. The Linux Foundation, CNCF, Apache, and the OpenSSF hold the governance of software that powers most of the internet, and companies that once sold these projects as products have donated them and moved to a support-and-services model. This is mostly good. A foundation with several corporate members can survive one sponsor changing strategy, which is more than a single company project can say.
+
+The pattern has a real cost: foundation governance is slow, and decisions get made by committee rather than by the people who actually wrote the code. That tension is not going away.
+
+## Open weights are not open source
+
+The single most misunderstood issue in 2026 is the difference between open source AI and open weights. Meta, DeepSeek, Qwen, Mistral, and most of the major labs release model weights you can download and run. That is a genuinely huge improvement over API-only access. But nearly all of these are open weights, not open source in the OSI sense: the training data, and often the training code, stay closed, and licenses add usage restrictions that classic open source licenses never impose.
+
+The OSI published its Open Source AI Definition to set the boundary, and the reaction from model labs ranged from ignoring it to pushing back on it. If you use these models, you should care, because the distinction decides whether you can truly audit, fork, and redistribute. We wrote the practical side of this in [how open source licensing works](/how-open-source-licensing-works) and [the free AI models post](/open-source-llms-in-2026-the-free-ai-models-everyone-will-be-using-while-you-re-still-overpaying).
+
+## Licensing fights reshaped the map
+
+License drama was the defining story of the early 2020s, and its results are now baked into the landscape. MongoDB moved to SSPL, Elastic moved away from the Elastic License and back to AGPL, Redis switched to BUSL and then back to AGPL in a reversal, and HashiCorp relicensed Terraform to BUSL, which directly produced the [OpenTofu](https://github.com/opentofu/opentofu) fork and the Redis fork [Valkey](https://github.com/valkey-io/valkey).
+
+What most people miss is that AGPL, SSPL, and BUSL are not the same thing. AGPL is a real open source license with a network clause. SSPL and BUSL are source-available licenses with restrictions that most companies cannot accept. Each fork that followed a relicensing move has done fine, which tells you something: for infrastructure, the community can and will rebuild around open governance. The details on each license are in [our licensing guide](/how-open-source-licensing-works).
+
+## Maintainer burnout is a structural problem
+
+The xz utils backdoor in 2024 forced everyone to look at how fragile the maintainer model is. A project used by essentially every Linux system was kept alive by one overworked volunteer, and the attacker spent months becoming that volunteer's collaborator before planting the backdoor. The problem was not unique to xz, it was just the version that got caught.
+
+Since then, foundations and companies have put money into maintainer funding and critical projects. GitHub Sponsors and similar tools help individuals, but they are not a career. The honest summary: sustainability is improving at the top of the stack, the long tail of small but depended-on projects is still on goodwill.
+
+## Security moved up the stack
+
+Supply chain security is no longer an afterthought. SBOMs, signed artifacts, provenance attestations, and tools like Sigstore have gone from nice-to-have to expected practice in most serious projects. Package registries keep improving their scanning, and tools that pin and audit dependencies, Renovate and Dependabot being the common ones, are now standard. The gap between how the top 1 percent of projects handle this and how the average project handles it is still large, and that gap is where most incidents will keep happening.
+
+## Where individuals and startups fit
+
+For individuals, open source is still the cheapest way to get good: your contributions are public, portable, and often noticed by recruiters. For startups, the playbook has settled. Use open source to build your base and your community, keep the messy or enterprise-critical parts proprietary, or sell hosted versions and support. Nobody should pretend there is a single business model that works for every project, but the open core and SaaS-on-top patterns keep proving themselves.
+
+The state of open source in 2026 is this: the software has never been more central to the world, the funding and governance around it are maturing, and the open questions, around AI, licensing, and who actually gets paid, remain genuinely open.
diff --git a/content/posts/top-10-websites-to-find-open-source-software.md b/content/posts/top-10-websites-to-find-open-source-software.md
new file mode 100644
index 0000000..63c5b6b
--- /dev/null
+++ b/content/posts/top-10-websites-to-find-open-source-software.md
@@ -0,0 +1,37 @@
+---
+title: "Top 10 Websites to Find Open Source Software for Any Use Case"
+description: "A practical list of the best websites to find open source software, from GitHub Trending and ossium to awesome lists and AlternativeTo, and which search each one suits."
+type: article
+category: tools
+tags: [open-source, discovery, directories, curated-lists, tools]
+keywords: [websites to find open source software, find open source software, open source alternatives, awesome lists, open source directories]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Ten sites, each with a different reason to exist. No single one of them finds everything, and anyone who tells you otherwise is selling something. What follows is where I actually go, depending on what I am looking for.
+
+**GitHub Trending.** The default. Updated daily, and its language tabs (Today, This Week, This Month) are more useful than most people use. Suits: when you want to see what is gaining stars right now, before you decide what deserves attention. The feed is popularity-weighted, so it rewards hype. Fine for a scan, weak for a decision.
+
+**ossium.** A discovery platform built on GitHub data, with trending repos plus filters for programming language and license, project comparison, and tracking. Suits: when you have criteria, "self-hosted, Go, MIT license, actively maintained", and you want the list narrowed before you open any repository page. If your decision hinges on license or maintenance, this is the site. The discovery workflow is covered in [how to find projects as a beginner](/how-to-find-open-source-projects-for-beginners).
+
+**Sourcegraph.** Code search over millions of repositories. Suits: when you want to see how a library is actually used in the wild, or verify a claim in a README. Type a function name and you get real usage examples. It will not tell you what to pick, but it will tell you whether a project's code matches its promises.
+
+**Awesome lists.** Not a single website so much as a convention, but the awesome-* repositories on GitHub are the most reliable curated directories in open source. awesome-selfhosted alone answers the "is there a self-hosted alternative" question for almost anything. Suits: research-heavy browsing by category, where you want a human-curated shortlist.
+
+**LibHunt.** Ranks open source libraries by GitHub stars, organized by topic, with an alternatives feed. Suits: "which library for X" questions where you want a popularity baseline plus related options. The ranking is crude, so treat it as a starting list, not a verdict.
+
+**Free Software Directory.** Run by the Free Software Foundation, listing thousands of packages that respect user freedom, which usually means a copyleft bias and no proprietary dependencies. Suits: when the license is a hard requirement, especially if you want to avoid anything non-free. Not the place for current trends.
+
+**AlternativeTo.** Users vote and comment on alternatives to known software, and it includes open source options alongside commercial ones. Suits: "I currently use X and want something different" searches. The open source filter shows you what the crowd recommends instead of the marketing copy.
+
+**Hacker News (Algolia search).** Not a directory, but the best source of ground truth about which projects are actually good. Suits: reading what maintainers and power users say about a project before you adopt it. Search a repo name, sort by date, and read the threads where people argue about the tradeoffs.
+
+**Open Hub (Black Duck).** Years of statistics on projects, contributors, and licenses. Suits: due diligence on a project's history, contributor counts, and license data. The interface is dated and the data leans toward the older open source world, which is exactly where it is strongest.
+
+**GitLab Explore.** The non-GitHub half of open source. Suits: finding projects that live outside the GitHub ecosystem, which includes serious infrastructure and corporate open source.
+
+Each of these solves one job well. Match the site to the question you are asking and you will find things in minutes. Ask the wrong one and you will conclude open source has nothing for you. If you would rather skip the search and look at finished projects, the [10 tools worth trying in 2026](/10-open-source-tools-worth-trying-in-2026) list is a different kind of starting point.
diff --git a/content/posts/top-50-open-source-software-every-developer-should-know.md b/content/posts/top-50-open-source-software-every-developer-should-know.md
new file mode 100644
index 0000000..2f657d1
--- /dev/null
+++ b/content/posts/top-50-open-source-software-every-developer-should-know.md
@@ -0,0 +1,94 @@
+---
+title: "Top 50 Open Source Software Every Developer Should Know in 2026"
+description: "A curated list of 50 open source projects every developer should know in 2026, grouped by category: version control, languages, databases, dev tooling, AI/ML, design, security, and communication."
+type: article
+category: tools
+tags: [open-source-tools, developer-tools, top-50, github, oss]
+keywords: [top open source software, open source tools for developers, best open source projects 2026, open source software list, developer tools]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Fifty projects, grouped by what they do. This is a curated list, not a popularity contest, so some obvious names are here and a few famous ones are not. Everything listed is a real project with a real community. If you do not recognize one, clone it and read the readme.
+
+**Version control**
+
+- Git: the version control system that runs most of the world's software, built by Linus Torvalds in 2005.
+- GitLab CE: self-hosted Git hosting with CI/CD, issue tracking, and merge requests bundled in.
+- Gitea: a lightweight Git forge you can run on a cheap VPS, perfect for a small team or personal use.
+
+**Languages and runtimes**
+
+- Python: the default for scripting, data, and AI work, with an enormous ecosystem.
+- Node.js: runs JavaScript outside the browser, and now TypeScript too.
+- Go: Google's compiled language for servers, CLIs, and anything with a network.
+- Rust: a systems language with memory safety built in, increasingly common in production infrastructure.
+- OpenJDK: the open source implementation of Java that most production Java actually runs on.
+
+**Databases**
+
+- PostgreSQL: the relational database most serious projects start with today.
+- MySQL: the most widely deployed open source relational database, owned by Oracle but open.
+- SQLite: a full database in a single file, built into your phone and browser.
+- Redis: the in-memory store for caching and queues. Its license changed in 2024, so check the terms; the open fork is Valkey.
+- MongoDB: the document database that made JSON-shaped storage mainstream.
+- Elasticsearch: search and log analysis at scale, the engine behind countless search boxes.
+
+**Servers and infrastructure**
+
+- Linux: the kernel running most servers, Android phones, and cloud infrastructure.
+- nginx: the web server and reverse proxy that quietly handles a huge share of internet traffic.
+- Apache HTTP Server: the web server that powered the early web and still runs millions of sites.
+- Docker: containers, the standard way software is packaged and shipped now.
+- Kubernetes: container orchestration, the platform most companies build their platforms on top of.
+- OpenSSL: the crypto library that secures almost every TLS connection.
+
+**Dev tooling**
+
+- VS Code: the most popular code editor, MIT licensed, with an enormous extension ecosystem.
+- Vim: the modal editor from 1991 that refuses to die, and for good reason.
+- Neovim: Vim's modern fork, scriptable in Lua, beloved by people who configure everything.
+- Jenkins: the oldest name in CI/CD, still running a huge share of build pipelines.
+- Ansible: agentless configuration management, simple automation for servers.
+- Prometheus: the standard for metrics and monitoring, almost every observability stack starts here.
+- Grafana: the dashboard layer on top of Prometheus and other data sources.
+
+**AI and machine learning**
+
+- TensorFlow: Google's deep learning framework, still widely used in research and production.
+- PyTorch: the framework most AI research actually ships in now.
+- Jupyter: the notebook environment where most data science and ML experiments happen.
+- scikit-learn: the simple, reliable library for classical machine learning.
+- Hugging Face Transformers: the interface to almost every open model, from BERT to modern LLMs.
+- Ollama: run open source LLMs locally on a laptop with one command.
+- llama.cpp: run quantized models on CPUs and limited GPU hardware.
+- vLLM: the high-throughput serving engine behind many LLM deployments.
+
+**Design and media**
+
+- GIMP: the free Photoshop-class image editor, stubborn but capable.
+- Blender: the complete 3D suite, modeling, animation, and rendering, all open source.
+- Inkscape: vector graphics, the free alternative to Illustrator.
+- Krita: a digital painting tool that is genuinely world-class for illustration.
+- Kdenlive: nonlinear video editing that covers most creators' daily needs.
+- OBS Studio: streaming and screen recording, the standard for video producers.
+- Penpot: collaborative design and prototyping, the open source Figma alternative.
+
+**Security**
+
+- Wireshark: the packet analyzer every network engineer eventually installs.
+- Nmap: port scanning and network discovery, the first tool in most security playbooks.
+- OWASP ZAP: web application security testing with automated scanning, a free alternative to Burp.
+- Hashcat: password recovery and cracking at high speed on GPUs.
+- Bitwarden: a password manager with an open source server and clients.
+
+**Communication**
+
+- Mattermost: self-hosted team chat that is Slack-shaped and enterprise-friendly.
+- Rocket.Chat: another self-hosted chat platform with a strong history in India and elsewhere.
+- Element: the main client for Matrix, the open protocol for federated messaging.
+
+None of these fifty is obscure. Most are the boring, dependable backbone of the industry, the kind of software you use for years without noticing it is there. If you want a more opinionated shortlist of things worth trying this year, including some newer names, my post on open source tools worth trying in 2026 covers that. And if you are wondering which of these make good first projects for contributions, I have a separate list of the best tools for open source contributors.
diff --git a/content/posts/top-open-source-github-repositories-by-stars-2026.md b/content/posts/top-open-source-github-repositories-by-stars-2026.md
new file mode 100644
index 0000000..331b001
--- /dev/null
+++ b/content/posts/top-open-source-github-repositories-by-stars-2026.md
@@ -0,0 +1,39 @@
+---
+title: "Top Open Source GitHub Repositories by Stars in 2026"
+description: "The most-starred open source repositories on GitHub, what star counts actually tell you, and how to separate real value from popularity."
+type: article
+category: tools
+tags: [github, open-source, repositories, trending, stars]
+keywords: [top github repositories by stars, most starred github repos, popular open source projects, github stars, top open source repositories 2026]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Star counts change constantly, so any exact number is stale by the time you read it. What does not change is which projects dominate the top of the list. This is the group that has held the top spots for years, with the usual caveat that a new AI project occasionally barges in.
+
+## The usual suspects
+
+freeCodeCamp has been near the top for so long that it is practically a landmark. A learning platform with a curriculum anyone can audit for free, and a codebase thousands of contributors have touched. Its stars are a mix of genuine users and people bookmarking it "for later", which is exactly what a star often means.
+
+React, Vue, and TensorFlow occupy the next tier. React because it is the default for frontend work, Vue for the same reason in different circles, and TensorFlow because a generation of ML engineers started there. Visual Studio Code is another permanent resident, popular with every kind of developer.
+
+build-your-own-x and system-design-primer sit high too. They are "learning" repos in the same sense as freeCodeCamp: thousands of people star them intending to study them, and the study gets deferred indefinitely. Popularity, but of a particular kind.
+
+## What a star count does and does not tell you
+
+A high star count tells you one thing reliably: the project is visible and widely known. It is a marketing signal, not a quality signal.
+
+It does not tell you if the project is maintained. Some heavily starred repos are barely active, with maintainers who respond every few months. It does not tell you if the code is good, or if the maintainers are responsive, or if the project will still exist in a year.
+
+When people say "the most popular open source projects", they usually mean "the most starred", and those are not the same thing. Popularity measured by stars is heavily influenced by how long a repo has existed and how easy it is to star without using the software.
+
+## What to check instead
+
+When you are picking a project to adopt or contribute to, the meaningful signals are different. Look at the last commit date on the default branch, the number of open issues versus how quickly they get closed, the release cadence, and whether the maintainers respond to new issues at all.
+
+A project with fifty thousand stars and no commits in two years is a museum piece, not a dependency. A project with eight thousand stars and a release last week is an actively maintained tool you can build on.
+
+For the very top of the list, the truth is that the most-starred repositories are mostly learning resources and frameworks that everyone has heard of. That is fine. Just know that when you star a repository, you are contributing to its popularity, not to its quality. The two diverge more than people expect.
diff --git a/content/posts/top-open-source-projects-trending-this-month.md b/content/posts/top-open-source-projects-trending-this-month.md
new file mode 100644
index 0000000..22043cd
--- /dev/null
+++ b/content/posts/top-open-source-projects-trending-this-month.md
@@ -0,0 +1,45 @@
+---
+title: "Top Open Source Projects Trending This Month"
+description: "A snapshot of open source projects trending now across local AI tooling, AI coding agents, self-hosting, and developer productivity."
+type: article
+category: tools
+tags: [trending open source, open source projects 2026, local ai, coding agents, self-hosting]
+keywords: [open source projects trending 2026, trending github repositories, local ai tools, open source coding agents, self hosted tools 2026]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Trending lists move fast. A repository that sat in your bookmarks for months can pick up a burst of stars in a week, and another can go quiet overnight because it matured, not because it failed. So treat this as a snapshot, not gospel. Here is what has been getting attention across a few clear themes recently: local AI tooling, AI coding agents, self-hosting and privacy, and everyday developer productivity.
+
+## Local AI and LLM tooling
+
+The dominant trend in open source right now is people running models on their own hardware. [Ollama](https://github.com/ollama/ollama) is still the most common entry point. One command pulls a model and serves it locally, and a whole ecosystem has grown around it: [Open WebUI](https://github.com/open-webui/open-webui) gives it a ChatGPT-like interface, and [llama.cpp](https://github.com/ggml-org/llama.cpp) does the actual CPU and GPU inference under the hood.
+
+[VLLM](https://github.com/vllm-project/vllm) is what you reach for when you need throughput rather than convenience. It is the engine behind a lot of production serving stacks, and it keeps picking up new kernels and quantization formats. [LocalAI](https://github.com/mudler/LocalAI) is a smaller but persistent project that mimics OpenAI-compatible APIs, which makes it handy when you want to swap out a cloud endpoint without rewriting your app.
+
+Why this cluster keeps trending: hardware got cheaper, small models got much better, and more people got tired of paying per token for things a mid-range GPU can run fine. If that matches you, the practical reading is in [our post on the free models everyone is using](/open-source-llms-in-2026-the-free-ai-models-everyone-will-be-using-while-you-re-still-overpaying) and [what the best local model for coding is](/what-is-the-best-local-llm-for-coding-in-2026).
+
+## AI agents and coding assistants
+
+The other big story is AI that edits code directly. [Aider](https://github.com/Aider-AI/aider) has been around a while and still holds the crown for terminal-based pair programming, because it works with whatever model you can talk to. [Cline](https://github.com/cline/cline) pushed agents into the IDE, and its plugin-based approach to permissions and tools has been copied widely. [OpenHands](https://github.com/All-Hands-AI/OpenHands) (formerly OpenDevin) targets autonomous multi-file tasks, and [Continue](https://github.com/continuedev/continue) keeps gaining ground as a fully open alternative to the closed autocomplete extensions.
+
+A fair warning if you are new to these: the models still make confident mistakes, so running them against git history you can throw away is the sane workflow. For a wider view of the tooling around these agents, the [tools roundup](/10-open-source-tools-worth-trying-in-2026) is a good starting point.
+
+## Self-hosting and privacy
+
+Self-hosting has quietly become the default answer to "I do not want my data on someone else's SaaS." [Immich](https://github.com/immich-app/immich) is the standout, a Google Photos replacement that keeps improving its face recognition and search. [Home Assistant](https://github.com/home-assistant/core) remains the biggest name in smart home automation, and its annual releases keep pulling in more integrations than any competitor.
+
+On the privacy side, [Pi-hole](https://github.com/pi-hole/pi-hole) and [AdGuard Home](https://github.com/AdguardTeam/AdGuardHome) both stay in steady rotation as network-level ad blockers. [Paperless-ngx](https://github.com/paperless-ngx/paperless-ngx) and [Actual Budget](https://github.com/actualbudget/actual) are the two I see recommended most for personal data, documents and finance respectively. For a broader set of picks, the [tools worth trying in 2026](/10-open-source-tools-worth-trying-in-2026) post covers several of these in more depth.
+
+## Developer productivity
+
+The terminal stack keeps getting better. [uv](https://github.com/astral-sh/uv) has made Python dependency management fast enough that people stopped defending pip's speed, and [Ruff](https://github.com/astral-sh/ruff) did the same for linting. [lazygit](https://github.com/jesseduffield/lazygit) is one of those tools where you wonder how you survived without a visual git client in the terminal, and [zoxide](https://github.com/ajeetdsouza/zoxide) removes any excuse for slow `cd` habits.
+
+[ripgrep](https://github.com/BurntSushi/ripgrep), [bat](https://github.com/sharkdp/bat), and [fd](https://github.com/sharkdp/fd) round out the modern grep-and-file toolkit. None of this is flashy, which is exactly why it trends: once you install these, you do not go back.
+
+## The honest caveat
+
+Trending is measured by stars, commit activity, and adoption, and all three change weekly. A project that leads this month can be replaced next month, sometimes by a fork or a rewrite of itself. Use lists like this to discover candidates, then judge with your own hands: clone it, read the docs, check the license. Your own workflow is a better filter than any ranking.
diff --git a/content/posts/what-does-oss-mean-in-software.md b/content/posts/what-does-oss-mean-in-software.md
new file mode 100644
index 0000000..a871f93
--- /dev/null
+++ b/content/posts/what-does-oss-mean-in-software.md
@@ -0,0 +1,30 @@
+---
+title: "What Does OSS Mean in Software?"
+description: "OSS means open source software: source code published under a license that allows viewing, modifying, and distributing it. How it differs from freeware and public domain."
+type: question
+category: beginners
+tags: [open source, oss, software, beginners]
+keywords: [what does oss mean, oss meaning, open source software definition, oss vs freeware, what is open source software]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+answerSummary: "OSS stands for open source software, meaning software whose source code is published under a license that lets others view, modify, and distribute it."
+---
+
+OSS stands for open source software, software whose source code is published under a license that lets others view, modify, and distribute it. That is the answer in one line. Everything else is about what that definition actually guarantees and what people commonly confuse it with.
+
+The term was formalized by the Open Source Initiative in the late nineties. The OSI published ten criteria that a license must meet to be called open source: free redistribution, source code available, permission to create derived works, no discrimination against people or fields of endeavor, and a few more. The practical core is simple. Open source means the code is readable and reusable, not just free to download.
+
+Most people get two things mixed up with open source. The first is freeware. Freeware is software you can use without paying, but you get no source and no rights to modify or redistribute it. WhatsApp is freeware. You use it, that is all. Open source is freeware plus rights. You can even sell open source software, so "free" and "open" are not the same axis. Some software is both free and open source, like most of Linux. Some is paid and open source, which is how Red Hat built a business.
+
+The second confusion is public domain. Public domain means the author has abandoned copyright entirely, so no license is needed at all. Most open source does not work that way. MIT, GPL, and Apache keep the author's copyright and grant you permission under explicit terms. The license is the legally precise thing that makes the openness real. No license file, no rights, even if the code is sitting in a public GitHub repo.
+
+The examples you already know are mostly OSS. Linux and Git are GPL. Node.js and React are MIT. Kubernetes is Apache 2.0. PostgreSQL has its own permissive license. Firefox is Mozilla Public License. The list covers operating systems, compilers, databases, browsers, and the front end of half the web. The odds are high that your stack already depends on more open source code than you realize.
+
+Why does the label matter in practice? When a client or a procurement team writes "must be open source" into a requirement, they usually mean one of three things: no vendor lock-in, the ability to inspect code, or no licensing fees. The first two are guaranteed by the definition. The third is not. Freeware gives you the "no fees" part and nothing else, so the term separates "cheap" from "open".
+
+Here is the failure mode I have seen. A Bangalore consultancy bids on a government RFP that states all delivered software must be open source. The team reads that as "must be free", proposes a proprietary product with a free tier, and the bid dies in compliance review. Had they read it as "source available under an OSI-approved license", they could have proposed building on open components and shown the exact license on every dependency. Same product, different reading of four words.
+
+For how the rights actually work in practice, including which licenses let you build commercial products, read [the licensing guide](/how-open-source-licensing-works). If you are looking for projects to start with, [the beginner's guide to finding open source projects](/how-to-find-open-source-projects-for-beginners) is a better next step.
diff --git a/content/posts/what-is-open-source-software.md b/content/posts/what-is-open-source-software.md
new file mode 100644
index 0000000..9ab88e3
--- /dev/null
+++ b/content/posts/what-is-open-source-software.md
@@ -0,0 +1,37 @@
+---
+title: "What Is Open Source Software? A Complete Beginner's Guide"
+description: "What open source actually means: source code you can read plus a license that lets you use, modify, and redistribute it. Common misconceptions, and why developers and businesses choose it."
+type: guide
+category: beginners
+tags: [open-source, beginners, open-source-license, github]
+keywords: [what is open source software, open source explained for beginners, open source vs free software, open source license explained, why use open source]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+Open source is not a kind of software you download for free. It is a legal setup. The source code is published, and the license that comes with it gives anyone permission to use, modify, and redistribute the program. Both parts matter, and confusing them is where beginners go wrong.
+
+The source being visible is only half the story. The code for an open source project sits in a public repository on GitHub or a similar host. Anyone can read it, study it, and copy it into their own editor. But "I can read the code" is not the same as "I am allowed to use it." Under copyright law, the author owns the code the moment it is written. If a repository has no license file, you have no legal right to do anything with it beyond looking. The license is what grants the rights. An open source license, MIT, Apache 2.0, or GPL, gives you that permission up front, no email required.
+
+So the working definition: a project is open source when its source code is publicly available and a recognized open source license grants you the right to use, modify, and distribute it, with conditions that vary by license. Permissive licenses like MIT let you drop the code into closed commercial products. Copyleft licenses like GPL require you to share your modified source if you distribute your version. I explain the difference in more depth in my guide to how open source licensing works, which is worth reading before you copy code into a project that will ship.
+
+Now the misconceptions.
+
+Open source does not mean free of cost. The word "free" here means liberty, not price. Plenty of open source projects are free to download, but companies like Red Hat, GitLab, and Mongo sell hosted versions, support, and enterprise features. You can also charge money for an open source product; the license governs redistribution, not what you may charge. And the reverse is true: lots of software is free to download yet closed source, WhatsApp or Zoom for example. Free price and open source are two separate axes.
+
+Open source does not mean no support. Large projects have large communities. When you hit a problem with PostgreSQL or React, you are usually one search away from a Stack Overflow answer or a GitHub discussion. What you do not get is a named vendor with a phone number. Companies that want that buy support contracts from the companies built around open source projects; Red Hat's whole business is that.
+
+Why do people and businesses pick open source anyway?
+
+For individuals, the reasons are practical. You can inspect what a tool does instead of trusting marketing. A tool read by thousands of developers has had its rough edges found, reported, and fixed. And you can extend it. If a tool does ninety percent of what you need, you can fork it and build the last ten percent, legally, because the license permits it.
+
+For businesses, it comes down to cost, control, and vendor lock-in. No per-seat license fees means predictable pricing. Because the source is visible, a company is not trapped if a vendor disappears or raises prices; someone can take over the code. This is why the modern internet runs on open source. The server that served this page almost certainly runs Linux, behind a reverse proxy like nginx, on a PostgreSQL database. The cloud provider underneath runs the same story.
+
+A concrete example. A small team in Bangalore, say three students building a college placement tracker, can assemble the entire stack from open source tools without spending a rupee on licenses. Git for version control, PostgreSQL for the database, React for the frontend. When they need a caching layer, Redis. When they get stuck, they search the same community forums where thousands of people hit the same problem before them. Nothing expires when a trial runs out, and the tools scale with the project.
+
+The license is the part beginners skip, and it is the part that matters. Read the LICENSE file before you rely on a project, and when you are ready to start contributing, my guide to finding open source projects for beginners is a decent first stop.
+
+Open source is source code you can read plus a license that says what you may legally do with it. Everything else, the free price, the community, the absence of formal support, follows from those two facts.
diff --git a/content/posts/why-companies-are-adopting-open-source-software.md b/content/posts/why-companies-are-adopting-open-source-software.md
new file mode 100644
index 0000000..b988098
--- /dev/null
+++ b/content/posts/why-companies-are-adopting-open-source-software.md
@@ -0,0 +1,43 @@
+---
+title: "Why Companies Are Adopting Open Source Software in 2026"
+description: "The practical reasons enterprises adopt open source, from cost and auditability to avoiding vendor lock-in, plus the hidden costs in people and operations."
+type: article
+category: tools
+tags: [open source adoption, enterprise, postgresql, kubernetes, vendor lock-in, cost]
+keywords: [why companies adopt open source, open source software benefits for business, postgresql vs oracle cost, kubernetes enterprise adoption india, avoiding vendor lock-in, open source security auditability]
+publishedAt: 2026-08-08
+updatedAt: 2026-08-08
+author: OpenCode
+avatar: /logo/opencode-logo-dark.png
+featured: false
+---
+
+A private Indian bank swapped its Oracle databases for PostgreSQL and did not announce it. Migrations like this are not product launches, they are infrastructure, and by 2026 most large Indian enterprises have done at least one. The reasons keep coming up in the same order.
+
+## Cost is the entry point
+
+A commercial database licence renewal runs into crores at scale, and per-core pricing climbs every few years. PostgreSQL is free to license, and that gap alone justifies the planning cost. But the real savings show up elsewhere. Commercial licences bundle features you never touch. Open source lets a team run exactly the stack it needs, on commodity hardware or whatever cloud it already has.
+
+## Avoiding vendor lock-in
+
+A proprietary database's file format and undocumented behaviour tie you to the vendor's roadmap, pricing, and support timeline. Open formats and standard SQL mean another vendor, or your own team, can take over. Indian enterprises learned this the hard way with ERPs and core banking platforms where the exit cost had become higher than the software itself.
+
+## Security and auditability
+
+Open source is not automatically secure, but you can actually check. Enterprise teams review the diff on a security release, run their own scans, and see precisely what runs in production. For a bank answering to the RBI, knowing what the core database does matters more than any vendor certification. Source visibility also makes compliance audits easier, since you can point at code instead of trusting a document.
+
+## Control over the roadmap
+
+A vendor can deprecate a feature you depend on and simply stop supporting it. With open source you can fork, patch, or hire someone to maintain what you need. Most companies never actually fork, but the option alone changes the negotiation. Vendors of open source software know you can leave, so pricing stays closer to reality.
+
+## Talent and the ecosystem
+
+A junior developer in India is far more likely to have run PostgreSQL or Kubernetes than Oracle WebLogic. Recruiting for open source skills is easier, the learning material is free, and the pool includes people who trained on the exact stack you run. The ecosystem compounds this. Kubernetes, Prometheus, and Grafana are the default stack for running and observing modern workloads, and the community ships tools faster than any single vendor could.
+
+## The Indian example nobody announced
+
+IRCTC is the clearest case. Its ticketing site absorbs booking spikes that break most architectures, and it moved off a proprietary stack years ago, partly for cost and partly for scale. The same reasoning sits behind public sector moves to open source office software and behind nearly every Indian fintech running Kubernetes and PostgreSQL. The argument is identical at every size: the licence was the cheapest part, and removing it exposed the real cost, which is engineering.
+
+## The honest counterpoint
+
+Open source is not free. You pay in people. The DBA team that used to call Oracle support now owns the PostgreSQL upgrade, the failure, and the tuning. Hosting, backups, monitoring, and security patching all land on your plate. That is why the mature adoption pattern is managed: a bank rarely runs its own Kubernetes distribution, it buys a managed service and keeps the flexibility. The licence cost disappears, the operations cost does not, and companies that plan for that are the ones where the switch sticks.
diff --git a/lib/content/parse.test.ts b/lib/content/parse.test.ts
index 91a921d..0820b06 100644
--- a/lib/content/parse.test.ts
+++ b/lib/content/parse.test.ts
@@ -66,6 +66,14 @@ describe("toFrontmatter", () => {
     expect(fm.tags).toEqual(["a", "b"]);
     expect(fm.keywords).toEqual(["solo"]);
   });
+
+  it("reads the avatar field and leaves it empty by default", () => {
+    expect(
+      toFrontmatter({ title: "T", avatar: "/logo/opencode-logo-dark.png" }, "t")
+        .avatar,
+    ).toBe("/logo/opencode-logo-dark.png");
+    expect(toFrontmatter({ title: "T" }, "t").avatar).toBeUndefined();
+  });
 });
 
 describe("estimateReadingTime", () => {
diff --git a/lib/content/parse.ts b/lib/content/parse.ts
index 2d61301..05a2c0f 100644
--- a/lib/content/parse.ts
+++ b/lib/content/parse.ts
@@ -118,6 +118,7 @@ export function toFrontmatter(
     updatedAt: data.updatedAt ? String(data.updatedAt) : undefined,
     author: String(data.author ?? "ossium"),
     authorUrl: data.authorUrl ? String(data.authorUrl) : "https://ossium.in",
+    avatar: data.avatar ? String(data.avatar) : undefined,
     featured: Boolean(data.featured),
     draft: Boolean(data.draft),
     image: data.image ? String(data.image) : undefined,
diff --git a/lib/content/types.ts b/lib/content/types.ts
index 17e9cbf..194f44b 100644
--- a/lib/content/types.ts
+++ b/lib/content/types.ts
@@ -25,6 +25,8 @@ export interface PostFrontmatter {
   updatedAt?: string;
   author: string;
   authorUrl?: string;
+  /** Author avatar image path (defaults to the ossium logo when absent) */
+  avatar?: string;
   featured?: boolean;
   draft?: boolean;
   /** Optional cover image path or absolute URL */
diff --git a/public/logo/opencode-logo-dark.png b/public/logo/opencode-logo-dark.png
new file mode 100644
index 0000000..cf868c8
Binary files /dev/null and b/public/logo/opencode-logo-dark.png differ