And to be a more effective GitHub user, you'll need to know how to search within the platform.

This involves using qualifiers to efficiently filter through millions of repositories and billions of lines of code. Precise queries help you locate specific function definitions, projects, people, issues, pull requests, code, security vulnerabilities, or contribution opportunities.

In this tutorial, you'll learn how to use GitHub search, whether you're a beginner or a pro developer.

To enhance your learning, I've divided this article into two sections:

1. Basic Search Functionality

2. Advanced Search Functionality

What We'll Cover:

• What We’ll Cover:

• Basic Search Functionality

  • How to Search Globally

  • How to Do a Scoped Search (for a Particular Repo or Organization)

• Advanced Search Functionality

  • Search Qualifiers

  • How to Save Searches

  • How to Manage Saved Searches on GitHub

  • Why Do We Need GitHub Advanced Search?

• Conclusion

Basic Search Functionality

Basic search here refers to the most commonly used search functionalities that are fast and easy to use.

To start, click the GitHub search icon, type your query, and GitHub will display your results. With basic search, you can search globally across all of GitHub or narrow your search to a specific repository or organization.

How to Search Globally

To search on GitHub, click the search tab or press the / key to open the search bar.

To search globally (across all of GitHub), open the search input, type your query, and select "Search all of GitHub" from the dropdown menu or press enter.

After clicking the "Search all of GitHub" button, you'll be directed to a page displaying all results related to your query.

How to Do a Scoped Search (for a Particular Repo or Organization)

To search within a specific repository or organization, go to the repository or organization page, enter your query in the search field at the top, and press Enter.

For instance, if you're searching for a file name starting with "pnpm" in the frontendweb repository:

In the search bar, you'll see four suggestions: the first is "Search in this repository," the second is "Search in this organization," the third is "Search all of GitHub," and the last is the code section "Display similar files." Clicking a file opens it in the GitHub web editor.

Advanced Search Functionality

In addition to the GitHub search bar, you can search on GitHub using the advanced search page.

GitHub's advanced search allows you to find specific code, repositories, and issues. You can filter your searches by factors such as the number of stars, owners, forks, followers, programming language, and creation dates.

As you complete the advanced search fields, your query is automatically generated in the top search bar, and you can click on the Search button.

For a basic example, let's search for React on GitHub, including recent pull and push requests, issues, commits, discussions, and so on, related to ReactJS. We can use GitHub's advanced search functionality for this. Type "React" in the first input field as text and add the owner, in this case, Facebook, to find everything related to ReactJS in the Facebook organization or user.

After clicking on the Search button, you should see the following results page:

As you can see, GitHub's advanced search functionality lets you find specific code, repositories and issues using a powerful set of qualifiers and options. Let's talk more about qualifiers now.

Search Qualifiers

You can filter your search directly using various key qualifiers. We can divide these qualifiers into different sections:

Advanced Options

• From these owners: type the specific user's or organization's name, such as GitHub, Atom, Electron, Octokit, and so on.

• In these repositories: type the specific user's or organization's name, such as Facebook/React, Vercel/Next.js, and so on.

• Created on these dates: Specify the repository creation date, for example >2016-04-29, =2016-04-29, etc., to learn more, check out the Query for dates documentation.

• Written in this language: Select the specific language that matches repositories from lists: JavaScript, TypeScript, Rust, and so on, or what it’s written in.

Repository Options

• With this many stars: Type the number of stars in the stars: field to filter and find repositories by star count. You can apply comparisons like >1000 (more than 1000 stars) or =1000 (exactly 1000 stars) to narrow results based on popularity.

• With this many forks: Type the number of forks to filter and find repositories by fork count. You can apply comparisons like 100..1000 (find repos with 100 to 1000 forks), >1000 (more than 1000 forks), or =1000 (exactly 1000 forks) to narrow results based on popularity.

• Of this size: type the repository size in KB to filter and find repositories, for example, size of 10000 KB

• Pushed to: type the date to filter and find repositories, for example >2013-02-01 matches repositories with the word "react" that were pushed to after January 2013.

• With this license: Select the license to filter or find repositories based on license, for example, those licensed under the Apache License 2.0.

Code Options

• With this extension: type the extension, such as rb, py, or jpg, that you want to search on GitHub.

• In this path: Type the path to filter on GitHub to search for files by their location within a repository. For example, you can find a header.tsx file specifically inside the ./components folder by combining filename: with path:.

• With this file name: Type the file name, such as app, footer, or header, that you want to search on GitHub.

Issue Options

• In the state: Select the issue state (whether the issue is open or closed), for example, libraries state:open mentions:rajdeep matches open issues that mention @rajdeep with the word "libraries," or language:JavaScript state:open matches open issues in JavaScript repositories.

• With this many comments: Enter the comment number based on the comment count. You can filter the issue, for example, state:closed comments:>100 matches closed issues with more than 100 comments, or comments:500..1000 matches issues with comments ranging from 500 to 1,000.

• With the labels: Enter the label to filter or narrow your results by labels. Since issues can have multiple labels, you can list and add multiple label qualifiers for each issue.

  For example, first, label:bug label:resolved matches issues with the labels "bug" and "resolved." Second, label:bug,resolved matches issues with the label "bug" or the label "resolved." Third, example broken in:body -label:bug label:priority matches issues with the word "broken" in the body, that lack the label "bug," but do have the label "priority."

• Opened by the author: Enter the name or username to filter or find issues created by a user or integration account, or filter the issues based on the author.

  For example, author:rajdeep matches issues with the word "fixed" that were created by @rajdeep, or author:octocat matches issues created by the account named "octocat."

• Mentioning the users: Enter the name or username to find issues that mention the user. For example, fixed mentions:rajdeep matches issues with the word "fixed" that mention @rajdeep in the issue.

• Assigned to the users: Enter the name or username to find or filter issues based on the specific username assigned to the issue. For example, state:open assignee:rajdeep matches open issues that are assigned to @rajdeep.

• Updated before the date: Enter the date, filter issues based on the time of creation, or when they were last updated.

  For example language:c# created:<2011-01-01 state:open matches open issues that were created before 2011 in repositories written in C# or weird in:body updated:>=2013-02-01 matches issues with the word "weird" in the body that were updated after February 2013.

User Options

• With this full name: Enter a full name to filter repositories whose name includes “rajdeep singh” on GitHub.

• From this location: Enter a location to find users on GitHub. For example, location:russia language:javascript returns users based in Russia whose repositories are primarily written in JavaScript.

• With this many followers: Enter a follower count to filter users by popularity. For example, followers:>=1000 finds users with 1,000 or more followers, while followers:1..10 rajdeep returns users with 1–10 followers whose name includes “rajdeep” on GitHub.

• With this many public repositories: Enter a repository count to filter users by the number of public repositories they have. For example, repos:>10 finds users with more than 10 repositories, while repos:10..30 returns users who have between 10 and 30 public repositories on GitHub.

• Working in this language: Select the language to find users based on the primary languages of their repositories. For example, language:javascript location:russia returns users in Russia whose repositories are mostly written in JavaScript, while language:javascript fullname:rajdeep finds users with JavaScript repositories whose full name includes "rajdeep" on GitHub.

Wiki Options

• Updated before the date: Enter a date to filter wiki pages containing “next.js” that were last updated after 2016-01-01 in your GitHub wiki.

The best way to use advanced search qualifiers is to combine one or multiple qualifier/search options to achieve the best result.

How to Save Searches

I don't often use GitHub Advanced Search, but I used it to find open-source projects to learn from and contribute to. If you take a moment to fill in the information in GitHub Advanced Search, you can save the search for future use:

Enter the name and click the "Create saved search" button:

You can show a list of all your saved searches:

How to Manage Saved Searches on GitHub

To manage a saved search, open the search bar and type "saved:" in the search bar, then click the "Manage saved searches" button.

To edit a saved search, click the pencil icon next to it. To delete a saved search, click the trash icon.

Why Do We Need GitHub Advanced Search?

As mentioned, GitHub Advanced Search helps you find the best issues to contribute to in open source repositories.

For example, I'm an expert in Next.js and React.js, and I can use GitHub Advanced Search to locate suitable issues in open-source projects for contribution.

Even as a beginner developer, you can use GitHub Advanced Search to find "good first issues" labeled by maintainers, making it easier to contribute.

Conclusion

GitHub Advanced Search is versatile. t's not just for searching but also for researching recent issues, pull requests, and push requests that may be related to your query, repository, user, or anything else. My favorite use is finding open-source contribution opportunities with GitHub Advanced Search.

The open-source story is not slowing down. It's accelerating.

And yet, most of the teams celebrating these headlines can't run the models they're celebrating. Self-hosting GLM-5 requires roughly 1,490GB of memory.

The gap between open and proprietary AI has closed on benchmarks, but "open" and "accessible" aren't the same word. Treating them as synonyms is the most expensive mistake a team can make these days.

What follows is a look at the benchmarks that matter, the infrastructure reality the press releases leave out, and a decision framework for teams that need to ship something.

The two models at the center of this comparison are GPT-5.4, OpenAI's most capable, frontier model for professional work, released on March 5, 2026, and GLM-5, the 744-billion-parameter open-weight model from China's Zhipu AI, released on February 11.

GPT-5.4 represents the current ceiling of proprietary AI: a model that unifies coding and reasoning into a single system with a one-million token context window, native computer use, and the full weight of OpenAI's platform behind it.

GLM-5 represents something different: the first open-weight model to crack the Intelligence Index score of 50, trained entirely on domestic Chinese hardware, available for free under an MIT license.

The question now shifts from which model scores higher on a given leaderboard to what the gap between them means for teams making real infrastructure decisions.

What We'll Cover:

• What GLM-5 Achieved

• Where GPT-5.4 Still Has the Edge

• "Open" Does Not Mean "Accessible"

• The Right Question Is Not Which Model Wins

• What This Moment Means

What GLM-5 Achieved

GLM-5 is a 744-billion-parameter model with 40 billion active parameters per forward pass. It uses a sparse MoE architecture and was trained on 28.5 trillion tokens.

The model was released February 11, 2026, by Zhipu AI, a Tsinghua University spin-off that IPO'd in Hong Kong and raised $558 million in its last funding round. The license is MIT, which means it's commercially usable without restrictions.

The Artificial Analysis Intelligence Index v4.0 is an independent benchmark that aggregates 10 evaluations spanning agentic tasks, coding, scientific reasoning, and general knowledge.

Unlike single-task benchmarks, it's designed to measure a model's overall capability across the kinds of work people actually pay AI to do. Scores are normalized so that even the best frontier models sit around 50 to 57, preserving meaningful separation between them.

GLM-5 scores 50 on this index, the first time any open-weight model has cracked that threshold. GLM-4.7 scored 42. The eight-point jump came from improvements in agentic performance and a 56-percentage-point reduction in the hallucination rate.

On Arena (formerly LMArena), the human-preference benchmark initiated by UC Berkeley, GLM-5 ranked number one among open models in both Text Arena and Code Arena at launch, putting it on par with Claude Opus 4.5 and Gemini 3 Pro overall. That's a human preference, not an automated benchmark.

SWE-bench Verified: 77.8%, the number one open-source score. The only models scoring higher are Claude Opus 4.6 (80.8%) and GPT-5.2 (80.0%). On Humanity's Last Exam with tools enabled, GLM-5 scores 50.4, beating GPT-5.2's 45.5.

So GLM-5 is genuinely competitive. But competitive at what, exactly? The Intelligence Index gap tells part of the story. The rest lives in specific benchmarks where GPT-5.4 still pulls ahead.

Where GPT-5.4 Still Has the Edge

The gap is not imaginary. On the Artificial Analysis Intelligence Index, GPT-5.4 scores 57 to GLM-5's 50, tied with Gemini 3.1 Pro Preview for number one out of 427 models.

Terminal-Bench is where the gap is most evident. It measures how well a model performs real-world terminal tasks in actual shell environments: file editing, Git operations, build systems, CI/CD pipelines, and system debugging.

Unlike benchmarks that test whether a model can write code in isolation, Terminal-Bench evaluates whether it can operate a computer the way a developer does.

According to OpenAI's API documentation, GPT-5.4 scores 75.1%, a 9.7-point lead over the next proprietary model. If your team does DevOps, infrastructure-as-code, or CI/CD debugging, this benchmark maps directly to your actual job.

Context window is another differentiator. GPT-5.4 handles 1.05 million tokens, while GLM-5 caps at 200,000. For agentic workflows that need to plan across large codebases or synthesize multi-document research, this is not a spec difference but a capability difference.

Native computer use is another advantage. This means the model can interact directly with desktop software through screenshots, mouse commands, and keyboard inputs, without requiring a separate plugin or wrapper.

GPT-5.4 is the first general-purpose OpenAI model with this capability built in, while GLM-5 is text-only with no image input. If you're building agents that interact with UIs or need multimodal reasoning, you can't use GLM-5 for that.

OpenAI also claims a 47% token reduction in tool-heavy workflows through something called tool search, a real efficiency gain if you are paying per token.

On pricing, GPT-5.4 at \(2.50 per million input and \)15.00 per million output is 4.2 times more expensive than GLM-5's API. But long-context pricing doubles above 272,000 tokens to $5.00 per million inputs, a tax you'll feel if you run large-context agents.

There's a deeper issue the benchmark numbers don't capture, and it's most likely to trip up teams who rush to adopt open source.

"Open" Does Not Mean "Accessible"

The MIT license is real, and the weights are downloadable, but running GLM-5 in native BF16 precision requires roughly 1,490GB of memory. The recommended production setup for the FP8 model is eight H200 GPUs, each with 141GB of memory. That's a GPU cluster, not something you spin up on a single workstation.

