10 GitHub Open Source Projects I Actually Use (Not Just Starred)

Three years into programming, I had a bad habit: see a project with lots of stars, star it, never look at it again. My GitHub stars collection hit the hundreds. I could count on one hand the number of projects I'd actually used.

That feeling is pretty common — you collect a lot, but nothing really changes.

So I changed my approach: instead of chasing star counts, I started asking myself "did this actually save me or solve a real problem?" With that lens, GitHub looks completely different.

I went back through the projects I've genuinely used over the years and picked these 10. They're not necessarily the most-starred projects on GitHub, but every single one went through the same journey for me: discovered it -> started using it -> became a habit.

---

freeCodeCamp: The Most Serious Free Programming Education

Let's get the obvious one out of the way first: freeCodeCamp, 377K+ stars, the world's largest programming learning community.

Why is it obvious? Because it genuinely is the ceiling of free programming education — not just one of them.

A few years ago, a friend of mine wanted to transition from a traditional industry into frontend development. Limited budget, couldn't afford a bootcamp. I told him to try freeCodeCamp for three months, no other advice. Three months later he'd completed the entire frontend path — React, Node.js, MongoDB, each course with hands-on projects. He ended up getting interviews and landed a job at a small company.

I'm not saying freeCodeCamp replaces everything. Its curriculum leans frontend and full-stack, the algorithm section is relatively weak, and the UI teaching isn't cutting-edge. But it does the most important thing right: it doesn't let you watch videos — it makes you write code.

Every concept has exercises immediately. Every module ends with five projects you have to complete independently to earn the certificate. This "forced output" design is more effective than any methodology.

Best for: Complete beginners, career switchers on a budget.
Not for: Experienced developers who just want to quickly pick up a new technology.

---

hello-algorithm: Learning Algorithms With Animations Actually Works

70.5K+ stars. This one's sometimes called "Algorithm Visualized" in English.

I used it during my second year of college while grinding LeetCode for interview prep. I'd done about fifty problems but felt like I had no system — every new problem felt like starting from scratch. A senior recommended I read through hello-algorithm before continuing.

I spent two weeks going through all the animations, from complexity analysis to dynamic programming. Each algorithm has animated visualizations with code in multiple languages. After that, LeetCode felt completely different. Instead of memorizing solutions, I could recognize patterns — "this is a greedy problem," "that's a DP state transition."

Its biggest strength is lowering the psychological barrier to understanding algorithms. A lot of people get stuck learning algorithms not because of intelligence, but because abstract concepts don't form mental pictures. This project exists specifically to solve that problem.

Best for: People learning algorithms for the first time, anyone stuck in the "I grind problems but don't improve" loop.
Not for: People who've already done 500+ LeetCode problems — it'll be too basic.

---

awesome: You Can't Find Resources Because You're Not Searching This Word

264K+ stars. A "list of lists."

I discovered the awesome series embarrassingly late — about two years into using GitHub. I was looking for a Python async crawler, Googled it, got a dozen conflicting blog posts from different sources. A colleague said: "Just search awesome-python on GitHub."

Organized categories, one-line descriptions for each library, star counts. I picked what I needed in fifteen minutes.

That's all it does — lets experienced developers do the first round of filtering for you. You don't start from zero in a new domain. You start from "what everyone already knows is good" and go deeper from there.

awesome-python (160K+), awesome-go, awesome-machine-learning — each one is worth bookmarking separately. There's also awesome-interview-questions, organized by domain, which is great for last-minute interview prep.

When to use: Whenever you're entering a new language or framework, search awesome-xxx first before reading any tutorial.

---

VS Code: But Actually Look at Its Source Code

154K+ stars. Microsoft's code editor — I don't need to introduce this one. Everyone reading this probably uses it.

But I'm not here to say "use VS Code." I'm here to say read its source code.

VS Code is one of the best large-scale open source projects to learn from. Written in TypeScript, extremely well-engineered: clean module boundaries, thorough tests, detailed contribution guides. If you write TypeScript at work, reading VS Code's source will directly improve how you architect your own projects.

My own experience: I was building an Electron desktop app and got stuck on main process/rendering process communication. Tutorials were vague. I looked at how VS Code handles the same problem — its IPC wrapper layer design — and it immediately cleared up my confusion.

As for plugin recommendations, there are too many lists online. I'll just mention one that's easy to overlook: GitLens. It shows you who wrote each line of code, when, and why. In team collaboration, this plugin has saved me countless times.

The real value: Using it is common. What's actually valuable is going deeper — studying the architecture, the plugin system, the contribution workflow.

---

the-art-of-command-line: Learning the Command Line Properly Is Worth It

140K+ stars. A repository dedicated to command line tips.

This is the most "I didn't know I needed this until I read it" project on this list.

My first year as a developer, my command line knowledge was basically cd, ls, git add, git commit. Then I watched a colleague SSH into a server and troubleshoot an issue — he used awk to parse a 200-line log file in one command, then batch-renamed a pile of files with xargs, all in under two minutes.

I remember standing there thinking: I could do the same tasks, but it would take me ten times as long because I didn't know these tools existed.

I went through the-art-of-command-line that evening. It has a Chinese translation. It's not a dry command reference — it's organized by scenario: "you need to batch process files," "you need to analyze logs," "you need to monitor system status." Each section gives you the most practical commands.

After that, I started consciously using the command line instead of GUI for daily tasks. The efficiency improvement was real.

