Course B · Module B2 Going Agentic · Lesson 14 of 18

Open Source

Stand on the shoulders of millions of builders — for free.

~12 min · No tools needed · Prereq: B13 (Session Logs)

Almost every serious piece of software you use — your database, your web framework, the AI library powering your agents — was built in the open by thousands of volunteers who chose to share their work with the world. That shared work is called open source, and your single win from this lesson is learning how to find it, evaluate it, and use it without feeling like an outsider. Millions of builders already solved the problem you're staring at. Your job is to know how to borrow the answer.

What "open source" actually means

Think of a recipe book where every recipe is public, anyone can cook from it, anyone can suggest a tweak, and anyone can reprint it — as long as they follow a few simple rules. That's open source software. The code is the recipe; the licence is the rules for reprinting it.

The rules are usually one of two flavours. Permissive licences (like MIT or Apache) essentially say: "Use it for anything — commercial, personal, modified — just keep our name in the credits." Copyleft licences (like GPL) add one extra rule: "If you ship a modified version, your version must also be open source." For most small-business use you'll rarely hit the GPL restriction, but it's worth a quick check before you build a paid product on top of something.

Permissive (MIT, Apache, BSD)

  • Use in commercial products: yes
  • Modify freely: yes
  • Keep your own code private: yes
  • Required: credit the original authors

Copyleft (GPL, AGPL)

  • Use and modify: yes
  • Ship a modified version: must open-source your version too
  • AGPL extends this to server-side use
  • Not a problem if you're not redistributing

Finding and evaluating a project

The main home for open source software is GitHub. A search there — or just asking your AI "what are the best open source libraries for [task]" — will surface candidates quickly. Once you have a project page in front of you, run this four-point check before you trust it:

StarsOther developers' votes of confidence. Thousands of stars is a good sign; dozens might mean a personal experiment.
Recent activityWhen was the last commit? A project with no updates for two years may be abandoned. Look for recent releases.
Open issuesA few hundred is normal for a popular project. Thousands of open issues and none being closed is a warning sign.
LicenceClick the licence badge. Confirm it's MIT, Apache, or similar permissive text before you build on it commercially.
The golden move: paste the project's README into your AI and ask "In one paragraph, what does this do? Is it still actively maintained? What licence does it use, and are there any restrictions I should know about for a commercial product?" You get a plain-English evaluation in seconds.

Using a project vs contributing back

For most entrepreneurs, the relationship with open source is simple: you are a user. You install the package, you get the benefit, you follow the licence terms. That is completely fine and completely normal — it's why the software was published.

Occasionally you'll fix a bug or add a feature that would benefit others. If you do, you can contribute back by opening a pull request — a proposed change the project's maintainers can review and merge. You don't have to. But when you do, you join the collaborative chain that made the software useful to you in the first place. It's one of the genuinely warm parts of the tech world.

How AI changes the equation

A year ago, picking up an unfamiliar open source library meant hours of reading documentation and stack-overflow hunting. Now you can paste the README (or a code snippet) into your AI and say "show me the simplest possible way to use this in my project." The AI will write the wiring code, explain what each part does, and flag anything that looks risky. That lowers the barrier to using open source from "requires a developer day" to "requires an afternoon." Millions of solved problems just became directly accessible to you.

Check yourself

Answer before opening. Recalling it now is what makes it stick.

You want to use a library licenced under MIT in a paid product you sell. Is that allowed?

Yes. MIT is a permissive licence. You can use it in commercial products and keep your own code private. Just keep the original copyright notice somewhere in your project.

You find a perfect library on GitHub, but the last commit was three years ago and there are 800 unanswered issues. What do you do?

Look for a maintained fork or a different library. Abandoned projects don't get security patches. A popular project's README often links to the actively maintained successor; your AI can also suggest current alternatives.

A developer friend says "just copy this GPL-licenced library into your product." Should you?

Not without checking. GPL requires that any product you distribute that contains GPL code must also be released as open source. If you're selling a closed-source SaaS, that's likely a problem. Ask the AI to explain the specific GPL version's terms, and when in doubt, find an MIT-licenced alternative.

Read this next (primary source)

Open Source Guides (opensource.guide) — the canonical plain-English guide to understanding, using, and contributing to open source software. Start with "How to Contribute to Open Source." ~15 min. See RESOURCES.md for more.

I'm your teacher — bring me a project. Find any open source library or tool that looks useful for what you're building, paste the GitHub URL or README here, and I'll help you evaluate it, understand the licence, and show you the simplest way to use it. That's the fastest path from "looks interesting" to "working in my project."

New terms this lesson — open source, licence, repository, pull request — are defined in the course glossary.