In dollar terms, a used or leased H100 runs \(15,000 to \)25,000. Eight H200S is not a startup purchase. The infrastructure cost of self-hosting GLM-5 rivals or exceeds that of just calling the OpenAI API for most real-world usage volumes.

There is a quantization path. Quantization is a technique that reduces a model's memory footprint by representing its weights at lower numerical precision – for example, compressing from 16-bit to 2-bit values. It makes large models runnable on smaller hardware, but at the cost of some accuracy.

Unsloth's 2-bit GGUF reduces memory usage to 241GB, which fits within a Mac's 256GB unified memory. But quantization degrades model quality. That 77.8% SWE-bench score is for the full-precision model, and the number you get from a quantized local deployment will be lower.

The honest alternative is to use a hosted GLM-5 API. DeepInfra charges \(0.80 per million input tokens, and Novita charges \)1.00 per million input tokens. You can get the model without the hardware, but then you're not self-hosting. You're just using a cheaper API, and the data sovereignty, privacy, and vendor lock-in arguments all evaporate.

"Open weight" in 2026 increasingly means open to enterprises with GPU clusters, open to researchers with cloud credits, and open to teams willing to accept quality trade-offs from quantization. It doesn't mean open to the median developer who wants to avoid their API bill.

The paradox is real: open weights, but not open access. That doesn't mean the choice is impossible. It just means the choice has to be honest.

The Right Question Is Not Which Model Wins

The right model depends entirely on what your team is trying to optimize.

Use GLM-5 via API when cost efficiency is the primary constraint, when data residency isn't a concern for Chinese-origin models, when your workflow doesn't require multimodal or image input, and when context demands stay under 200,000 tokens.

It's also the right choice if you want to experiment with open-weight research or contribute back to it. The GLM-5 API is cheap, and if tokens per dollar is your dominant variable, it's hard to beat.

Use GPT-5.4 when your workflow is terminal-heavy or involves computer use, when long-context coherence above 200,000 tokens matters, when you need multimodal input, or when your team is already embedded in the OpenAI ecosystem.

If response consistency at scale is non-negotiable, the premium you pay is real, but for some workloads, the consistency and capabilities justify it.

Consider self-hosting GLM-5 only when your organization already has GPU cluster infrastructure or the budget to build one, when data sovereignty concerns are documented and specific rather than hypothetical, and when you have the ML infrastructure capabilities to manage deployment, updates, and monitoring. Self-hosting a 744-billion parameter model is not a weekend project.

The break-even math is worth doing. At roughly \(0.80 per million tokens via DeepInfra, a team would need to process over one billion tokens per month before self-hosting on \)15,000 H100 hardware begins to pay off. Most teams don't hit that volume, and the ones that do probably already have the infrastructure.

With this decision framework in place, the question shifts to a larger one. What does this moment mean for how teams should think about open source and proprietary AI?

What This Moment Means

The benchmark gap has closed. It's real, significant, and historic. The MMLU gap between open and proprietary models was 17.5 points in late 2023 and is now effectively zero. GLM-5, scoring 50 on the Intelligence Index, the first open-weight model to do so, is a genuine milestone.

But the way the gap closed matters as much as the fact that it closed. It closed through architectural ingenuity like DSA sparse attention, MoE efficiency, and asynchronous reinforcement learning, not through democratized compute.

The models that have closed the gap are still large, still expensive to deploy at full fidelity, and still dominated by Chinese labs with significant institutional backing.

The proprietary moat is no longer because they have better models. It's now a better platform, a better ecosystem, a better context window, better enterprise support, and a deployment path that doesn't require a GPU cluster. It's a narrower moat, but it's still a moat.

The question for 2026 is not whether to choose open source or proprietary. It's what you're getting for the premium you pay, and whether that's worth it for your specific workflow. For some teams, the answer will flip. For many, it won't yet.

Most teams reading this won't do the math. They'll see "open source" and assume it means cheaper. They will see "GLM-5 matches GPT-5.4 on benchmarks" and assume they can swap one for the other with no trade-offs.

Those assumptions are how you end up with a $50,000 GPU cluster you don't know how to operate, or a production outage because your quantized model can't handle long context.

The gap between what a benchmark says and what a model does in your actual environment is where engineering judgment lives. If you outsource that judgment to headlines, you're not saving money. You're just deferring the cost until it shows up as an incident.

Curious about the hype I saw on Bluesky, I recently joined the npmx Discord server on a whim. My journey from lurker to contributor taught me a lot about OSS and gave me new confidence going into code reviews.

In this article, I’ll walk you through my journey to give you a little insight into the process of getting involved in Open Source.

Here’s what I’ll cover:

• My Struggles with Pull Requests

• My Former View of OSS

  • The Basics of OSS

  • The Dark Side of OSS

• Getting Started with npmx

• The Not So Perfect PR

• Collaboration Over Perfection

• My Current View of OSS

• Tips for PR Authors and Reviewers

• Conclusion

My Struggles with Pull Requests

I’ll admit, I’ve always had a hard time with code reviews. I can be quite the perfectionist. I’ll entertain every nitpick and only hear the criticism.

If reviews go on for days, I easily get overwhelmed. I enjoy pairing and co-working. I want to enjoy Pull Request (PRs), but addressing PR comments takes a lot out of me.

Some of my struggle is a need for accommodations that I rarely get. I also have plenty of lived experience with how hostile code reviews can become (even in a professional setting). Finally, there’s how I was introduced to PR reviews.

Outside of work, I had only ever experienced perfunctory PRs – I’d receive at most one suggestion, but usually just got a “LGTM” (Looks Good to Me) comment. Professionally, I went from no code reviews to incredibly detailed code reviews basically overnight. I still feel like I’m playing catch up.

On the one hand, thinking deeply about every suggestion has made me a better developer. I thrive in collaborative environments with thoughtful code reviews. Developers who have worked with me have told me that they benefit from answering all my “why?” questions.

On the other hand, I demand compliments, gifs, and video calls from my reviewers. I don’t do well with a bombardment of vague comments on my PRs. I’ve spent a lot of time documenting code guidelines and review processes that other people seem to understand and remember much more easily than I do.

Developer communities have helped me navigate all of this. Community is a priceless resource for career changers and new grads. When everyone shares their experience, the uninitiated learn about how things could be and what kinds of things aren’t normal (like very hostile code reviews).

My Former View of OSS

When I’ve talked and written about developer community, I’ve recommended online networking communities, going to meetups, tech conferences, social media, writing, and posting your writing online. The one thing I haven’t written about? OSS.

My first real introduction to OSS was through the online networking group Virtual Coffee. By the end of my first Hacktoberfest, I knew the basics.

The Basics of OSS

• Find a project that interests you.

• Check the Contributing Guide.

• Claim an issue.

• Following the Contributing Guide, make a fork, write the code, and open a PR.

• The maintainer merges it.

• You did it! That’s OSS.

The Dark Side of OSS

Over time, I couldn’t help but see the “dark side” of OSS – maintainers burning out, friction between users and maintainers, corporations suddenly trying to assert control over OSS (for example, Wordpress, Ruby), and the thankless, frustrating job of maintaining a package that everyone uses but no one wants to pay for.

I have to be honest: I had begun to think of open source maintainers as Roz from Monsters Inc. – justifiably fed up with the extra work dumped on them by unappreciative people.

Meeting maintainers in-person didn’t contradict my view. Every single one had a story about burnout and lack of funding. I started to assume that anyone excited about OSS just hadn’t been in it long enough

…so my friends were quite surprised when I suddenly announced that I had joined the OSS project npmx.

Getting Started with npmx

It wasn’t the first mention of the npmx project that interested me. It wasn’t the second. It was a meme. I’ve known Daniel Roe long enough to know that he is brilliant. I like learning from people who are smarter than I am.

I reached out to Patak, and got an invite to the npmx Discord server. I was amazed by what I saw: a rapidly growing, excited, and inclusive community. I realized that I had only ever contributed to communities with at most a handful of people. My view of OSS immediately changed.

This was it. I was finally going to have fun doing PRs.

So I hopped into the npmx GitHub repository and tried to get my bearings. Very quickly, I was overwhelmed. The project moves so fast. I tried to do step 3 – claim a ticket. As far as I could tell, all the tickets were being claimed in Discord before or as they were being written.

Jono kindly welcomed me into his fork for working on the blog page, but I ran into frustrating and weird issues with running the repository (repo) locally and the pre-commit hooks. Multiple people tried to help me debug and were just as stumped as I was.

The next day, Salma arrived. The day after, she was in charge of outreach, and asked me to write a blog. Then life got in the way. I couldn’t keep my promise to context switch into a feature branch in a new repo. I felt like my only contribution was going to be a single line change on the blog page and a blog.

It didn’t help that I wasn’t happy with the blog I had started writing. I gave up on keeping up and lurked in the Discord channels. I chimed in on a few conversations, and offered to help with things like failing accessibility tests.

Four days later, the project was officially two weeks old. The maintainers announced a mandatory week of vacation – community members experienced with burnout had seen the writing on the wall. Vacation would start in 10 days, so that’s basically how long I had to get a contribution in before the alpha release.

The Not So Perfect PR

An hour later, I finally saw it – my chance to contribute code. Alex needed a toggle re-written as a checkbox. It was my time to shine. I commented on the ticket to claim it as soon as it was written. I slapped up a draft PR to show I was working on it. Predictably, my focus was once again pulled away from the repo.

A couple days later, Knowler reviewed my draft PR, and all my PR anxieties came tumbling back. This was going to be The Perfect PR. How dare anyone look at it before I was ready to defend my work. What would they think about my abilities looking at my old copy and pasted portfolio site code that I hadn’t even finished translating from React to Vue? I was legitimately embarrassed someone was looking at my code in that state.

Fueled by embarrassment and productive procrastination, I sprung into action. In what little free time I had, I must have toggled my toggle a thousand times. Three days later, it was finally in a state I was happy with. It was time to open up my PR for review.

A couple dozen comments came in. Overwhelmed, I tried to remember that I had asked for this. I resolved most of the comments and left a comment saying I’d get to the last item, forced colors mode, in the morning. Frustrated with the code for the forced colors and myself for forgetting a few tiny things, I went to play games with friends.

A few hours later, I got a DM from Daniel. He had some code for my PR. I agreed with his reasoning for all the changes and found out an entire tooltip had been added while I was blissfully ignoring the rest of the repo. (I’m confident in my ability to merge or rebase my way out of any situation.)

Splitting my attention between Enshrouded and talking to Daniel, I felt defeated. I knew I finish the forced colors fix the next day, but also adding a tooltip felt daunting. Still, it felt like I needed to do it all.

Collaboration Over Perfection

And then I remembered, this wasn’t work and it wasn’t going to come up on a performance review. I wasn’t alone – Knowler and Daniel were taking the time to help me get this PR merged because they wanted to. I had the opportunity to collaborate with some brilliant people and see how they would write the same thing.

So I pushed through my perfectionism, demanded compliments, and asked Daniel to push his changes. I told him I’d review them in the morning.

Reviewing Daniel’s code, I found that he had forgotten a couple tiny things, just like I had. The code I was frustrated with the night before was legitimately frustrating. Emulating forced colors on a Mac was giving me weird and contradictory results. I needed to test on a Windows machine to finally get it right.

Then, six days after I opened the PR, I finally merged it. I was on top of the world. I had gotten my contribution in before our vacation (and more importantly, I had received multiple compliments). Finally, I knew what to write this blog about.

My Current View of OSS

When you’re looking for a project that interests you, the code isn’t the only thing to evaluate. Early in my career, I learned three rules for evaluating software tools.

1. Check the date of the last update to make sure it’s actively maintained.

2. Look at the documentation. Is it up to date and easy to follow?

3. Check out the community. Do people get fairly quick responses to their questions?

After joining npmx, I’ve discovered that, with a few tweaks, these rules also apply to evaluating an OSS project.

1. Check out the last few tickets and PRs to see how fast the repo moves. If it’s fairly slow, you can probably claim an issue in GitHub easily. If it’s rapid, start by getting to know the community and how they’re assigning tickets.

2. You should always check the repo for a code of conduct, contributing guide, and sufficient documentation. Also evaluate the tickets. Are contributors expected to research solutions on their own or given strict requirements? How do maintainers respond to comments on issues?

3. Check out the community. An active, inclusive community makes contributing a lot more fun.

Now, my view of OSS is much more nuanced. Yes, there are issues with OSS as whole, but there’s a reason people want to fix them. OSS can be collaborative, inspirational, and enjoyable.

Tips for PR Authors and Reviewers

People underestimate the importance of the relationship between PR author and reviewer. A collaborative OSS code review process doesn’t happen in a vacuum. It takes careful cultivation by the PR author, PR reviewer, and project community.

For a long time, I focused on the responsibility of the reviewer to make the PR author comfortable (for example, compliments, gifs). Don’t get me wrong – I think one of the most important parts of a senior developer’s job is to provide constructive, actionable feedback.

But I now understand that the PR author’s sense of agency and desire to learn are just as important.

A sense of agency is a sense of control over actions and consequences. In other words, the PR author needs to feel that they have control over what goes into their PR. Before npmx, I understood this a little bit. I always ask “why?” because I’m not putting my name on code that I don’t understand and agree with. I have counseled my own junior developer that it’s his job to get PRs he’s authored reviewed and merged.

After experiencing an in-depth code review outside of work, I finally understand that a PR is a process. Reviews exist to get consensus, so “perfect” is far more subjective than I originally thought. There’s a reason you get a conversation, not a grade.

Maybe I’ll even ignore some nitpicks in the future.

A desire to learn makes remaining open to a reviewer’s suggestions and requests a lot easier. During my first npmx PR, it was only when my desire to learn outweighed my desire to prove something that I started having fun.

