You do not need to be a coder or developer to understand open-source communities. If you are curious about how developers actually work, collaborate, and contribute to open-source projects, then this article is for you. In this article, I will walk through the step-by-step process of how developers contribute their skills and participate in open-source community projects by using K-serve as an example.
This article is also helpful for user experience researchers who already work with developers but want to better understand how developers work on projects and use GitHub. It is also useful for UX designers who are interested in learning about the developer experience (DevEx) domain and becoming developer experience designers. Additionally, this article is intended for non-technical people who want to learn how developers and open-source communities work, and how GitHub repositories are used to manage, collaborate on, and operate projects.
Let's learn what is Kserve? KServe is an open-source Kubernetes-based model serving platform that enables scalable and reliable deployment of machine learning models in production environments. I chose KServe because it sits at the intersection of machine learning, Kubernetes, platform engineering, and open-source collaboration, making it a rich example for understanding real-world engineering workflows.
It is important to understand that engineers are not simply “writing code”; instead, they are continuously discovering problems, discussing solutions, implementing changes, reviewing and refining decisions, validating outcomes, and maintaining the system over time.
This entire workflow—spanning collaboration, decision-making, and iteration—leaves behind valuable traces in GitHub through issues, pull requests, discussions, and commits, which together reveal how complex systems are actually built and evolved.
What is Github repository?
A GitHub repository is created by developers, project maintainers, or organizations as a central place to store, organize, and manage a project’s code, documentation, issues, and collaboration history. Once created, it is used by a wide range of people, including developers who write and maintain code, contributors who fix bugs or add new features, reviewers who evaluate and approve changes, and non-developers such as UX researchers, product managers, and technical writers who explore the project to understand it or contribute documentation and feedback.
GitHub repositories are important because they reveal not just the final software product but the entire development process behind it. Developers use them to collaborate, track issues, discuss and review changes, manage tasks, and maintain transparency in their work. Learning how repositories function helps in understanding real developer workflows, decision-making processes, and how complex software systems evolve over time in both open-source and professional environments.
I am going to explain how developers and the open-source community work with entire GitHub repository in 5 simple steps.
Step : 1. The Project Exists as a Living System
Imagine that KServe already exists and is being used by people around the world. Its users include ML engineers who deploy and manage machine learning models, platform engineers who build and maintain the underlying infrastructure, MLOps teams who ensure smooth model lifecycle operations, Kubernetes administrators who handle cluster configuration and deployment, and researchers who experiment with and evaluate machine learning systems.
Most people think software development means typing code all day. In reality, a typical improvement starts with a real person running into a problem, and ends with millions of users getting a better experience. Here's how that journey unfolds, using KServe — a tool that helps AI models run in the cloud — as the example.
Let me show you the big picture first, then zoom into each phase.
Now let's look at each phase in plain language, with a closer diagram for the parts that need more detail. For example: A user(Engineer) deploys an inference service.
Step :2 A User Encounters a Problem & Created the issue.
Imagine you're an engineer who uses KServe to run an AI model. You follow all the instructions, but when you try to use it, nothing responds. You're not sure if you did something wrong, or if there's a bug in the software.
So you do what most people do: check the logs, search the documentation, ask the community — and eventually open a "bug report" (called an issue on GitHub). This is where the real work begins, even though no one has touched code yet.
When you file that issue, volunteer maintainers (people who help run the project) step in to classify it. Is this a bug? A misunderstanding? Something missing from the docs? They ask questions to narrow it down
Step: 3 Can I make it break on my machine?
Before anyone can fix a problem, they have to be able to see the problem. An engineer sets up the same software environment as the user and tries to make the bug happen intentionally. This is called reproducing the bug.
Once they can make it fail consistently, they start playing detective — tracing the path a request takes through the system, reading log files, and asking: where exactly does things go wrong?
This phase is mostly thinking, not typing. Engineers build a mental map of how the system is supposed to behave, then look for where reality diverges from that map. It looks like this:
Step: 4 Choosing the right fix (not just any fix)
Once the root cause is found, the next question isn't can we fix it? — it's what's the safest way to fix it?
In the KServe example, the bug was that a missing network port would cause a silent, invisible failure. Engineers debated three possible solutions:
This kind of debate — often hundreds of comment threads for just a few lines of code — is what separates good software from brittle software.
Step : 5 From code to released fix
Only after all that thinking does actual coding begin. The engineer writes the fix in a separate "branch" (a safe copy of the code), then submits it as a "pull request" — essentially saying "here's my proposed change, please check my work."
Other engineers review it, suggest improvements, and run automated tests. When everyone agrees it's safe, it gets merged into the main codebase and released.
The ending: and why it never really ends
After the update is released, what changed for the user? Before: "It just doesn't work." After: "Configuration invalid: missing port." That's a small sentence, but it means the user now understands what to fix instead of guessing blindly.
And here's the final truth: the moment one problem is solved, a user somewhere will notice the next thing that could be better. The loop starts again. That's not a flaw in open source — it's the whole point. Software improves because real people keep using it, keep running into its rough edges, and keep caring enough to speak up.
