Organized by Ubuntu Nepal in collaboration with GNOME Nepal.
On 27th September 2026, we conducted a session titled “Introduction to Open Source Communities, Linux and GNOME” at Softwarica College of IT & E-Commerce.
The session was facilitated by three of us:
- Sailesh Singh (@saileshsingh): Co-lead of Ubuntu Nepal and GNOME Nepal, System Network Administrator
- Shraddha Tiwari (@shraddhatiwari): AI Engineer and open-source advocate
- Abhishek Kushwaha : Backend Developer and open-source contributor
We had run this same session not long before at another college, so we went in with a fairly clear idea of how it would go. What we didn’t expect was how different the room would feel.
This time our audience were 66 students from the ethical hacking and cybersecurity program, and that changed almost everything.
A Different Kind of Room
Last time, we spent a lot of energy explaining what a terminal is and why anyone would want to use it. Here, that wasn’t the case.
Many of these students already lived in the command line. Some were running Kali or Parrot, a few had used Linux daily for months, and several could talk about permissions, processes and networking more confidently than we expected. When we asked who had used Linux before, a large part of the room raised their hands.
So we had to change our approach. Instead of asking “What is Linux?”, the more interesting question became why does the entire security world run on it?
We talked about how the Linux kernel, distributions and open source tools underpin the field they were studying. Tools they use every day are open source, and the transparency of that code is a large part of why the security community trusts them. Anyone can read it, audit it, break it, and fix it.
The Journey
We followed the same path as before, but with a different weight on each stop:
Open Source → Communities → Linux → Linux Distributions
↓
Installation Methods
↓
Terminal
↓
Files & Directories
↓
Git
↓
GitHub
↓
Collaboration
↓
Pull Requests
↓
CI/CD
↓
Deployment
↓
Localization
We began with introductions to GNOME Nepal and Ubuntu Nepal, and how communities helped us grow. Then we discussed open source beyond code: documentation, translation, testing, design, organizing events, and reporting bugs. For this audience, we especially stressed that responsible vulnerability reporting is a contribution too. Finding a flaw and disclosing it properly to maintainers is one of the most valuable things a security person can give back to a project.
We also cleared up the usual confusion between Linux, the Linux kernel and distributions, and explained why different distributions exist for different users. Students had strong opinions here. A short and interesting debate rose from amongst the students between Linux and Windows.
Terminal: Fast Ground Covered
Since the fundamentals were familiar, we moved quicker through the terminal and file system section. Quizzes helped us gauge the room.
What stood out was that even confident users sometimes had gaps. Knowing which command to run is different from understanding what the system is doing, and a few quiz questions led to good side discussions about permissions and file ownership.
Git and GitHub: Where the Gap Showed
Here is where the picture changed. Comfort with Linux didn’t automatically mean comfort with Git and collaborative workflows. Many students knew commands but had never used version control for teamwork, or made a pull request to someone else’s project.
We covered configuration, repositories, staging, commits, remotes and pushing to GitHub. Then students worked with our practice repository, made changes, and opened their first Pull Request.
Because these students think about attack surfaces, we framed Git a little differently: a repository is history, and history can leak. We briefly discussed why credentials, API keys and private files must never be committed, and why a secret pushed once is effectively public.
CI/CD: The Part That Clicked
Again we wanted to go beyond git init, add, commit, push. We showed a simple CI/CD pipeline:
Local Development
↓
Git Commit
↓
Push to GitHub
↓
Continuous Integration
↓
Build
↓
Checks
↓
Artifact
↓
Deployment
↓
Live Website URL
This was the moment that resonated most with this audience. Security students immediately started asking the right questions: What runs in the pipeline? Who can trigger it? Where are the secrets stored? What if someone opens a malicious pull request?
These are exactly the questions that lead into DevSecOps and supply chain security, and we were happy to see students connecting automation to their own field without us prompting them. Watching a change go from their laptop to a live URL still got the same reaction it always does.
Contributing in Our Own Language: GNOME Nepali Localization
We saved one more topic for the end of the session, and it was one we cared about a lot: GNOME’s localization for the Nepali language.
After a session full of terminals, repositories and pipelines, we wanted students to leave knowing that contributing to GNOME doesn’t have to start with writing code. Every button, menu, error message and setting in GNOME is a string of text that can be translated, and every translated string means one more person in Nepal can use their computer in the language they think in.
We showed them how it works:
- How GNOME’s translatable strings are organized and where translation teams coordinate
- How to find the Nepali translation team and which modules need work
- How to open a translation file, translate, transliterate or review strings, and submit them
- How this connects to what they had just learned: files, commits, review and pull requests
For students who had come in thinking of open source as something for expert programmers, this was a good moment. Careful reading and good language skills are enough to make a visible difference. Students came in with a belief that contributing to open source is for the tech nerds and needs expert level of coding skills but went back realizing contributions can be easy and non-technical as well.
It also tied the whole session together. Everything before it, from communities to Git to pull requests, was the machinery of contribution, and this was one concrete place to use it.
What We Learned
Our biggest lesson last time was that a hands-on workshop depends on everyone’s environment. This time the lesson was about the audience:
Knowing your audience changes the session. The same content lands differently depending on who is in the room. A group with a strong technical background needs less hand-holding and more context, depth and “why”.
Familiar with tools doesn’t mean familiar with the ecosystem. These students were skilled with the terminal but new to the culture of contribution: issues, pull requests, review and maintainers.
Security and open source are closely tied. Transparency, peer review and community response are part of how open source software becomes trustworthy, and students understood this quickly.
What We Want to Do Next
-
Tailor future sessions to the audience’s background before the event.
-
Share prerequisites and a setup guide in advance (this worked better this time).
-
Include a short segment on responsible disclosure and secure contribution practices for security-focused groups.
-
Offer follow-up material on contributing to security-related open source projects.
-
Encourage students to start with small contributions: documentation, bug reports, testing.
-
Keep the practical section divided into checkpoints.
Final Thoughts
Our aim wasn’t to turn anyone into a maintainer in one session. We wanted to show these students that the tools and culture they already love are built by communities, and that they can be part of them. The security field needs people who both break things and help fix them in the open.
We also distributed stickers and merchandise after the session and received a token of love from the department and faculty, which we really appreciated.
A big thank you to Softwarica College of IT & E-Commerce, the faculty, and all the students who participated.
And special thanks to my fellow instructors, Sailesh Singh and Abhishek Kushwaha for making this session possible.
We’re looking forward to seeing your first contributions and will keep improving from what we learned from this experience.