Conclusion

Today, March 3rd, 2026, is the alpha release of npmx, and I am very proud to be a contributor and member of the community.

I look forward to learning about OSS from Patak, fancy, smart code from Daniel, outreach from Salma, and accessibility from Knowler. I know I’ll learn many things outside of that list, too. I’m grateful I’m not the smartest person in the room and that I finally get to have fun with Pull Requests.

This guide will show you how to set up an open-source LLM locally, explain the tools involved, and walk you through both the UI and command-line installation methods.

What We’ll Cover

• Understanding Open Source LLMs

• Choosing a Platform to Run LLMs Locally

• How to Install Ollama

• How to Install and Run LLMs via the Command Line

• How to Manage Models and Resources

• How to Use Ollama with Other Applications

• Troubleshooting and Common Issues

• Why Running LLMs Locally Matters

• Conclusion

Understanding Open Source LLMs

An open-source large language model is a type of AI that can understand and generate text, much like ChatGPT, but it can function without depending on external servers.

You can download the model files, run them on your machine, and even fine-tune them for your use cases.

Projects like Llama 3, Mistral, Gemma, and Phi have made it possible to run models that fit well on consumer hardware. You can choose between smaller models that run on CPUs or larger ones that benefit from GPUs.

Running these models locally gives you privacy, control, and flexibility. It also helps developers integrate AI features into their applications without relying on cloud APIs.

Choosing a Platform to Run LLMs Locally

To run an open source model, you need a platform that can load it, manage its parameters, and provide an interface to interact with it.

Three popular choices for local setup are:

1. Ollama — a user-friendly system that runs models like OpenAI GPT OSS, Google Gemma with one command. It has both a Windows UI and CLI version.

2. LM Studio — a graphical desktop application for those who prefer a point-and-click interface.

3. Gpt4All — another popular GUI desktop application.

We’ll use Ollama as the example in this guide since it’s widely supported and integrates easily with other tools.

How to Install Ollama

Ollama provides a one-click installer that sets up everything you need to run local models. Visit the official Ollama website and download the Windows installer.

Once downloaded, double-click the file to start installation. The setup wizard will guide you through the process, which only takes a few minutes.

When the installation finishes, Ollama will run in the background as a local service. You can access it either through its graphical desktop interface or using the command line.

After installing Ollama, you can open the application from the Start Menu. The UI makes it easy for beginners to start interacting with local models.

On the Ollama interface, you’ll see a simple text box where you can type prompts and receive responses. There’s also a panel that lists available models.

To download and use a model, just select it from the list. Ollama will automatically fetch the model weights and load them into memory.

The first time you ask a question, it will download the model if it does not exist. You can also choose the model from the models search page.

I’ll use the gemma 270m model which is the smallest model available in Ollama.

You can see the model being downloaded when used for the first time. Depending on the model size and your system’s performance, this might take a few minutes.

Once loaded, you can start chatting or running tasks directly within the UI. It’s designed to look and feel like a normal chat window, but everything runs locally on your PC.

You don’t need an internet connection after the model has been downloaded.

How to Install and Run LLMs via the Command Line

If you prefer more control, you can use the Ollama command-line interface (CLI). This is useful for developers or those who want to integrate local models into scripts and workflows.

To open the command line, search for “Command Prompt” or “PowerShell” in Windows and run it. You can now interact with Ollama using simple commands.

To check if the installation worked, type:

ollama --version

If you see a version number, Ollama is ready. Next, to run your first model, use the pull command:

ollama pull gemma3:270m

This will download the Gemma model to your machine.

When the process finishes, start it with:

ollama run gemma3:270m

Ollama will launch the model and open an interactive prompt where you can type messages.

Everything happens locally, and your data never leaves your computer.

You can stop the model anytime by typing /bye.

How to Manage Models and Resources

Each model you download takes up disk space and memory. Smaller models like Phi-3 Mini or Gemma 2B are lighter and suitable for most consumer laptops. Larger ones such as Mistral 7B or Llama 3 8B require more powerful GPUs or high-end CPUs.

You can list all installed models using:

ollama list

And remove one when you no longer need it:

ollama rm model_name

If your PC has limited RAM, try running smaller models first. You can experiment with different ones to find the right balance between speed and accuracy.

How to Use Ollama with Other Applications

Once you’ve installed Ollama, you can use it beyond the chat interface. Developers can connect to it using APIs and local ports.

Ollama runs a local server on http://localhost:11434. This means you can send requests from your own scripts or applications.

For example, a simple Python script can call the local model like this:

import requests, json

# Define the local Ollama API endpoint
url = "http://localhost:11434/api/generate"

# Send a prompt to the Gemma 3 model
payload = {
    "model": "gemma3:270m",
    "prompt": "Write a short story about space exploration."
}

# stream=True tells requests to read the response as a live data stream
response = requests.post(url, json=payload, stream=True)

# Ollama sends one JSON object per line as it generates text
for line in response.iter_lines():
    if line:
        data = json.loads(line.decode("utf-8"))
        # Each chunk has a "response" key containing part of the text
        if "response" in data:
            print(data["response"], end="", flush=True)This setup turns your computer into a local AI engine. You can integrate it with chatbots, coding assistants, or automation tools without using external APIs.

Troubleshooting and Common Issues

If you face issues running a model, check your system resources first. Models need enough RAM and disk space to load properly. Closing other apps can help free up memory.

Sometimes, antivirus software may block local network ports. If Ollama fails to start, add it to the list of allowed programs.

If you use the CLI and see errors about GPU drivers, ensure that your graphics drivers are up to date. Ollama supports both CPU and GPU execution, but having updated drivers improves performance.

Why Running LLMs Locally Matters

Running LLMs locally changes how you work with AI. You’re no longer tied to API costs or rate limits. It’s ideal for developers who want to prototype fast, researchers exploring fine-tuning, or hobbyists who value privacy.

Local models are also great for offline environments. You can experiment with prompt design, generate content, or test AI-assisted apps without an internet connection.

As hardware improves and open source communities grow, local AI will continue to become more powerful and accessible.

Conclusion

Setting up and running an open-source LLM on Windows is now simple. With tools like Ollama and LM Studio, you can download a model, run it locally, and start generating text in minutes.

The UI makes it friendly for beginners, while the command line offers full control for developers. Whether you’re building an app, testing ideas, or exploring AI for personal use, running models locally puts everything in your hands, making it fast, private, and flexible.

Hope you enjoyed this article. Signup for my free newsletter TuringTalks.ai for more hands-on tutorials on AI. You can also visit my website.

This article will guide you through the basics of npm, explain how it functions behind the scenes, and demonstrate step-by-step how to create and publish your own npm package to the official npm registry. Whether you’re a beginner just starting with JavaScript or a seasoned developer who has used npm but never published a package, this guide will help you confidently navigate the entire process, from setup to sharing your code with the global developer community.

Table of Contents

• What is npm?

• Components of npm

• The Command Line Interface

• The Registry

• The Website

• What is the Package.json File?

• How npm Works

• How to Publish an npm Library

• How to Verify and Install Your Package

• How to Update Your Package

• Notes and Best Practices

• Beyond the Basics

• Conclusion

What is npm?

npm, which stands for Node Package Manager, is a command-line tool for installing and managing JavaScript packages. It is an ecosystem that powers modern JavaScript development (Node.js, frontend tools, frameworks, and so on). Developers use npm to share and borrow packages, and many organizations use npm to manage private development.

Essentially, npm is to JavaScript what pip is to Python or Maven to Java. It enables developers to reuse code written by others (most of the time to fulfil a function in their project), manage dependencies, and share their own code with the world.

You can use npm to:

• Get and utilize code packages in your applications, either as-is or with custom modifications.

• Download and run standalone tools instantly.

• Execute packages directly from the registry without installing them using npx.

• Share your own code with developers around the world through the npm registry.

• Limit access to specific packages so only approved developers can use them.

• Create organizations to manage code, teams, and packages in one place.

• Collaborate as virtual teams using shared organizational accounts.

• Handle different versions of packages and their dependencies with ease.

• Keep your applications up to date by syncing with the latest package updates.

• Explore different packages that offer various solutions to the same problem.

• Connect with developers working on similar challenges and projects.

Components of npm

npm consists of three core components:

• The command line interface (CLI)

• The registry

• The website

The Command Line Interface

There are different npm commands you can run on your terminal. For example, npm init can be used to initialize a Node project, npm install can be used to install a package. It also allows you to do things like:

• Publish packages (npm publish)

• Update packages (npm update)

• Manage versioning (npm version)

• Run scripts (npm run build, npm test, and so on)

Think of it as your control panel.

The Registry

You can find the huge public database at https://registry.npmjs.org, where packages are stored and shared. It also contains all the meta-information surrounding the package.

Example, when you run:

npm install express

npm fetches the Express package from the registry.

The npm registry enables collaboration by allowing developers to:

• Publish their own packages

• Install packages created by others

• Discover new tools and libraries

Its collaboration features include:

• Open-source packages: The code is publicly visible (usually hosted on GitHub).

• Versioning: Multiple versions of the same package let users safely adopt updates.

• Scoped packages: Namespaces allow teams and organizations to manage ownership.

• Issues & pull requests: Most npm packages link to GitHub, allowing developers too contribute fixes and enhancements.

• Organisations: Teams can manage access to shared private or public packages.

The Website

At https://www.npmjs.com, this is where you can:

• Browse packages.

• Read documentation.

• View download stats and dependencies.

• Create and manage your account, organization, and package access.

What is the Package.json File?

A very important component of any npm tool that you’ll come across as a JavaScript developer installing an npm package, is the package.json file. It is a metadata file that lives at the root of every npm or Node project. It tells npm (and other tools) everything it needs to know about your project, like:

• What the project is called.

• What it depends on

• How to run it

• How to version it

• and how to publish it

You can think of it like the blueprint of your JavaScript project. Without it, npm doesn't know how to work with your code.

You can create a package.json file by typing the command npm init in your terminal and filling in the prompts provided. Alternatively, you can create a file named package.json and manually populate it with JSON content.

Key Fields in an npm package.json File

The following is a list of commonly used fields and how they interact with npm:

1. name and version

    "name": "my-awesome-package",
    "version": "1.0.0"
   

   • This is required for publishing.

   • name must be unique (if publishing to the public npm registry).

   • version follows semantic versioning (semver) (for example, major.minor.patch).

2. description, keywords, author, and license

    "description": "A utility to convert markdown to HTML",
    "keywords": ["markdown", "html", "converter"],
    "author": "Ikegah Oliver",
    "license": "MIT"
   

   • Helps npm users discover your package

   • Show up on npmjs.com.

   • Sets collaboratory license

3. scripts

    "scripts": {
      "start": "node index.js",
      "test": "jest",
      "build": "tsc"
    }
   

   • Defines custom commands.

   • Run with npm run test, npm run build, and so on.

   • Automates build, test, lint, deploy processes.

4. main and exports

    "main": "dist/index.js",
    "exports": {
      ".": "./dist/index.js"
    }
   

   • main: Entry point for require() or import.

   • exports: Controls exactly what parts of your package are exposed (especially useful for modern ESM and package security).

5. dependencies and devDependencies

    "dependencies": {
      "express": "^4.18.2"
    },
    "devDependencies": {
      "eslint": "^8.0.0",
      "jest": "^29.0.0"
    }
   

   • dependencies : Core packages your project needs to run in production (for example, express).

   • devDependencies : Packages used only during development, like testing or build tools (for example, jest).

6. engines

    "engines": {
      "node": ">=14.0.0"
    }
   

   • Specifies Node.js version your package supports.

   • Helps warn users before they install with an unsupported version.

7. private

    "private":"true"
   

   • Prevents accidental publishing to the public npm registry.

   • Used for monorepos and internal-only projects.

8. files (optional)

    "files":["/dist", "README.md"]
   

   • Controls what files get included when you run npm publish.

   • Reduces package size, omits build artifacts or test files.

A minimal npm package.json file looks like this:

{
  "name": "@oliver/markdown-to-html",
  "version": "1.0.0",
  "description": "Converts markdown to HTML with styles",
  "main": "dist/index.js",
  "scripts": {
    "build": "tsc",
    "test": "jest"
  },
  "keywords": ["markdown", "html", "converter"],
  "author": "Ikegah Oliver",
  "license": "MIT",
  "dependencies": {
    "marked": "^5.0.0"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  },
  "engines": {
    "node": ">=14.0.0"
  },
  "files": ["dist/", "README.md"]
}

The package.json file plays a central role in every npm workflow. It defines your project's identity, lists its dependencies, specifies useful scripts, and outlines how the package should behave when published. Without it, npm can't properly install packages, run commands, or publish your code to the registry.

How npm Works

When you type npm install in your terminal, npm initiates a behind-the-scenes process to install the necessary packages for your project. Depending on how you run the command, the process varies slightly as follows:

Method 1 - package.json Already Has Dependencies

If your package.json lists packages under dependencies or devDependencies, npm will:

1. Read those entries: It looks at the names and version ranges of each dependency.

2. Contact the registry: npm queries https://registry.npmjs.org to fetch metadata about each required package.

3. Download the correct versions: It selects versions that match your version rules (such as ^4.17.0) and downloads the .tgz files.

4. Unpack and install: It places the packages into the node_modules directory and caches them.

5. Update package-lock.json: It logs the exact versions and dependency tree in this file to ensure consistent installs later.

Method 2 - You Run npm install <package-name> Without Existing Dependencies

If your package.json doesn't have any dependencies yet and you run something like this in your terminal:

npm install express

Then npm will run:

1. Resolve the package version: It fetches the latest version of Express (unless you specify a version manually).