The biggest benefit: Once you're comfortable with the command line, you can work in any environment. Servers, Docker containers, remote machines — these places often only have a terminal.

---

996.ICU: A Code Repository and the Reality Behind It

268K+ stars. A project completely unrelated to programming technology.

I hesitated about including it. But it's genuinely one of the projects that had the biggest impact on Chinese developers in GitHub's history, and it was the first time many people realized "open source isn't just about code."

In 2019, a developer launched the 996.ICU project on GitHub — "work 996, end up in ICU." It shot to the top of GitHub's all-time star growth chart within a short time, driven by millions of Chinese programmers collectively responding to overtime culture. The project maintains a blacklist (companies practicing 996) and a whitelist (companies with normal hours).

What practical value does it have for developers?

From a utilitarian standpoint, the lists themselves are informative. You get an offer from a company and don't know what it's like — search the lists. It's far more authentic than recruitment site reviews because it's anonymous and community-maintained.

But its deeper value is a reminder: tools and technology serve life, not the other way around. When making career decisions, salary is only one dimension. Work environment, pace, and long-term toll on a person deserve serious consideration.

I'm not including this to support or oppose any specific system. I just think, as a piece of collective memory for the developer community, it deserves to be remembered.

---

public-apis: No More Making Up Data for Your Demos

248K+ stars. Over 1,000 free APIs, categorized.

I was building a frontend portfolio and wanted a few apps with real data — weather, movie search, exchange rates. No backend, didn't want to set up a server. public-apis saved me.

The repo organizes APIs by category: weather, news, finance, games, AI... Each entry notes whether registration is required, whether HTTPS is supported, whether CORS works. You pick what you need, fetch it directly, done.

A few I've actually used:

• OpenWeatherMap: Free weather API, more than enough for a demo
• Unsplash API: Free image search, great for portfolio project visuals
• CoinGecko API: Crypto prices, good for data visualization practice
• REST Countries: Country info, easy "world encyclopedia" project

One tip: before using an API, check its GitHub repo and last update date. The public-apis list occasionally has entries for APIs that have already been shut down.

---

nvm: The Node Version Manager You Need

74.5K+ stars. Solves one specific but universal problem.

What problem? Project A needs Node 16. Project B needs Node 18. You want to play with the latest Node 20. Uninstalling and reinstalling Node every time you switch projects is torture.

nvm fixes it. Any Node version, three commands:

nvm install 18
nvm use 18
nvm alias default 18

A deeper tip: add a .nvmrc file in your project root with just the version number 18. When you cd into the project, run nvm use and it auto-switches. In a team setting, this is gold — everyone's local environment can differ, but each project can agree on a version.

The one gotcha I hit: on Mac, after installing nvm, packages you installed globally with npm install -g become unavailable after switching Node versions. The fix is simple — reinstall global packages after switching, or use nvm reinstall-packages to migrate.

One sentence: If you use Node.js, there's no reason not to install nvm.

---

gitignore: You Probably Don't Have a Proper .gitignore

155K+ stars. The "small thing that prevents big problems" project.

I've seen someone commit node_modules to Git. The entire folder. CI build timed out. I've also seen .DS_Store files everywhere, IDE configs, compiled artifacts all in version control.

The cause is always the same: no .gitignore file, or a bad one.

GitHub's gitignore repo has templates for every language, framework, IDE, and OS. The usage is simple: when starting a new project, find your tech stack's template, paste it into your .gitignore, done.

Common gotchas:

• Match the template to your tech stack. A Python template for a Java project won't help.
• Global .gitignore: Some files are OS-level (macOS .DS_Store, Windows Thumbs.db). Set up a global .gitignore once and forget about it.
• Already-committed files aren't ignored by adding them to .gitignore. If node_modules is already tracked, you need git rm -r --cached node_modules first.

It's a small thing, but a clean repo makes code reviews and collaboration much smoother. Repo cleanliness doesn't affect functionality on the surface, but it directly impacts collaboration efficiency and the code review experience.

---

spoon-knife: Your First PR Starts Here

12.3K+ stars. Not the most starred, but important for a different reason.

spoon-knife is GitHub's official beginner practice project. It's designed for people who've never submitted a PR. The entire project is just one README. The contribution is simple: add a line with your info.

But the value isn't the line — it's going through the entire open source contribution workflow:

1. Fork the project
2. Clone locally
3. Create a new branch
4. Make changes, commit
5. Push to your fork
6. Submit a Pull Request
7. Wait for code review and merge

For someone with no GitHub experience, this workflow has a real learning curve. I've helped two programming-newbie friends complete their first PRs using spoon-knife. Both said the same thing: "So this is how GitHub collaboration works."

If you want to contribute to open source but don't know where to start — do this first. Once you're comfortable with the Fork -> Branch -> PR flow, contributing to real projects won't feel intimidating.

---

How to Pick Projects That Actually Matter

Back to the original problem — starring everything, using nothing. My solution is three questions:

1. Does this solve a problem I have right now? If not, it can wait.

2. How much time will it take to figure out? Some projects need days of learning. Some take ten minutes. Start with the low-effort ones, get quick wins, then tackle the bigger ones.

3. Will I still use this in six months? This question forces you to distinguish between "interesting right now" and "actually need this."

GitHub has infinite great projects. Your time and attention are finite. Pick fewer, go deeper.

If you only remember one thing from this article: star count is a reference, but the real measure of a project's value is whether it changed how you work or learn. That's the only "star" that matters.