2. Download and install: The tarball is downloaded and placed in the node_modules/ folder that is automatically generated. A tarball is the zipped-up version of the package (express in this case), containing the package’s JavaScript files, a package.json, a README, and anything else the author included for distribution that npm downloads and extracts onto your machine.

3. Add to package.json: npm automatically adds the package to your dependencies list like this:

"dependencies": {
  "express": "^4.18.2"
}

4. Create a package-lock.json (if it doesn't exist): It writes all the version info to lock things down for future installs.

Note: If you run npm install --save-dev jestIt’ll add the package under devDependencies instead.

How to Publish an npm Library

To follow through with this guide section, you will need to have the following prerequisites:

• Stable network connection

• A code editor with a terminal (like VSCode)

• Basic knowledge of JavaScript and Node

• A basic understanding of the Markdown Markup language (for README documentation)

Now, let’s dive into publishing an npm library. Assuming you just built and tested a fantastic JavaScript tool that you would like to share with the world, and allow people to use it in their projects and applications, the steps below will guide you from having the tool on your local machine to making it publicly available as an npm package for anyone to install and enjoy:

Step 1: Create a free npm account

Before publishing, you will need an npm account.

• Go to https://www.npmjs.com/signup.

• Fill in the form with your username, email, and password.

• Confirm your email address by clicking the link in the verification email.

Step 2: Log in from the Command Line

Once you’ve created your account, you need to log in through your terminal. Run:

npm login

npm will prompt you for your username, password, and email address. If everything is correct, npm will generate an authentication token and store it locally, so you don’t have to log in every time.

Step 3: Create a package.json file

If your project doesn't already have a package.json file, create one by typing this command in your terminal:

npm init

You will be prompted to fill in the following information:

• name: Must be unique if it’s public.

• version: Start with 1.0.0 (it represents the first version of your project; subsequently, you will change it accordingly after each update push)

• description: One-line summary of your package.

• entry point: Entry file of your project, usually index.js or dist/index.js.

• keywords: Help others discover your package.

• author: Your name or GitHub handle.

• license: Use MIT, ISC, or another open-source license.

When you’re done, npm will generate a package.json like this:

{
  "name": "my-awesome-package",
  "version": "1.0.0",
  "description": "A demo package for npm publishing",
  "main": "index.js",
  "keywords": ["demo", "npm", "tutorial"],
  "author": "Your Name",
  "license": "MIT"
}

Step 4: Add a README.md

Explain what your package does and how to use it in a README.md file. The README appears on your package page on npmjs.com. Example content:

# my-awesome-package

A simple package that says hello.

## Usage

```js
const greet = require('my-awesome-package');
console.log(greet('Oliver'));
// Output: Hello, Oliver!

Step 5:Add an .npmignore file

This will exclude folders like node_modules, dist, or .env, and any other file or folder within the package you don’t wish to publish. Example content:

node_modules
.env
dist

Step 6: Check if the package name you chose is available

Before publishing, check if the package name you chose is not already taken. To check, run this command on your terminal:

npm search my-awesome-package

Or enter the URL https://www.npmjs.com/package/my-awesome-package in your browser (replace my-awesome-package with the name you chose). If no package page shows up, the name is not taken.

If the package name has been taken, change it in your package.json and any documentation (README.md), the name is reflected, or publish it under a scope. A scope is like a namespace tied to your npm username or organization. It ensures your package name is unique, even if the base name is common. For example, if my-awesome-package is taken, you can publish under a scope by setting the name section in its package.json like this:

{
  "name": "@yourname/my-awesome-package"
}

Step 6: Publish your package

You are now ready to publish. Run:

npm publish

If you used a scoped name, when publishing, you must make it public:

npm publish --access public

If everything is valid, npm will publish your package and give you a URL like:

https://www.npmjs.com/package/my-awesome-package

How to Verify and Install Your Package

Visit your project page on npm to see it live. For example: https://www.npmjs.com/package/my-awesome-package, or search your project name on the npm website search bar.

Now, try installing it in a node project:

npm install my-awesome-package

Test out its features and functionalities, depending on what it is built to do.

How to Update Your Package

If you make changes or update features in your package, you can publish the update.

After applying your changes, you can update the version in your package.json. Using semantic versioning, you can update it as follows:

• Patch update: 1.0.0 → 1.0.1

• Minor update: 1.0.0 → 1.1.0

• Major update: 1.0.0 → 2.0.0

Or you can use the CLI:

npm version <update_type>

Replace <update_type> with your new semantic version.

Now run:

npm publish

Notes and Best Practices

Although publishing to npm is straightforward, you still need to follow best practices to maintain a clean, secure, and user-friendly package.

• Exclude Sensitive Files: Never include .env, credentials, or secrets. Use .npmignore or the "files" field in package.json to control what gets published.

• Test Before Publishing: Run npm pack to preview the package and install it locally in another project to ensure everything works.

• Unpublish Carefully: You can unpublish within 72 hours using npm unpublish --force, but avoid doing this frequently to prevent breaking other projects that rely on your package.

• Always Bump the Version: npm won’t let you overwrite a version, so use semantic versioning (npm version patch|minor|major) before publishing updates.

• Add Essentials: Include a clear README.md file, a license, and relevant keywords to make your package discoverable and easy to use.

Beyond the Basics

Now that you've got the hang of the basics, you can put your npm skills to work and level up as a developer. Here are some simple, practical steps you can take:

Get Involved in Open Source

One of the best ways to gain real-world experience is by contributing to existing projects on npm. Check out their repositories on GitHub and GitLab and see how you can contribute to them. This teaches you how to collaborate, handle code reviews, and manage versions. A great way to start is by looking for projects on GitHub with a "good first issue" label.

Maintain Your Own Package

Publishing is just the first step. To truly master the process, keep your package up to date. This involves fixing bugs, listening to user feedback, and adding new features. You will quickly learn about versioning, ensuring your package remains compatible with older projects, and effectively manage dependencies.

Dig into Advanced Features

Explore advanced npm topics like semantic versioning, using private packages, creating scoped packages, and automating your releases with CI/CD pipelines. These are essential skills for any professional developer.

Taking these steps will help you transition from merely understanding npm to confidently utilizing it in real-world scenarios.

Conclusion

Congratulations! You have now learned the essentials of npm from the package.json file to publishing and maintaining a JavaScript package with the npm library. With this knowledge, you can share your JavaScript tools with the world, collaborate with other developers, and contribute to the growing ecosystem of open-source libraries.

By following best practices, testing locally, and learning from standard errors, you can confidently create packages that are clean, secure, and useful for other developers. Whether you’re building a small utility or a full-fledged framework, publishing on npm gives your ideas visibility and helps you contribute to the wider JavaScript community.

If you’d like to get hands-on experience collaborating on a real package, I published an npm project called route-pilot, a powerful CLI tool for testing and analyzing Express.js routes in your Node.js applications. I’m actively seeking contributors who want to enhance the code, add new features, or refine the documentation. It’s a simple way to practice working with npm in a collaborative setting while learning more about open-source development. Head over to the GitHub repo and join in. We’d love to have you on board!

I built the first version of freeCodeCamp's website in 2014. And now more than half a million people use freeCodeCamp every day.

Our tiny charity is able to help so many people thanks to clever use of technology and the help of thousands of volunteers.

In this brief article, I'll tell you how you can support our mission by donating. And I'll give you all the information you need to get involved.

How transparent is freeCodeCamp.org?

Very. We have a Platinum transparency rating from GuideStar.org.

You can download our IRS Determination Letter here.

And you can download our most recent 990 (annual tax report) here.

How efficient is freeCodeCamp?

freeCodeCamp's budget is much smaller than most comparable charities. Part of that is because I am admittedly bad at fundraising. We haven't brought in professional fundraisers. Instead, I just do everything myself.

Am I a fool for doing this? Maybe. But I can look you in the eye and tell you exactly where all the money is going, because I oversee everything myself.

I can also tell you that – on a budget of only a few hundred thousand dollars per year – we have been able to help millions of people.

What's the most common way people support freeCodeCamp?

You can set up a simple \(5 / month donation to our charity here. We are a very donation-efficient charity, and every \)5 you donate will help us provide more than 250 hours of learning to people around the world.

More than 11,000 kind people support us this way every month.

Depending on where you are in the world, $5 per month may not seem like much money. But it does add up, and this monthly approach makes it easier for our charity to budget its mission.

How can I make a one-time donation?

If you'd prefer to make one-time donations, you can support freeCodeCamp's mission whenever you have cash to spare. You can use this link to donate whatever amount feels right through PayPal.

If you'd prefer to use a credit card to make a one-time donation, here are some quick links you can use. Just click the "checkout" button and you can input your information securely into Stripe (only they will see your credit card information):

• Make a one-time donation of $20

• Make a one-time donation of $65

• Make a one-time donation of $100

Does freeCodeCamp accept donations in Bitcoin or other cryptocurrencies?

Yes, and we would welcome your cryptocurrency donations. Please email quincy@freecodecamp.org and he can give you a wallet address for whichever currency you'd like to donate.

Can I mail a physical check?

Yes, we would welcome a check. You can mail it to us at:

Free Code Camp, Inc.
3905 Hedgcoxe Rd
PO Box 250352
Plano, TX 75025

How can I set up matching gifts from my employer, or payroll deductions?

This varies from employer to employer, and our charity is already listed in many of the big donation-matching databases.

Some people are able to volunteer for freeCodeCamp and their employer matches by donating a fixed amount per hour they volunteer. Other employers will match any donations the donors make up to a certain amount.

If you need help with this, please email me directly: quincy@freecodecamp.org.

How can I set up an Endowment Gift to freeCodeCamp.org?

This would be a huge help. Since this is a more manual process, I can help walk you through it personally. Please email me directly at quincy@freecodecamp.org.

How can I donate stock to freeCodeCamp.org?

We would welcome your stock donations. Please email me directly and I can help you with this, and share our charity’s brokerage account details: quincy@freecodecamp.org.

How can I set up a Legacy gift to freeCodeCamp.org?

We would be honored to put such a gift to good use helping people around the world learn to code. Depending on where you live, this may also be tax exempt.

You can add this language, or something like it, to your will:

I give, devise, and bequeath [the sum of _____ USD (or other currency) OR _____ percent of the rest and residue of my estate] to freeCodeCamp.org (Free Code Camp, Inc. tax identification number 82-0779546), a charitable corporation organized under the laws of the State of Delaware, United States, currently located at 3905 Hedgcoxe Rd, PO Box 250352, Plano, Texas, 75025 United States, to be used for its general charitable purposes at its discretion.

And I'd like to thank the Wikimedia Foundation for providing this formal language for us to use.

Again, if you have any questions about this process, please email me at quincy@freecodecamp.org.

Can I donate Microsoft Rewards points or Bing points?

Yes. If you use Microsoft Rewards, you can donate your points to freeCodeCamp through Give with Bing. These are sometimes called Bing points or Microsoft points.

You can use this Give with Bing link for Free Code Camp, Inc. to make a one-time points donation, or you can set up a monthly recurring donation of your points.

This does not charge your credit card. Microsoft converts your points redemption into a cash donation through Benevity, and those donations help support freeCodeCamp’s servers, services, staff, and education initiatives.

Can I get a donation receipt so that I can deduct my donation from my taxes?

Absolutely. Just forward the receipt from your transaction to donors@freecodecamp.org, and tell us you'd like a receipt and any special instructions you may have, and we'll reply with a receipt for you.

I set up a monthly donation, but I need to update or pause the monthly recurrence. How can I do this?

Just forward one of your monthly donation receipts to donors@freecodecamp.org and tell us what you'd like us to do. We'll take care of this for you and send you confirmation.

Is there anything else I can learn about donating to freeCodeCamp.org?

I think that's everything. I’m just a teacher who is still learning a lot of this as I go.

If there is some other way you'd like to support our charity and its mission that isn't listed here, or if you have any questions at all, please email me at quincy@freecodecamp.org.

I am honored by the faith you have placed in freeCodeCamp.org to be a good steward of the global developer community. We will take seriously all donations, and any questions you may have about our charity. May peace be with you.

Contributing to open source projects is not just a way to give back to the community – it's also an excellent opportunity to enhance your skills, build your portfolio, and connect with like-minded developers from around the world.

But for many beginners, the prospect of contributing to open source can be daunting. Common barriers include not knowing where to start, fear of making mistakes, or feeling intimidated by complex codebases.

This guide aims to break down these barriers and provide you with a clear path to making your first open source contribution.

What we’ll cover:

1. Understanding Open Source

2. How to Prepare for Your First Contribution

3. How to Find the Right Open Source Project

4. Understand the Project Guidelines

5. How to Make Your First Contribution

6. Best Practices for Open Source Contribution

7. Practical Tools for Getting Started

8. Continuing Your Open Source Journey

9. Conclusion

Understanding Open Source

What is open source?

Open source refers to software whose source code is freely available for anyone to view, modify, and distribute. This collaborative approach to software development has led to the creation of many powerful tools and platforms we use daily, such as Linux, WordPress, and TensorFlow.

Benefits of contributing to open source projects

Contributing to open source projects offers numerous advantages for developers. It's an excellent way to improve your skills, exposing you to diverse coding styles and best practices. Your contributions can also help you build a strong portfolio, providing tangible proof of your abilities to potential employers.

The open source community offers valuable networking opportunities, connecting you with developers worldwide and potentially leading to job opportunities or mentorships. By contributing, you also give back to the community, helping improve tools that you and others rely on daily.

Lastly, you gain insights into project management, learning how large-scale software projects are coordinated and maintained. These benefits collectively enhance your technical skills, career prospects, and understanding of the software development ecosystem.

How to Prepare for Your First Contribution

Set up your development environment

1. Choose a code editor or IDE (Integrated Development Environment) that you're comfortable with. Popular options include Visual Studio Code, Sublime Text, or JetBrains IDEs.

2. Install Git on your computer. Git is the most widely used version control system in open source projects.

Learn version control basics (Git):

Understanding Git is crucial for contributing to open source. Here are some key concepts to start with:

• Repository: A project's folder containing all files and version history.

• Clone: Creating a local copy of a repository on your machine.

• Branch: A separate line of development for new features or bug fixes.

• Commit: Saving changes to your local repository.

• Push: Uploading your local changes to the remote repository.

• Pull Request: Proposing your changes to be merged into the main project.

Take some time to practice these concepts on a personal project before diving into open source contributions.

How to Find the Right Open Source Project

Identify your skills and interests:

Start by listing your skills (programming languages, frameworks, design, documentation) and areas of interest. This will help you find projects that align with your abilities and passions.

Explore resources for finding projects:

While we'll introduce some specific tools later in this guide, here are some general platforms you can explore to find open source projects:

1. GitHub's "Explore" section

2. CodeTriage

3. Up For Grabs

4. First Timers Only

5. Your favorite software's repository (look for "good first issue" labels)

Remember, the key is to find a project you're genuinely interested in, as this will keep you motivated throughout the contribution process.

Understand the Project Guidelines

Before you start contributing to an open source project, it's crucial to understand the project's guidelines. These guidelines are typically found in files like CONTRIBUTING.md, CODE_OF_CONDUCT.md, or in the project's README file.

Read the Contribution Guidelines

The CONTRIBUTING.md file is your roadmap to becoming a valuable contributor. It usually contains information on:

• How to set up the project locally

• The process for submitting contributions

• Coding standards and style guides

• How to report bugs or suggest new features

• Communication channels for the project

For example, the popular open source library React has a comprehensive CONTRIBUTING.md file. It includes sections on:

• Code of Conduct

• Development Workflow

• Bugs

• Proposing a Change

• Sending a Pull Request

Familiarize Yourself with Project Structure and Coding Standards

Take time to understand the project's architecture and file organization. This might involve:

1. Exploring the directory structure

2. Reading documentation on the project's architecture

3. Reviewing existing code to understand the coding style

Many projects use automated tools to enforce coding standards. For instance, a JavaScript project might use ESLint for code linting. You might see a configuration file like .eslintrc.js in the project root:

module.exports = {
  "extends": "airbnb",
  "rules": {
    "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
    "no-console": "off"
  }
};

This configuration tells you that the project follows Airbnb's JavaScript style guide with a few custom modifications.

How to Make Your First Contribution

Let's walk through the process of making your first contribution, using a real-life example.

Choose an Issue

Suppose you've found an issue in the repository of a popular markdown editor. The issue is labeled "good first issue" and describes a bug where the preview doesn't update when the user types a backtick (`).

Communicate with Project Maintainers

Before starting work, you comment on the issue:

Hi there! I'm new to open source and would love to work on this issue. 
Is it still available? I'm thinking of approaching it by modifying the 
event listener for the editor component. Does that sound like a good approach?

A maintainer responds, welcoming you and confirming your approach.

Create a Fork and Work on Your Solution

1. Fork the repository to your GitHub account.

2. Clone your fork locally:

    git clone https://github.com/yourusername/markdown-editor.git
   

3. Create a new branch:

    git checkout -b fix-backtick-preview
   

4. Make your changes. For example, you might modify the editor component:

    class Editor extends React.Component {
      handleChange = (event) => {
        const { value } = event.target;
        this.props.onChange(value);
   
        // Force update preview on backtick
        if (value.endsWith('`')) {
          this.props.forceUpdatePreview();
        }
      }
   
      render() {
        // ... rest of the component
      }
    }
   

5. Commit your changes:

    git add .
    git commit -m "Fix: Update preview on backtick input"
   

6. Push to your fork:

    git push origin fix-backtick-preview
   

Submit a Pull Request

1. Go to the original repository on GitHub.

2. Click "New pull request" and select your branch.

3. Fill in the pull request template:

    ## Description
    This PR fixes the issue where the preview doesn't update when a backtick is typed.
   
    ## Changes
    - Modified the Editor component to force an update when a backtick is entered
   
    ## Testing
    1. Open the editor
    2. Type some text followed by a backtick
    3. Verify that the preview updates immediately
   
    Fixes #123
   

4. Submit the pull request and wait for feedback.

Best Practices for Open Source Contribution

Write Clear Commit Messages

Good commit messages are crucial for project maintainability. Follow these guidelines:

• Use the imperative mood in the subject line

• Limit the subject line to 50 characters

• Capitalize the subject line

• Do not end the subject line with a period

• Separate subject from body with a blank line

• Wrap the body at 72 characters

• Use the body to explain what and why vs. how

Example of a good commit message:

Fix race condition in connection pool

- Add mutex lock when accessing shared resource
- Implement retry mechanism for failed connections

This change prevents multiple threads from accessing the connection
pool simultaneously, which was causing occasional crashes in high
load scenarios. The retry mechanism improves resilience to temporary
network issues.

Document Your Changes

Clear documentation is as important as good code. Here are some best practices:

1. Update relevant README files

2. Add inline comments for complex logic

3. Update or create API documentation for new features

For example, if you've added a new function to a Python library:

def validate_email(email: str) -> bool:
    """
    Validate an email address.

    Args:
        email (str): The email address to validate.

    Returns:
        bool: True if the email is valid, False otherwise.

    Example:
        >>> validate_email("user@example.com")
        True
        >>> validate_email("invalid-email")
        False
    """
    # Implementation details...

Respond to Feedback

When you receive feedback on your pull request:

1. Respond promptly and politely

2. Address all comments, even if just to acknowledge them

3. If you disagree with a suggestion, explain your reasoning respectfully

4. Make requested changes and update your pull request

For example:

Reviewer: "Could you add a unit test for the new validate_email function?"

You: "Absolutely, that's a great suggestion. I'll add a comprehensive test suite for various email formats and edge cases. I'll push the changes shortly."

Practical Tools for Getting Started

Git Begin: Your Gateway to Open Source Contributions

To help you take your first steps in open source, I’ve developed Git Begin, a free web application designed to make finding your first contribution opportunity as easy as possible.

How Git Begin works:

1. Visit Git Begin

2. Select your preferred programming language or framework from the options provided.

3. Browse through a curated list of issues tagged as "good first issue" or "beginner-friendly" across various open source projects.

4. Each issue is presented with key information such as the project name, issue description, and required skills.

5. When you find an issue that interests you, click on it to be directed to the original issue on GitHub.

Git Begin eliminates the overwhelming process of searching through countless repositories. It presents you with targeted, beginner-friendly opportunities that match your skills and interests, making it easier than ever to start your open source journey.

A Real-World Project for First-Time Contributors

In addition to Git Begin, I’m excited to introduce you to another free, open-source project designed specifically for beginners to practice their skills and make meaningful contributions:

• Project: Job Scraper

• Description: A tool for scraping job listings from multiple company career pages

• Repository: https://github.com/The-Enthusiast-404/career-craft-scrapper

About the project:

This Job Scraper project is a crucial component of a larger, ambitious platform I’m helping develop that will revolutionize the job-seeking process. This free platform aims to be a comprehensive resource for job seekers, offering a range of tools to streamline their job search and application process.

The Job Scraper itself aggregates job listings from various company career pages, forming the foundation of our platform. But that's just the beginning. Our vision extends to creating a full-fledged ecosystem that will include:

1. A centralized job application system, allowing users to apply to multiple positions across different companies seamlessly.

2. AI-powered resume creation tools to help job seekers craft compelling CVs tailored to their target roles.

3. An innovative AI mock interviewer, capable of simulating interviews for specific roles and tech stacks, helping candidates prepare more effectively.

By contributing to the Job Scraper project, you're not only gaining valuable experience in web scraping and data processing but also playing a part in building a platform that will make a real difference in people's careers.

It's an opportunity to work on a project with immediate practical applications while also contributing to a larger vision of making job seeking more accessible and efficient for everyone.

As an open source contributor, you'll have the chance to work on various aspects of this system, from improving the scraping algorithms to potentially helping develop some of the AI-powered features in the future.

This project offers a unique blend of practical coding experience and the satisfaction of working on a tool that will directly impact job seekers worldwide.

Current contribution opportunities:

There are a number of "good first issues" available, all focused on web scraping tasks. These might include:

• Adding support for scraping job listings from a new company's career page

• Improving the data cleaning process for a specific job site

• Enhancing the scraper's resilience against changes in a website's structure

Each issue is carefully documented to help newcomers understand the task and its context within the larger project.

First Steps in Open Source

The Job Scraper project has become a welcoming entry point for many developers making their first open source contributions. To date, we've had several contributors who chose the repository for their first pull request, most of them being students eager to gain real-world experience.

These newcomers to open source have successfully added new scraping functionalities, improved existing algorithms, and enhanced our data processing capabilities.

Their achievements demonstrate that our repository is an ideal starting point for anyone looking to begin their open source journey, especially students wanting to apply their skills to a practical project.

How to get involved:

1. Visit the repository: https://github.com/The-Enthusiast-404/career-craft-scrapper

2. Read through the README and CONTRIBUTING.md files to understand the project and contribution guidelines

3. Browse the open issues labeled "good first issue"

4. Comment on an issue you'd like to work on, and I will guide you through the next steps

Remember, both Git Begin and the Job Scraper project are completely free resources. We're committed to providing a supportive environment for developers to learn and grow in their open source journey.

Continuing Your Open Source Journey

Building on your first contribution:

After making your first contribution, take some time to reflect on what you've learned. Consider:

• What aspects of the process did you find challenging?

• What new skills or knowledge did you gain?

• How can you apply this experience to future contributions?

Use these insights to guide your next steps in open source.

Become a regular contributor:

To become a regular contributor:

1. Set up project notifications to stay informed about new issues and discussions.

2. Participate in project discussions, offering insights or asking questions.

3. Take on increasingly complex issues as you become more familiar with the project.

4. Help other newcomers by answering questions or reviewing their pull requests.

5. Consider contributing to documentation or writing tests, which are often overlooked but crucial aspects of open source projects.

Explore new projects:

As you gain confidence, don't hesitate to explore new projects:

1. Look for projects in different domains to broaden your skills.

2. Consider contributing to tools or libraries you use in your daily work.

3. Explore projects with different scales - from small utilities to large frameworks.

Remember, each project offers unique learning opportunities and challenges.

Conclusion

Contributing to open source can be an incredibly rewarding experience. It allows you to improve your coding skills, collaborate with developers worldwide, and make a meaningful impact on projects used by millions of people.

Remember, everyone starts somewhere. Don't be afraid to make mistakes – they're part of the learning process. The open source community is generally welcoming and supportive of newcomers.

We hope this guide, along with tools like Git Begin and our Job Scraper project, will help you take your first steps into the world of open source contribution. Happy coding, and we look forward to seeing your contributions!

Resources:

• Git Begin: https://gitbegin.theenthusiast.dev

• Job Scraper Project: https://github.com/The-Enthusiast-404/career-craft-scrapper

• Git Documentation: https://git-scm.com/doc

• GitHub Guides: https://guides.github.com/

• Open Source Guide: https://opensource.guide/

You might be wondering why you would want to become an open source maintainer.

Well, I can tell you from my own experience that you'll learn a lot, grow your network, and meet and collaborate with people you wouldn’t have the opportunity to otherwise.

It also helps you to get a deeper understanding of the open source ecosystem – which is increasingly important, as 90% of companies use open source according to the 2022 Octoverse report.

You can see why others enjoy being a maintainer by checking out this post from GitHub education.

To be an open source maintainer means that you’re responsible for the project. You define its goals, work with contributors, and make decisions about the development and growth of the project.

Since it's your project, you can create something that’s interesting, fun, or solves a pain point in your life. Remember, it should be something you want to work on.

How to Become an Open Source Maintainer

Becoming an open source maintainer can be a really rewarding experience that allows you to grow with a community of people.

Being a maintainer means that you create a public repository on the repository hosting platform of your choice (like GitHub), and you invite others to contribute to the project.

But before we learn more about the steps to do that, let’s explore what it means to be an open source maintainer.

What Does an Open Source Maintainer Do?

An open source maintainer is responsible for overseeing the development and growth of an open source project. This could involve:

• Creating a clear process and documentation for contributors
• Reviewing and merging pull requests
• Managing issues and feature requests
• Writing and maintaining documentation
• Ensuring code quality and project consistency
• Engaging with the community and encouraging contributions

Open source maintainers perform a lot of roles, so it’s helpful to come into the project with an understanding of your strengths and weaknesses and a willingness to grow.

Support Your Project's Contributors

Before becoming a maintainer, you should understand the open source ecosystem and how to contribute to a project. Once you’ve explored some projects, you should recognize that there are valuable paths for your own contributors.

Some good ways to support your contributors include:

Create Clear Documentation

Improving existing documentation or creating new guides to help others understand the project can be a really valuable way to get people involved in your project.

This should start with your own documentation. Make sure you have a clear README and Contribution Guidelines. Let the contributors know how they can contribute, the process for getting assigned issues and submitting Pull Requests (PRs), and the best way to communicate with you.

Call Out Good First Issues

Create open issues labeled "good first issue" or "beginner-friendly" to indicate to your contributors that folks who are new to open source can start here. This could include writing documentation, making updates, fixing bugs, and more. Just make sure that you clearly write the steps for completing the issue.

Give Constructive Feedback

Offer timely, specific, and helpful feedback on contributions to help your contributors learn and grow.

Recognize Your Contributors

Recognition is not only a great motivator, but it shows appreciation to your contributors. Thank them on social media, in a blogpost, or in some other meaningful way.

Create a Welcoming Environment

Create a supportive environment for your contributors by always being respectful in your communication and including a Code of Conduct in your repository.

Provide Your Contributors with Opportunities

You can’t have contributors if you don’t provide them with opportunities. So what types of tasks can they do? While this will ultimately depend on the needs of your project, here are some common ways for contributors to support your project:

• Submitting Pull Requests: They can contribute code, documentation, or other improvements to address open issues for the project. Consider adding a PR template to make the process easier for everyone.
• Writing Issues: Contributors can identify and document bugs, create feature requests, or give you feedback on your project. Adding issue templates makes creating issues easier for both you and your contributors.
• Writing Documentation: Adding to existing documentation or creating guides, tutorials, and or blog posts to help users and contributors understand the project can be a good way to get non-code contributions and to extend awareness of your project.
• Providing Support: Having contributors help each other is a great way to strengthen your community and to take pressure off of you as the maintainer. They can answer questions, offer guidance, and help troubleshoot problems. They can also share their experiences and provide feedback to other contributors.
• Reviewing Code: Checking out pull requests and providing feedback on the submission is another great way to provide support. If you have a specific way of reviewing code, include that in your documentation to empower others to be able to do it as well.

Engage with the Community

Building relationships with your contributors is a great way to support the community, recognize their impact, and to help grow your project.

You can do this by:

• Joining Discussions: Participate in issue discussions, pull request reviews, and community forums.
• Providing Support: Answer questions, provide resources, and help new contributors find their way.
• Creating Meetings: You don’t have to do this, but it’s a good way to create engagement and provide support for your contributors, especially in the early days of your project.

Being active and supportive in your community can also help to build your reputation as a maintainer.

Learn and Adapt

Once you become a maintainer, the learning doesn't stop. You can improve your skills and adapt to new challenges by:

• Understanding Your Community: Hanging out with your community is a great way to understand your project through their perspective. It also strengthens your relationship with them and provides more opportunities to grow.
• Seeking Feedback: Regularly seek feedback from your contributors to improve your work or learn how they understand your project.
• Learning from Others: I truly believe that we all can learn from each other, no matter what stage of our journey we’re on. Look at how your community members write issues and pull requests, communicate with each other, and provide feedback.

Being a maintainer is a continuous learning journey, and the more practice you get and the knowledge you seek, the better you’ll get at it.

How to Setup Your Open Source Project

There are some key components to include when setting up your project.

Create a README

A README file introduces your project, provides setup instructions, images, code examples, and links to essential resources, and is the first impression you give to your contributors.

Here are some things you should include in your README:

• Project title and summary
• Brief setup instructions
• Images of the app and code examples
• Technologies and tools used
• Links to contributing guidelines, code of conduct, open source license, and community channels (Discord, Slack, GitHub Discussions)

Create an Installation Guide

If your project requires running code, this guide should include step-by-step instructions for forking, cloning, installing dependencies, setting up environment variables and databases, and running the project locally so new contributors can quickly get started.

Details should include:

• Forking the repository
• Cloning the repository
• Installing dependencies
• Setting up environment variables and database (if applicable)
• Running the project locally

Have an Open Source Software License

An open source license gives legal permissions for others to use, distribute, and contribute to your project. There are many different types of licenses, and choosing the right one depends on your needs. The MIT license is a popular one on GitHub.

Create a Code of Conduct

A code of conduct is important for keeping your community safe and supportive. It outlines acceptable behaviors, consequences for violations, and how to create a welcoming environment for all contributors.

Some things it might include:

• Pledge: Establishes a welcoming environment
• Standards: Acceptable and unacceptable behaviors
• Enforcement: Consequences for violations

As an example, here's freeCodeCamp's code of conduct.

Write Up Some Contributing Guidelines

These guidelines help contributors understand how to get involved, including instructions for setting up the project, reporting issues, creating pull requests, and how to communicate with maintainers.

They should include:

• Project setup instructions
• Guidelines for creating issues and pull requests
• Commit and style conventions
• Communication pathways, including links to discord, discussion boards, or other spaces for community interaction.

Takeaways

Becoming a maintainer can be a great learning experience. You don’t ever have to get it perfect, but if you treat people with respect, create clear lines of communication, and consider it a journey you’re taking together, you’ll be providing with really unique opportunities for growing and finding a community.

If you're ready to take the next step and want a comprehensive course to help you navigate the journey, check out OpenSauced’s Introduction to Maintainer Course. This course will provide you with an in-depth understanding of what it means to be a maintainer, provide you with guides to make the experience good for you and your contributors, and walk you through how to get started today.

Don't worry. I'm not tired. I love doing this, I'm going to keep working hard to share helpful learning resources with you.

I just need to make sure you're actually reading these emails. Please fill out this Google form real quick. It will take less than 1 minute.

Why I'm asking people to re-subscribe

Each week I send this email to all 7 million people who have opted in to receive it. This isn't cheap. Even with the cheapest email service on Earth (Amazon's Simple Email Service) it still costs our charity about $700 each week.

Now – I don't know exactly how many people open these emails. (Out of respect for your privacy, I refuse to add a tracking pixel or analytics to my emails, and instead send them in plain text.) But I suspect not all 7 million of you actually open them. 🙂

Again, if you want to keep getting these emails from me each week, please fill out this Google form real quick. It will take less than 1 minute.

Thanks, and happy coding! 🏕️

Unlike closed-source models like ChatGPT, Ollama offers transparency and customization, making it a valuable resource for developers and enthusiasts.

We'll explore how to download Ollama and interact with two exciting open-source LLM models: LLaMA 2, a text-based model from Meta, and LLaVA, a multimodal model that can handle both text and images.

How to Download Ollama

To download Ollama, head on to the official website of Ollama and hit the download button.

ollama homepage

Ollama supports 3 different operating systems, and the Windows version is in preview mode.

ollama download page

You can choose the executable file according to your OS and after successfully downloading the executable file, you can install it by running the executable file.

For Linux users, you have to execute the command that is being shown on the screen instead of downloading an executable file.

How to Run Ollama

To show you the power of using open source LLMs locally, I'll present multiple examples with different open source models with different use-cases. This will help you to use any future open source LLM models with ease.

So, lets get started with the first example!

How to Run the LLama2 Model from Meta

Llama 2 model is an open-source LLM model from Meta and we'll interact with it like we'd do with ChatGPT (free version), only text based interaction.

First, let's download the model using the following command:

ollama run llama2

You should see a output similar to this after the downloading of the model.

pulling manifest
pulling 8934d96d3f08... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏ 3.8 GB
pulling 8c17c2ebb0ea... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏ 7.0 KB
pulling 7c23fb36d801... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏ 4.8 KB
pulling 2e0493f67d0c... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏   59 B
pulling fa304d675061... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏   91 B
pulling 42ba7f8a01dd... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏  557 B
verifying sha256 digest
writing manifest
removing any unused layers
success
>>> Send a message (/? for help)

Now, its should ask you to send a message or prompt. Let's ask llama2 "What can you do for me?" (You can ask whatever you want).

If you asked the same question as above, then you should get a reply like this:

>>> What can you do for me?

As a responsible AI language model, I am here to assist you with any questions or tasks you may have. Here are some examples of things I can help
with:

1. Answering questions: I can provide information on a wide range of topics, from science and technology to history and culture.
2. Generating ideas: I can help you brainstorm ideas for creative projects, or provide suggestions for solving problems.
3. Writing assistance: I can help you with writing tasks such as proofreading, editing, and suggesting alternative words or phrases.
4. Translation: I can translate text from one language to another.
5. Summarizing content: I can summarize long pieces of text, such as articles or documents, into shorter, more digestible versions.
6. Creativity: I can help you generate creative ideas for stories, poems, or other forms of writing.
7. Language learning: I can assist you in learning a new language by providing grammar explanations, vocabulary lists, and practice exercises.
8. Chatting: I'm here to chat with you and provide a response to any question or topic you'd like to discuss.

Please let me know if there is anything specific you would like me to help you with.

>>> Send a message (/? for help)

So that is the response that I got from llama2.

To exit the program, you can type /exit.

Let's now run a multi-modal model where you can send an image and ask questions based on that.

How to Run the LLaVA Model

LLaVA is a open-source multi-modal LLM model. A multi-modal model can take input of multiple types and generate a response accordingly.

Using this model, we are now going to pass an image and ask a question based on that.

So, first things first, lets download the model:

ollama run llava

After successfully downloading the model, you should see something like this in the terminal:

pulling manifest
pulling 170370233dd5... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏ 4.1 GB
pulling 72d6f08a42f6... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏ 624 MB
pulling 43070e2d4e53... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏  11 KB
pulling c43332387573... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏   67 B
pulling ed11eda7790d... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏   30 B
pulling 7c658f9561e5... 100% ▕██████████████████████████████████████████████████████████████████████████████████████████▏  564 B
verifying sha256 digest
writing manifest
removing any unused layers
success
>>> Send a message (/? for help)

I'll be using this image from pexels.com.

This is the output I got from LLaVA:

>>> What's in this image? ./Downloads/test-image-for-llava.jpeg
Added image './Downloads/test-image-for-llava.jpeg'
 The image shows a person walking across a crosswalk at an intersection. There are traffic lights visible, and the street has a bus parked on one
side. The road is marked with lane markings and a pedestrian crossing signal. The area appears to be urban and there are no visible buildings or
structures in the immediate vicinity of the person.

>>> Send a message (/? for help)

You can see that its an accurate explanation of the image.

Feel free to try something else and have fun with it.

Conclusion

That's it! With Ollama, you can experiment with powerful LLMs like LLaMA 2 and LLaVA on your own machine.

Download Ollama and explore the exciting world of open-source large language models!

This article comes from my Complete LPI Open Source Essentials Exam Study Guide Udemy course and book. You can also view the video version.

What are Software Releases?

There are several types of software releases and some related versioning methods used to keep track of software changes and to communicate them to users. We'll start with releases.

• There's the alpha release – an initial version of software that is typically not feature-complete and is not intended for use by the general public. It is used for testing and internal use only.
• A beta release is a pre-release version of software that is feature-complete but may still have bugs or other issues. It is released to a limited audience for testing and feedback before the final release.
• Next will be a release candidate, which is a version of software that is considered stable and ready for release, pending final testing and bug fixes.
• And finally you'll produce a general availability release as the final version of software that's released to the general public.

What is Software Versioning?

Software versioning (sometimes known as semantic versioning) is the practice of assigning unique version numbers to different releases of software.

Here's a useful example:

vmlinuz-5.19.0-40-generic

In some approaches, the first number in the version number ("5" in this case) is the major version. A major version change indicates significant changes or new features that are not backward compatible with previous versions.

The second number ("19") is the minor version. A minor version change indicates new features or functionality that are backward compatible with previous versions.

The third number in the version number ("0") is the patch version. A patch version change indicates bug fixes or minor changes that are backward compatible with previous versions.

Why distinguish between major and minor releases? Major releases are typically used for significant changes or new features that are not backward compatible with previous versions. Major releases are usually announced to users and customers with a lot of fanfare, as they represent a significant milestone in the development of the software.

Minor releases, on the other hand, are used for smaller changes or new features that are backward compatible with previous versions. Minor releases are typically released more frequently and are intended to provide users with incremental improvements to the software.

What Does Backward Compatibility Mean?

Backward compatibility is the ability of a newer version of software or system to work with files, data, and other components created in an older version of that software or system. This means that users can upgrade to the newer version without losing access to their existing data or files.

For example, let's assume a user has created a document in an older version of a word processing program. If the newer version of the program is backward compatible, the user can open and edit the same document without any issues. This is because the newer version of the program is designed to read and interpret the file format used in the older version.

However, if the newer version of the program is not backward compatible, the user may not be able to open or edit the file created in the older version without first converting or re-creating it in the newer version. This can be a significant inconvenience for users and can lead to compatibility issues and data loss.

Here are some more quick – but important – definitions.

Feature Freeze

Feature freeze is a stage in the software development process where no new features are added to the product or project. It is typically implemented as a deadline by which all new features must be completed and approved before the release of the software product.

The primary goal of a feature freeze is to stabilize the software product in preparation for release. By setting a feature freeze deadline, developers can focus on completing and testing existing features rather than introducing new ones. This allows time for rigorous testing and bug fixing, improving the overall quality and reliability of the software product.

Roadmaps

A roadmap is a high-level strategic document that outlines the goals, objectives, and timeline for a software product's development. It provides a visual representation of the product development plan, outlining key milestones and the expected timeline for completion.

Roadmaps are useful for communicating the overall direction of a software product to stakeholders, including developers, product managers, investors, and customers.

Milestones

Milestones are specific, measurable achievements that mark progress towards the completion of a software product. They're typically set at regular intervals throughout the development process and are used to track progress and ensure that the project stays on schedule.

Examples of milestones might include the completion of a specific feature, the successful completion of a testing phase, or the release of a beta version of the software product.

Changelog

A changelog is a document that lists the changes made to a software product over time, including bug fixes, new features, and other updates. Changelogs allow developers and other stakeholders to understand what's been updated and when.

Changelogs are particularly useful for software products that are updated frequently or have a large number of contributors.

Long Term Support (LTS)

Long term support refers to a software version that is designated for longer-term support and maintenance, typically for a period of several years. During this time, the software vendor provides ongoing support, including bug fixes, security updates, and other maintenance activities.

LTS versions are often used in enterprise environments where stability and reliability are critical. In April of each even year, for example, Canonical will release an LTS version of Ubuntu. These versions are normally supported for four or five years.

End of Life (EOL)

On the other hand, end-of-life refers to a point in time when a software version is no longer supported by the vendor. This means that the vendor will no longer provide updates or fixes for the software, and any security vulnerabilities or bugs that are discovered will not be addressed. This can leave users with unsupported software that may be prone to security risks and other issues.

When a software product reaches its end-of-life, it is typically retired, and users are encouraged to upgrade to a newer version or switch to a different product. The EOL process is often gradual, with the vendor providing advance notice and guidance to users to help them migrate to a new version or product.

Conclusion

You've seen how it's important to understand the stages through which successful software projects will move. And this isn't just theoretical, because this knowledge gives you the tools to track your progress and quickly identify when things are going off rails.

This article comes from my Complete LPI Open Source Essentials Study Guide course__. And there's much more technology goodness available at bootstrap-it.com

You don't need a law degree to avoid problems, but you should definitely familiarize yourself with some basic principles.

This article comes from my Complete LPI Open Source Essentials Exam Study Guide Udemy course and book. You can also view the video version here:

We'll begin with some best practices:

• Conduct an inventory of all open source software used in your business workflow, including third-party libraries and dependencies. This will help you identify the licenses and terms of use associated with each piece of software. You'll also want to implement a system for tracking licenses and their terms of use. This can include using tools or software that automatically identify open source software and their associated licenses.
• Create a license policy that outlines the procedures and guidelines for using open source software in your business workflow. This policy should be communicated to all employees and stakeholders involved in the software development process.
• Use only approved open source licenses that comply with your license policy. This can help you avoid legal issues and ensure compliance with regulations.
• Monitor changes to open source software licenses and updates to ensure continued compliance. This can include subscribing to notifications or alerts about license changes and updating your license inventory accordingly.
• Document all steps taken to ensure compliance with open source licenses, including license reviews, approvals, and renewals. This documentation can help you demonstrate compliance in the event of an audit or legal challenge.

That sounds like a lot of work. Well, you might consider creating an Open Source Program Office. Let's see how that works.

Open Source Program Offices (OSPO)

An OSPO is an organizational unit or team within a company or organization that's responsible for managing open source software and its use within the organization.

An OSPO helps organizations effectively manage the use of open source software by providing guidelines, policies, and procedures that ensure legal and regulatory compliance, proper usage, and contribution to the open source community.

The OSPO can also help organizations to establish a strategic direction for open source use, including identifying opportunities for collaboration with other organizations or contributing to industry-wide initiatives.

Typically, an OSPO is responsible for ensuring that the organization complies with the terms of open source licenses, including understanding license obligations, tracking license usage, and managing compliance risk. It'll also work to:

• Build relationships with the open source community, contributing to projects, and promoting internal contributions to open source projects
• Develop and implement policies and governance frameworks that guide the organization's use of open source software
• Develop and execute strategic plans for open source software use within the organization
• Provide training and education to employees and stakeholders on the use of open source software, including compliance, governance, and community engagement.

There are some useful business tools that can help simplify the administration of your software resources.

Software Package Data Exchanges (SPDX)

A Software Package Data Exchange, for instance, is a standard format for exchanging data related to software packages, including open source licenses, copyrights, and other related information.

SPDX is intended to simplify the sharing of information between developers, software vendors, and other stakeholders in the software supply chain. SPDX provides a common language for describing software packages and their associated licenses, making it easier to understand the terms of use and comply with license obligations.

The primary purpose of SPDX is to promote license compliance and facilitate the management of open source software. SPDX allows developers and organizations to easily identify the open source software components in their software products and track license obligations associated with each component.

The Software Bill of Materials

A Software Bill of Materials (SBOM) is a list of all the components and dependencies that make up a software application or system. The SBOM provides information about the software's components, such as open source libraries, commercial software components, and proprietary code.

The goal of an SBOM is to improve transparency and accountability in software supply chains by providing a detailed inventory of the software components used in a product.

An SBOM typically includes information about the version, license, and origin of each component. An SBOM can help identify security vulnerabilities in a software system. By providing a complete list of all software components, developers and security teams can more easily identify and address security risks.

An SBOM can also helps ensure compliance with open source licenses and other legal requirements by providing information about the licenses associated with each component. And an SBOM can help manage supply chain risks by providing visibility into the software components used in a product. By knowing what components are used and where they come from, companies can more easily assess the risks associated with each component and make informed decisions about their use.

We should also take some time to talk about lawyers. Or, at least, the things that might get lawyers all excited. By which I mean to say that open source business models can carry legal risks, including risks related to product liability and export regulations. It's important for companies that use or distribute open source software to understand these risks and take appropriate measures to manage them.

Product Liability

Product liability is a legal concept that holds manufacturers or distributors of products liable for any harm caused to consumers by defects in the products. When a company uses or distributes open source software as part of its products, it assumes responsibility for any defects in the software that could cause harm to consumers. This could result in legal claims for product liability, which can be costly and damaging to the company's reputation.

To manage product liability risks associated with open source software, companies should implement effective quality assurance processes to ensure that the software is free from defects and meets industry standards. Companies should also work closely with their legal teams to understand the legal implications of using and distributing open source software, including any potential product liability risks.

Export regulations are another area of concern for companies that use or distribute open source software. Export regulations are laws and regulations that govern the export of goods and technology from one country to another. These regulations can restrict the export of certain types of technology or require companies to obtain licenses or certifications before exporting certain types of products.

Like any other technology, open source software can be subject to export regulations. Companies that use or distribute open source software should be aware of these regulations and ensure that their use and distribution of open source software comply with all applicable laws and regulations.

Mergers and Acquisitions

One more lawyerly thing: mergers and acquisitions can have a significant impact on the use of open source software within organizations. When two companies merge or one company acquires another, they may have different approaches to the use of open source software and different policies and practices for managing open source licensing and compliance. This can create challenges and risks related to the integration of open source software.

One potential impact is that the acquiring company may need to conduct due diligence to understand the open source licensing and compliance practices of the acquired company. This can be a complex and time-consuming process, especially if the acquired company has a large and diverse software portfolio. The merged company may also need to reconcile different approaches to open source licensing and compliance. For example, if one company has a more permissive approach to open source licensing than the other, the merged company may need to develop a new policy or approach that takes both approaches into account.

Mergers and acquisitions can also impact the use of open source software in terms of product development and innovation. For example, if the acquiring company has a different technology stack or development process than the acquired company, it may need to integrate or replace open source components used by the acquired company. This can result in delays and added costs.

And don't forget that mergers and acquisitions can also impact the open source community. If a company that is an active contributor to an open source project is acquired, the new company may change its approach to the project or reduce its contributions. This can have a negative impact on the project and the community that supports it.

Conclusion

The bottom line? Building software can be fun and profitable and can change people's lives in positive ways. But, if you're not careful, it can also get you into a lot of trouble.

So take some time to educate yourself on your business and compliance responsibilities.

This article comes from my Complete LPI Open Source Essentials Study Guide course__. And there's much more technology goodness available at bootstrap-it.com

This article will introduce you to the big players and concepts in the open source license universe.

This article comes from my Complete LPI Open Source Essentials Exam Study Guide Udemy course and book. You can also view the video version here:

In broad terms, we'll divide those classes into two categories. We'll discuss both permissive and restrictive licenses here.

Working with Permissive Software Licenses

Permissive open source software licenses are a type of software license that allows for a wide range of uses of the licensed software. Some examples of permissive open source software licenses — that we'll explore in greater depth a bit later — include Apache, BSD, and MIT.

In general, permissive open source software licenses give you the right to use the software for any purpose – including commercial purposes – and the right to modify the software to suit your needs.

You'll get the right to distribute the software to others, either in its original form or as a modified version and the right to sublicense the software to others, allowing them to exercise the same rights as the original licensee. You'll also have the right to use any patents or trademarks associated with the software, as long as they comply with any applicable laws.

At the same time, permissive open source software licenses also impose certain obligations on users. You might be required to include a copyright notice when making further copies or distributions of the software.

You could also need to include a copy of the license in subsequent distributions. You might need to disclaim any warranties or liability for damages that may arise from the use of the software. And you'll often have to give attribution to the original software authors or contributors. Although there might also be times when using the names of those authors without explicit permission is forbidden.

The bottom line: make sure you read the fine print.

Now let's take a more detailed look at some actual permissive licenses.

The 2-Clause BSD License

The 2-Clause BSD License, also known as the Simplified BSD License, is a permissive open source software license that allows for a wide range of uses of the licensed software.

The license permits users to use, copy, modify, and distribute the software, as long as they include a copyright notice and disclaimer of any warranties or liability. The 2-Clause BSD License is commonly used for software that is released as open source but also used in proprietary software products.

The 3-Clause BSD License

The 3-Clause BSD License, also known as the New BSD License, is similar to the 2-Clause BSD License but includes an additional clause that requires users to include a copy of the license and copyright notice in any distributions of the software. This license is commonly used for open source software projects that want to ensure proper attribution and give credit to the original authors or contributors.

"BSD", by the way, stands for "Berkeley Software Distribution". The license is associated with the version of the Unix operating system that was developed at the University of California, Berkeley in the late 1970s and early 1980s.

The MIT License

The MIT License is a permissive open source software license that allows users to use, copy, modify, and distribute the software, as long as they include a copyright notice and disclaimer of any warranties or liability.

The license is similar to the 2-Clause BSD License but is often preferred for its brevity and simplicity. The MIT License is commonly used for open source software projects, especially those related to web development and programming languages.

"MIT", of course, stands for Massachusetts Institute of Technology, a private research university located in Cambridge, Massachusetts, USA. The MIT License is named after the university because it was developed by the university's computer science department and used for its open source software releases.

The Apache License

The Apache License version 2.0 is widely used for open source software projects, especially those related to web and server software. The license permits users to use, copy, modify, and distribute the software, as long as they include a copyright notice, disclaimer of any warranties or liability, and a notice of any changes made to the original software.

The license also includes patent grant provisions that protect users against patent infringement lawsuits. The Apache License version 2.0 is often considered to be one of the most permissive open source software licenses available.

The Eclipse Public License (EPL)

The EPL is a permissive open source software license that was developed by the Eclipse Foundation for use with the Eclipse software development environment. On the other hand, EPL is not a permissive open source software license. In fact, EPL kind of straddles the border between permissive and restrictive. I'll describe it here, but bear in mind that it actually shares some features with the restrictive copyleft licenses we'll talk about later.

At any rate, the license is designed to be compatible with other open source software licenses and allows for the creation of derivative works.

The EPL version 1.0 is a copyleft license that requires any modifications or derivative works to be released under the same license. The license also includes a patent license grant that allows users to use any patents associated with the software, as long as they comply with the terms of the license.

The EPL version 2.0, released in 2017, is also a copyleft license but includes several updates and improvements over the previous version. The license has been updated to address some of the legal issues that arose with the previous version and to make it more compatible with other open source software licenses. One notable change in version 2.0 is the addition of a patent non-assertion covenant, which assures users that the software's licensors will not assert their patents against the user for using or distributing the licensed software.

Working with Protective Software Licenses

Copyleft software licenses aim to ensure that the licensed software remains free and open for future users and developers. These licenses use copyright law to achieve this goal by requiring any derivative works of the software to be licensed under the same license terms.

This means that anyone who modifies or distributes the software must also make their changes and additions available to others under the same license.

The most well-known copyleft software license is the GNU General Public License (GPL), but there are many other copyleft licenses such as the Lesser General Public License (LGPL), the Mozilla Public License (MPL), and the Affero General Public License (AGPL).

The rights and obligations defined by copyleft software licenses can vary depending on the specific license, but some common aspects include rights, typically granting users the right to use, modify, and distribute the software. The licenses often require that any derivative works be licensed under the same terms, which ensures that the software remains free and open for future use and development.

Copyleft software licenses also impose certain obligations on users and developers of the software. These obligations can include requirements to include a copy of the license with any distributions of the software, to make the source code available, and to maintain copyright notices and attribution to the original authors.

Copyleft licenses can have implications for compatibility with other licenses. For example, using individual software components licensed as copyleft as part of a larger project may require the entire project to be released under a copyleft license. This is because the copyleft license requires any derivative works to be licensed under the same terms.

Let's work through some of the more popular copyleft templates, one at a time.

The GNU General Public License

The GPL is developed by the Free Software Foundation (FSF). It requires any derivative works of the licensed software to be licensed under the same terms.

The GPL has several versions, including version 2.0 (GPLv2) and version 3.0 (GPLv3). The GPL is widely used for software development projects and is often seen as a key component of the free software movement.

GPLv2 (that is, "version 2") of the GPL includes provisions for distributing the source code and making modifications to the software. GPLv3 added provisions for preventing "tivoization" (meaning, the practice of using digital restrictions to prevent users from modifying the software) and for addressing patent issues.

The GNU Lesser General Public License

The LGPL is another license developed by the FSF that allows for more flexibility in the use of the licensed software. The LGPL has two versions, version 2 (LGPLv2) and version 3 (LGPLv3).

The LGPL is commonly used for software libraries and other software components that are designed to be linked with other software. LGPLv2 and LGPLv3 added more flexibility in the use of the licensed software, particularly for software libraries. Later versions also worked to add greater compatibility with the GPLv3.

The GNU Affero General Public License

The AGPL also comes from the FSF. It's similar to the GPL but includes additional requirements for software that is distributed over a network.

The AGPL is often used for software that's designed to be run on servers and accessed over a network, such as web applications.

Version 3 (AGPLv3) includes additional requirements for software that is distributed over a network. It requires anyone who uses the software over a network to make the source code available and to provide a copy of the license to users.

The Mozilla Public License

The MPL was developed by the Mozilla Foundation – the people behind the Firefox browser. It is a copyleft license that allows for the distribution of the licensed software under both proprietary and open source terms. The MPL is compatible with the GNU General Public License (GPL), allowing code to be shared between MPL-licensed software and GPL-licensed software. The MPL is also compatible with other open source licenses such as Apache and MIT.

The MPL requires that the source code for any modified versions of the licensed software be made available. This allows others to see and modify the code, promoting the growth and development of the software. The MPL also requires that any distribution of the licensed software, whether in its original or modified form, be made under the MPL.

This means that anyone who distributes the software must provide a copy of the license with the software and make the source code available. The MPL includes provisions to protect users from patent claims related to the licensed software. These provisions ensure that users of the software are able to use and distribute the software without fear of legal action.

Wrapping Up

With this information you're now ready to carefully evaluate the benefits and limitations of each specific collection of open source code you might use. And you can similarly understand how you might want to license your own code when it's ready to be shared with the world.

This article comes from my Complete LPI Open Source Essentials Study Guide course__. And there's much more technology goodness available at bootstrap-it.com

Oh My Zsh is a framework for managing your Zsh configuration for your command line terminal. It's been extremely popular among developers for more than a decade.

Robby is also the CEO of Planet Argon, a developer consultancy he created two decades ago. He's done work for Nike and lots of other companies.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can listen to my interview in your favorite podcast player (be sure to subscribe), or right below in your browser:

Or you can watch me interview Robby on the freeCodeCamp YouTube channel:

Links we talk about during the interview:
Robby reading his classic "d'Oh My Zshell" article recording on an older freeCodeCamp podcast episode: https://freecodecamp.libsyn.com/site/ep-34-doh-my-zsh

The Sandi Metz interview episode of Maintainable that Robby mentions: https://maintainable.fm/episodes/sandi-metz-making-is-easy-mending-is-a-challenge

The Mighty Missoula (Robby's Post Rock band) live set: https://www.youtube.com/watch?v=63DE2tNlAWY

What is Hugging Face 🤗?

If you are interested in Artificial Intelligence and Natural Language Processing, you have probably heard of Hugging Face – the company named after a cute emoji.

Hugging Face is not only a company, but also a platform that is transforming the fields of AI and NLP through open source and open science.

Hugging Face offers a platform called the Hugging Face Hub, where you can find and share thousands of AI models, datasets, and demo apps. The Hub is like the GitHub of AI, where you can collaborate with other machine learning enthusiasts and experts, and learn from their work and experience.

Hugging Face’s mission is to democratize good machine learning, one commit at a time. Whether you are a beginner or a professional, you can benefit from the amazing resources and tools that Hugging Face provides.

In this post, I'll guide you through the basics of Hugging Face. You'll learn how to create your Hugging Face account, set up your development environment, and use some of the pre-trained models that are available on the Hub. Let’s get started! 🚀

Here's what we'll cover:

1. What can you do on the Hugging Face Platform?
   • Download and fine-tune existing Open Source models
   • Run models directly from Hugging Face
   • Add/create your own model
   • Use existing datasets
   • Create/browse demo apps (also known as Spaces)
   • Join or create an organization
   • Create a portfolio
   • Learn AI skills
2. Hugging Face terminology
3. How to get started with Hugging Face
   • Create a Hugging Face account
   • Set up your environment
4. How to use pre-trained models in Hugging Face
5. How to find the right pre-trained model
6. What's next?

What Can You Do on the Hugging Face Platform?

Here are some of the awesome things you can do on Hugging Face:

Download and fine-tune existing Open Source models:

Why start from scratch when you can leverage the power of over 450k models that are already available on the Hugging Face model library?

You can easily download these models and fine-tune them on your own custom dataset with just a few lines of code. This way, you can save time and resources, and still get a model that suits your specific needs.

You can use these models to perform various tasks, such as:

1. Natural language processing (for example, translation, summarization, and text generation)
2. Audio-related functions (for example, automatic speech recognition, voice activity detection, and text-to-speech)
3. Computer vision tasks (for example, depth estimation, image classification, and image-to-image processing),
4. Multimodal models capable of handling diverse data types (text, images, audio) and producing multiple types of output.

Run Models directly from Hugging Face:

If you don’t want to set up these models on your own machines, you can simply use Hugging Face’s Transformer library to connect to these models, send requests, and receive outputs.

Add/create your own model:

If you have a brilliant idea for a new model, or you want to improve an existing one, you can also add/create your own model on Hugging Face.

The platform will host your model, and allow you to provide additional information, upload essential files, and manage different versions. You can also choose whether your models are public or private, so you can decide when or if you want to share them with the world.

Once your model is ready, you can access it directly from Hugging Face, send requests, and retrieve the outputs for integration into any applications you are developing.

Use existing datasets:

A good model needs a good dataset. Hugging Face provides a repository of over 90,000 datasets that you can use and feed into your models.

You can take an in-depth look inside the dataset using the dataset viewer. You can also contribute your own datasets to the repository, and help the machine learning community grow.

Screenshot of dataset viewer

Create/browse demo apps (also known as Spaces):

Hugging Face’s Spaces are Git repositories that allow you to showcase your machine learning applications. You can also browse and try out the Spaces created by other users, and find inspiration for your next AI app.

With thousands of ML apps to choose from, you will never run out of fun and interesting things to do.

Here are a few cool Spaces you can check out:

• OpenAI's Whisper: Transcribe long-form microphone or audio inputs with the click of a button.
• AI Comic Factory: Create your own comic books.
• QR Code AI Art Generator: Generate beautiful QR codes using AI.
• Stable Video Diffusion (Img2Vid - XT): Generate 4s video from a single image.
• Video-LLaMA: Audio-Visual Language Model for Video Understanding.

Join or create an organization:

You can join or create your own organization on Hugging Face. This allows you to showcase your work and collaborate with other members from your university, lab, or company. You can also work on private datasets, models, and spaces with your organization.

Create a portfolio:

You can create a professional portfolio on Hugging Face to showcase your work and start building your reputation. This can help you land jobs related to AI model training, integration, and development.

Hugging Face provides the basic computing resources for running the demo app, including 16 GB of RAM, 2 CPU cores, and 50 GB of disk space for free. You can also upgrade your hardware for improved and faster performance with paid options.

Learn AI Skills:

Hugging Face is an excellent platform for learning AI skills. It offers a comprehensive set of tools and resources for training and using models. This includes demos, use cases, documentation, and tutorials that guide you through the entire process of using these tools and training models.

You can also learn from the experts and the community on Hugging Face, and improve your AI knowledge and skills.

Hugging Face Terminology

There are some terms you'll need to know to get the most out of working with Hugging Face.

Pretrained model: A model that has been trained on a large dataset for a specific task before being made available for use.

Inference: Inference is the process of using a trained model to make predictions or draw conclusions about new, unseen data based on the learned patterns from the training data.

Transformers: Transformers are models that can handle text-based tasks, such as translation, summarization, and text generation. They use a special architecture that relies on attention mechanisms to capture the relationships between words and sentences.

Tokenizer: A tokenizer is a process that breaks down text into smaller units called tokens. Tokens are usually words or subwords that can be used for natural language processing (NLP) tasks.

How to Get Started with Hugging Face

To get started with HuggingFace, you will need to set up an account and install the necessary libraries and dependencies. Don’t worry, it’s easy and fun!

Here are the steps you need to follow:

Create a Hugging Face Account

Signing up as a Community individual contributor is free of charge. You can also opt for a ‘Pro’ plan or a customized plan for Organizations if you need more features and resources.

Go to the Hugging Face website and click on “Sign Up” to create a free account.

Then enter your email address and a password. Click next and complete your profile and security check.

Setting up a Hugging Face account

Congratulations, you are now a Hugging Face member! 🎉 You will be directed to the Hugging Face ‘Welcome’ page, where you can find more information and tips on how to use the platform.

As a bonus, you also get a Git-based hosted repository where you can create your Models, Datasets and Spaces. You can do this directly using the website or using the CLI. If you prefer the latter, you can check the detailed instructions on the ‘Welcome’ page under the ‘Programmatic access’ section.

Hugging Face welcome screen showing options to create a new model, browse the docs, and set up programmatic access

Set Up Your Environment

Before you start using the Hugging Face hub programmatically, you will need to set up your environment.

Step 1: Install Python and Pip:

Make sure you have Python 3.8 or higher installed on your system. You will also need Pip, the package manager for Python, to install the Hugging Face libraries. If you don’t have Python, you can install it by following the instructions here.

Step 2: Install HuggingFace libraries:

Open a terminal or command prompt and run the following command to install the HuggingFace libraries:

pip install transformers

This will install the core Hugging Face library along with its dependencies. To have the full capability, you should also install the datasets and the tokenizers library.

pip install tokenizers, datasets

Step 3: Set up a development environment:

Choose a code editor or IDE of your choice, such as Jupyter Notebook, PyCharm, or Visual Studio Code. Create a new project directory and set up a virtual environment to isolate your project dependencies. You can find more information on how to do this here.

With these steps completed, you have successfully set up Hugging Face on your system and are ready to start exploring its features and capabilities. Let’s go! 🚀

How to Use Pre-Trained Models in Hugging Face

One of the best things about Hugging Face is that it gives you access to thousands of pre-trained models that can perform various tasks on different types of data. Whether you are working with text, vision, audio, or a combination of them, you can find a model that suits your needs.

Hugging Face has two main libraries that provide access to pre-trained models: Transformers and Diffusers. The Transformers library handles text-based tasks, such as translation, summarization, and text generation. Diffusers can handle image-based tasks, such as image synthesis, image editing, and image captioning.

You have already installed the transformers library during the environment setup. Let’s see how you can use it to work with pre-trained models.

Step 1: Visit the PyPI page

To learn more about the transformers library, you can visit its page on PyPI, the Python Package Index.

Go to PyPi and search for ‘transformers’. Click on the latest version of the transformers library displayed in the search result. You will see a brief introduction of the library, as well as some useful links and information.

Step 2: Download and use pre-trained models

The transformers library provides APIs to quickly download and use pre-trained models on a given text, fine-tune them on your own datasets, and then share them with the community on Hugging Face’s model hub.

Step 3: Use the pipeline() method

To use a pre-trained model on a given input, Hugging Face provides a pipeline() method, an easy-to-use API for performing a wide variety of tasks.

The pipeline() method makes it simple to use any model from the Hub for inference on any language, computer vision, speech, and multimodal tasks.

Let’s try to perform a task using the pipeline() method.

Task: Sentiment analysis:

Let’s use the pipeline() method to classify positive versus negative texts provided by the user:

from transformers import pipeline

# Load the pre-trained sentiment analysis model
sentiment_analysis = pipeline(
"sentiment-analysis", model="distilbert-base-uncased-finetuned-sst-2-english")

input_text = [
"It’s a great app, my biggest problem is the card readers regularly do not connect. Which is very poor customer service for us because we have to manually enter our customers debit cards, which takes time. This slows down our efficiency."
]

# Perform sentiment analysis on the input text
result = sentiment_analysis(input_text)

# Print the result
print(result)

The pipeline statement downloads and caches the pretrained model used by the pipeline, while the statement result = sentiment_analysis(input_text) evaluates it on the given text.

Output:

[{'label': 'NEGATIVE', 'score': 0.9996176958084106}]

Here, the answer is "NEGATIVE" with a confidence of 99.96%.

Task: Automatic speech recognition

Let’s try another task that involves speech recognition.

from transformers import pipeline

transcriber = pipeline(task="automatic-speech-recognition",
                       model="openai/whisper-small")
result = transcriber(
    "https://huggingface.co/datasets/Narsil/asr_dummy/resolve/main/mlk.flac")

print(result)

Output:

{'text': ' I have a dream that one day this nation will rise up and live out the true meaning of its creed.'}

You can see how easy it is to get a pre-trained model up and running using Hugging Face's libraries.

How to find the right pre-trained model

But how can you find the right pre-trained model if you want to perform a specific task?

This is actually quite easy. You can browse the models on the Hugging Face website, and filter them by task, language, framework, and more. You can also search for models and datasets by keyword and sort them by trending, most likes, most downloads, or by recent updates.

Searching for models

Each model has a model card that contains important information, such as model details, inference example, training procedure, community interaction features, and link to the files. You can also try the model on the model card page by using the Inference API section.

Inference API

You can also check the list of spaces that are using that particular model and further explore the spaces by clicking on the space link.

Spaces

What's Next?

In this guide, you have learned the basics of Hugging Face, and how to use its libraries, models, datasets, and spaces. But there is so much more to discover and enjoy!

Here are some tips on how to make the most of Hugging Face:

• Dive into Hugging Face’s Spaces: Spaces are where the magic happens. You can find and try out thousands of machine learning applications created by the community, and see what’s trending and popular. You can also create your own spaces and showcase your work to the world.
• Explore the Hugging Face documentation and tutorials: If you want to learn more about the Hugging Face platform and its features, you can check out the documentation and tutorials. They provide detailed information and guidance on how to use the tools and resources that Hugging Face offers. You can also find information about common ML/AI tasks, such as text classification, image generation, and speech recognition, on the tasks page.
• Visit the learn section: If you are interested in acquiring new skills and knowledge in AI and NLP, you can visit the ‘learn’ page that displays courses from Hugging Face. Here, you can learn from the experts and the best practices in the field, and apply them to your own projects.
• Join the Hugging Face community: Machine learning is more fun when collaborating! You can join the Hugging Face community on platforms like GitHub, Discord, and Twitter to connect with other users and stay updated on the latest developments. You can also share your feedback, questions, and ideas with the community, and help Hugging Face grow and improve.

Hugging Face is not just a platform for AI and NLP – it's also a playground for your curiosity and creativity. You can experiment with new models, expand your AI knowledge, and enrich your AI toolkit with various tools and resources. So, keep learning, keep exploring. There is always something new and exciting to discover with Hugging Face. 😊