DEV Community: Ibrahim Olawoyin

Making AI "Boring": An Engineering Audit of RamaLama on Fedora Linux

Ibrahim Olawoyin — Wed, 01 Apr 2026 18:49:50 +0000

The Thesis of Boring AI

When I first encountered the RamaLama project, its mission statement gave me pause: "Making working with AI boring (in a good way)." In an industry characterized by unpredictable latency and non-deterministic "hallucinations," predictability is the ultimate premium.

However, as a Fedora contributor, my exploration revealed that "Boring AI" is not a default state; it is a goal achieved through rigorous infrastructure abstraction and data verification. Below is my technical audit of RamaLama (v0.18.0) evaluated on Fedora 43 (WSL2), documenting why the tool excels at infrastructure while highlighting the critical need for RAG (Retrieval-Augmented Generation) to fix output reliability.

1. Transport Evaluation: The Latency Gap

RamaLama's core strength is its unified interface for multiple model transports. However, my benchmarks showed that not all transports are created equal when working in distributed environments.

Transport	Test Model	Download Speed	Status
Ollama	TinyLlama (608.16 MB)	6.21 MB/s	Success
HuggingFace	TinyLlama GGUF (460.74 MB)	7.41 MB/s	Success
ModelScope	Qwen1.5 (Simultaneous)	200-600 KB/s	Cancelled
OCI (Quay.io)	RamaLama Image	Varied	Success (Incomplete)

The "ModelScope" Bottleneck:

My exploration of the ModelScope transport proved impractical for global contributors with bandwidth constraints. Unlike Ollama or HuggingFace, the ModelScope transport initiated 11 simultaneous downloads for various quantization variants, exceeding 5 GB of total bandwidth and significantly lower throughput.

Engineering Decision: For Fedora documentation workflows, Ollama and HuggingFace remain the primary reliable transports for rapid model deployment.

2. Hardware Diagnostics: The KV Cache Wall

A common novice critique of AI tools is "the model didn't run." A curious engineer asks "exactly where did the memory allocation fail?"

In my testing, models larger than 1B parameters (specifically DeepSeek R1 8B and Granite 3.1 2B) failed to initialize. By auditing the llama.cpp and crun logs, I identified the precise failure point:

DeepSeek R1 8B Requirement: CPU KV buffer size = 18,432 MB (18 GB).
System Constraint: Available Memory = 7,184 MB.
Result: A 180-second health check timeout.

The Lesson: "Boring AI" requires absolute hardware awareness. RamaLama's abstractions cannot bypass physical RAM limitations, but its transparent logging allowed me to diagnose the memory shortfall within seconds rather than guessing at the cause of the timeout.

3. Truth vs. Hallucination: The Ground Truth

To measure output quality, I measured model responses against the official Fedora Project Documentation.

Test Case: The Four Foundations of Fedora

I prompted two different 1B parameter models with the same question: "What are the Four Foundations of the Fedora Project?"

Model	Response (Foundations)	Ground Truth (Actual)	Accuracy
Ollama: TinyLlama	Core, Desktop, Server, Project	Friends, Features, First, Freedom	0%
HF: TinyLlama	Forking, Simplicity, Community, Open-Source	Friends, Features, First, Freedom	0%

The "Hallucination" Trap:

Both models produced beautifully structured, authoritative-sounding lists that were fundamentally incorrect. They "hallucinated" project structures and philosophical values that sounded plausible but lacked any factual basis in Fedora history.

4. The Synthesis: Why Infrastructure is the First "Boring" Step

This brings us back to the original question: Does RamaLama make AI boring?

The answer is Yes for Infrastructure, No for Intelligence.

Boring Infrastructure (The Success): RamaLama successfully abstracts container runtimes (Podman), model sourcing, and execution. The command ramalama run ollama://tinyllama is a masterpiece of reproducibility.
Exciting Intelligence (The Gap): The output remains unpredictable. Without a secondary layer like RAG (Retrieval-Augmented Generation), these models cannot be used for technical documentation.

Final Review

As a junior engineer in the Fedora community, this exploration taught me that the "Boring AI" stack looks like this:

RamaLama: Makes the Environment predictable (Podman-backed reliability).
Docling: Makes the Data structured (Precision extraction).
RAG Pipeline: Makes the Output accurate (Grounding the model in facts).

The journey to boring AI is just beginning, and with tools like RamaLama handles the "heavy lifting" of infrastructure, we can finally focus on the harder problem of factual accuracy.

Explore the Technical Trace

For the full system logs, exact bbox coordinates from my Docling experiments, and a deep dive into the llama.cpp error outputs mentioned above, visit the repository:

RamaLama Exploration on Fedora Linux

The Libravatar Problem Nobody Warned Me About (And How I Finally Fixed It)

Ibrahim Olawoyin — Fri, 27 Mar 2026 16:39:41 +0000

I didn’t expect something as simple as setting a profile picture to turn into a full debugging session.

But that’s exactly what happened.

It started like any normal onboarding task. I had just set up my Fedora Account System account, everything was working fine, and I thought, “Let me quickly update my profile picture and move on.”

Simple, right?

I clicked “Change Avatar.”
I was redirected to Libravatar.
I logged in.
I uploaded my picture.

Done.

Or at least, that’s what I thought.

I went back to check my profile… and there it was, the same default avatar staring back at me like nothing had changed.

At first, I assumed it was just a delay. Maybe caching. Maybe I needed to refresh.

I refreshed.

Nothing.

I logged out and back in.

Still nothing.

That was the moment I realized this wasn’t just a small glitch. There was something deeper going on.

The Loop That Made It Worse

While trying to figure it out, I ran into another issue, the login loop.

At one point, instead of smoothly logging in, I kept getting prompted repeatedly for credentials. It felt like I was stuck between two systems that weren’t fully talking to each other.

That’s when I made a small but important decision, I cancelled the prompt.

And surprisingly, that worked.

It redirected me to the proper Fedora login page, and I was finally able to proceed cleanly.

It was my first clue that the problem wasn’t just about uploading an image… it was about how systems were connected.

Understanding the Real Problem

At this point, I stopped guessing and started thinking.

Libravatar wasn’t just storing images. It was linking identities.

And Fedora wasn’t just using usernames. It was relying on a specific identity mapping system — OpenID and email associations.

That’s when it clicked.

Uploading the image wasn’t enough.
The system needed a verified identity to attach it to.

The Fix That Finally Worked

Instead of trying to re-upload the image again, I took a different route.

I added a new email address inside Libravatar.
Then I verified it.

Came back. Refreshed.

And just like that; it worked.

The new profile picture finally showed up.

What I Learned

This wasn’t just about fixing an avatar issue.

It taught me something deeper about working in real systems:

Things don’t always fail loudly, sometimes they fail silently
Identity systems (OpenID, email mapping) matter more than they seem
Debugging isn’t about trying random fixes, it’s about understanding how things connect

Most importantly, I learned that the difference between being stuck and moving forward is often just one shift, from guessing to thinking.

Why I Decided to Document It

After solving it, I realized something:

If I ran into this, others definitely would too.

So instead of keeping the solution to myself, I turned it into a guide for the community, something simple, clear, and easy to follow.

Because in open source, solving a problem is good…

But making it easier for the next person?

That’s better.

If you're interested in the documentation I prepared as a guide for resolving these issues, you can find it here

Beyond the PDF: Engineering Structural Fidelity for Fedora RAG Pipelines

Ibrahim Olawoyin — Wed, 25 Mar 2026 15:37:51 +0000

The Preprocessing Mirage

When I first approached the task of "Exploring Document Processing with Docling," I fell into a common trap: I thought I was simply converting a PDF. In most contexts, "converting" implies a change in format, something routine, almost trivial.

However, as I integrated these outputs into the RamaLama RAG system for the Fedora Outreachy project, the reality set in. Document processing isn't just a setup step; it is the architectural foundation of retrieval accuracy. If the structural extraction is flawed, the Large Language Model (LLM) is essentially "hallucinating" on top of broken data.

Below is the technical breakdown of my exploration, the benchmarks I ran, and why structural fidelity is the primary lever in a reliable AI pipeline.

1. The Experimental Setup

To push the boundaries of Docling, I selected a high-complexity test case: the PyTorch Conference Europe 2026 Sponsorship Prospectus. This document was chosen specifically because it contains:

Multi-column text layouts.
Tables spanning multiple pages.
Mixed image/text content.
Diverse font weights and heading hierarchies.

Environment Specs:

Tool: Docling CLI (v2.81.0)
Host: Windows 11 (Python 3.14)
Pipeline: Standard vs. VLM (Vision-Language Model)

2. Comparing Pipelines: Efficiency vs. Semantic Depth

One of the most critical decisions in a document pipeline is choosing the right engine. Docling offers a Standard pipeline and a VLM (Vision-Language Model) pipeline. My benchmarks revealed a staggering disparity in resource consumption.

Metric	Standard Pipeline	VLM Pipeline
Latency (7 Pages)	~10 Seconds	~120 Minutes
Compute Requirement	Low (CPU)	High (GPU Recommended)
Model Overhead	Minimal	~500MB+ (Vision Models)
Semantic Fidelity	Structure-Aware	Context-Aware (Visual)

The Judgment:

For the Fedora RPM Packaging Guidelines, the Standard Pipeline is the engineering choice. Since the guidelines are text-heavy and structured with clear headers, the 10x speed advantage of the Standard pipeline outweighs the visual context parsing of the VLM engine. In a production environment, 120 minutes of preprocessing for a single document is a scalability failure.

3. The Metadata Tax: Navigating Data Density

Perhaps the most eye-opening discovery was the "Metadata Tax", the sheer volume of data required to maintain structural integrity. I compared the output file sizes of the same 7-page PDF across four formats:

Format	File Size	Use Case
Text (.txt)	26 KB	Simple NLP / Rapid Prototyping
DocTags (.xml)	22 KB	Token-Efficient Structural Chunking
Markdown (.md)	1.2 MB	Semantic Chunking with Visual Context
JSON (.json)	6.7 MB	High-Fidelity Spatial Indexing

The "250x" Insight:

The jump from 26 KB (Text) to 6.7 MB (JSON) represents a 250x increase in data volume. This JSON bloat isn't "garbage data"; it includes precise bounding-box (bbox) coordinates and parent-child relationship mappings (e.g., matching a list item to its specific parent list).

Recommendation: For high-volume Fedora docs, DocTags is the optimal balance. It is actually smaller than raw text because it replaces white-space noise with concise structural tags, making it the most token-efficient format for LLM context windows.

4. The OCR Fallacy: Dealing with Digital Searchability

I ran a comparative test with OCR (Optical Character Recognition) enabled vs. disabled. Many developers default to enabling OCR "just in case," but my logs showed why this is a mistake for digital-first documents.

Terminal Logs:

WARNING: RapidOCR returned empty result

Why this happened:
Modern PDFs (like Fedora's docs) already embed searchable text layers. When I forced OCR, the RapidOCR engine spent 25 seconds (up from 8 seconds) hunting for text in image layers that didn't exist.

Insight: Only enable OCR when processing scanned legacy archives. For modern digital documentation, OCR is purely a source of latency and potential artifacts.

5. Mapping findings to the Fedora Ecosystem

How do these benchmarks impact the RamaLama RAG system for Fedora? I've mapped specific document features to their optimal processing strategies:

Spec File Examples: Markdown is the winner here. It preserves the exact indentation and syntax of code blocks, which is critical for an LLM to generate correct RPM spec files.
Versioned Headers: The JSON document tree allows for "Section-Aware Filtering." A RAG engine can filter results based on whether a header belongs to "Fedora 40" vs "Fedora 41" guidelines.
License Tables: Precision table extraction ensures that complex licensing requirements are stored as structured grid data rather than a jumbled string of text.

Conclusion: From Conversion to Engineering

Preprocessing is the "silent partner" of AI engineering. My exploration of Docling revealed that "good enough" conversion isn't enough for production RAG. It requires:

Intentional Pipeline Selection (Standard vs VLM).
Format Optimization (DocTags for token efficiency).
Error-Aware Debugging (Interpreting Windows symlink limitations and OCR warnings).

In the world of Fedora guidelines and high-performance AI, precision at the beginning of the pipeline is what prevents failure at the end.

Explore the Benchmarks

If you are curious about the technical footprints, the exact commands I ran, or the raw outputs of these experiments, I have documented everything in my exploration repository.

Check out the full study here:

Docling Exploration: Fedora Outreachy Contribution

Outreachy 2026 -Comprehensive portfolio of my contributions to the Fedora Project during the Outreachy application phase

Ibrahim Olawoyin — Wed, 25 Mar 2026 08:08:27 +0000

🚀 Outreachy 2026 - Fedora Contributions Portfolio

Applicant: Ibrahim Jamiu

Project: Develop a SLM/LLM using RamaLama RAG based off Fedora RPM Packaging Guidelines

Community: Fedora Project

Application Period: March 20 - April 15, 2026

Last Updated: March 25, 2026

📋 Portfolio Overview

This portfolio documents my contributions to the Fedora Project during the Outreachy May 2026 application phase. I'm working on building an AI model using Retrieval Augmented Generation (RAG) to help Fedora package maintainers follow RPM packaging guidelines.

Connect with me:

💬 Matrix: @ibrahim-jam:fedora.im
🐙 GitHub: Olawoyin365
🌐 Fedora Account: ibrahim-jam

✅ Pre-Requisite Contributions (Completed)

These foundational tasks demonstrate my ability to work with the Fedora community, write technical content, and communicate effectively.

1. Fedora Account System (FAS) Setup

Completed: March 24, 2026

Type: Account Configuration

Status: ✅ Complete

What I did:

Created and configured complete FAS profile
Signed Fedora Project Contributor Agreement (FPCA)
Set up Libravatar profile picture
Configured Matrix, GitHub, and timezone information

Evidence:

Skills demonstrated: Following technical setup procedures, attention to detail

2. Personal Blog Setup

Completed: March 24, 2026

Type: Communication Platform

Status: ✅ Complete

What I did:

Established professional blog on Dev.to
Configured profile with bio, social links, and branding
Set up for publishing Fedora-related content

Evidence:

Skills demonstrated: Platform selection, professional presentation

3. Fedora Introductory Blog Post

Completed: March 24, 2026

Type: Technical Writing

Status: ✅ Complete

What I did:
Wrote a comprehensive introduction to the Fedora Project covering:

What Fedora Linux is and how it differs from other distributions
The Four Foundations (Freedom, Friends, Features, First) and their practical implications
The Fedora community structure and Special Interest Groups (SIGs)
Diversity initiatives like Fedora Week of Diversity
Practical advice for newcomers

Evidence:

Skills demonstrated: Technical writing, research synthesis, storytelling, hyperlinking to official resources

Impact: Provides a newcomer-friendly introduction to Fedora that future Outreachy applicants can reference

4. Social Media Promotion

Completed: March 24, 2026

Type: Community Outreach & Marketing

Status: ✅ Complete

What I did:

Created platform-specific promotional content for my Fedora intro blog post
Crafted messages for Twitter/X, LinkedIn, and Facebook
Used appropriate hashtags and tagged official Fedora accounts
Engaged with community members who interacted with posts

Evidence:

Skills demonstrated: Social media marketing, audience adaptation, community engagement

Reach: [The post was actively engaged and I got DMs from interested prospective applicants to make more enquiries on how to become an outstanding applicants in future application windows]

5. Outreachy Onboarding Guide

Completed: March 25, 2026

Type: Technical Documentation

Status: ✅ Complete

What I did:
Wrote a comprehensive guide for future Outreachy applicants covering:

What to do in the first 24 hours after approval
How to choose the right project
Environment setup best practices
Making your first contribution
Recording contributions properly
What mentors actually evaluate
Common mistakes to avoid

Evidence:

Skills demonstrated: Instructional writing, process documentation, empathy for newcomers

Impact: Provides actionable guidance that reduces confusion for future applicants

Writing style: Narrative approach to make technical instructions engaging and relatable

🔧 Project Contributions (In Progress)

This section will be updated as I make contributions to the RamaLama project.

Contribution #1: [Title]

Started: [Date]

Status: 🔄 In Progress / ✅ Merged

Type: Code / Documentation / Design

What I did:
[Brief description of the contribution]

Evidence:

Issue: [link]
Pull Request: [link]
Discussion: [link]

Technical details:
[What technologies/approaches I used]

Learning outcomes:
[What I learned from this contribution]

Contribution #2: [Title]

Started: [Date]

Status: 🔄 In Progress / ✅ Merged

Type: Code / Documentation / Design

What I did:
[Brief description]

Evidence:

Issue: [link]
Pull Request: [link]

Challenges & solutions:
[What problems I faced and how I solved them]

🌟 Highlighted Contribution

[This will be updated with my most significant contribution as the application period progresses]

As of March 25, 2026: My highlighted contribution is the Outreachy Onboarding Guide, which synthesizes my real-time experience as an applicant into actionable guidance for future participants. This demonstrates my ability to:

Document processes clearly
Think about user experience
Contribute to community knowledge
Write in an engaging, accessible style

📊 Contribution Summary

Total Contributions: 5 (Pre-requisites completed)

Blog Posts: 2

Documentation: 2

Community Engagement: Active in #mentoring Matrix channel

Status: All pre-requisite tasks complete, moving to project contributions

Breakdown by Type:

✅ Setup & Configuration: 2
✅ Technical Writing: 2
✅ Marketing/Outreach: 1
🔄 Code Contributions: Coming soon
🔄 Documentation Improvements: Coming soon

💡 Skills Demonstrated

Through these contributions, I've demonstrated:

Technical Skills:

Markdown formatting and documentation
Git/GitHub workflow understanding
Platform configuration (FAS, Matrix, Dev.to)
Research and information synthesis

Soft Skills:

Clear technical communication
Ability to follow complex instructions
Proactive community engagement
Storytelling and audience adaptation
Time management and organization

Open Source Practices:

Working in public
Documenting work transparently
Contributing to community knowledge
Following community guidelines and codes of conduct

🎯 Project Goals

As I move into the project contribution phase, my goals are:

Understand the RamaLama architecture - Deep dive into how RAG systems work
Study Fedora RPM packaging guidelines - Build domain knowledge
Make meaningful code contributions - Focus on quality over quantity
Document my learning journey - Continue writing about what I learn
Engage with the community - Ask questions, help others, stay visible

📝 Work in Progress

Current Focus (Week of March 24-30):

Reviewing RamaLama documentation
Setting up local development environment
Identifying good first issues for contribution
Studying existing RAG implementations

Next Steps:

Complete development environment setup
Claim first project issue
Make first code contribution
Continue community engagement

📬 Contact & Links

Get in touch:

Related Resources:

🔄 Portfolio Updates

March 25, 2026: Portfolio created, all pre-requisite tasks completed

March XX, 2026: Coming soon
April XX, 2026: [Future updates will go here]

This portfolio is a living document and will be updated throughout the Outreachy application period. Last update: March 25, 2026

Note to reviewers: This portfolio supplements my official Outreachy application. All contributions are also recorded on the Outreachy.org platform as required.

The First Week Panic: What I Wish Someone Had Told Me About Making My First Outreachy Contribution

Ibrahim Olawoyin — Wed, 25 Mar 2026 07:08:39 +0000

It's 11 PM on a Friday. You refresh your email for the hundredth time, and there it is: "Your initial application for Outreachy has been approved." You do a little victory dance. You screenshot the email. You tell everyone who'll listen. Then you open the Outreachy project list, and reality hits: Now what?

I'm writing this exactly five days into my contribution period, while the panic is still fresh enough to remember but far enough past to laugh about. If you're reading this the night you got approved, or if you're preparing for next year's round, here's the honest truth about those first critical days.

Day Zero: The Approval Email
When that email lands, you have roughly 26 days until the final application deadline (April 15, 4pm UTC for my cohort). That sounds like plenty of time. It isn't. Here's what nobody tells you: most applicants spend their first week just figuring out how to contribute. By the time they understand the process, they've lost precious days. So let's skip that learning curve. Here's what to do in the first 24 hours after approval.

First, breathe. You made it past the initial application. That's huge. The reviewers saw something in your essays that resonated. You belong here.

Second, resist the urge to immediately start coding. I know. Your instinct is to dive into the most complex issue and prove yourself. Don't. That path leads to frustration and abandoned pull requests. Instead, spend your first evening reading. Actually reading. The Outreachy Applicant Guide is long and slightly boring, but it answers 90% of the questions you'll panic about later. Set a timer for one hour and just read it straight through.

The single most important thing you'll learn: you need at least one accepted contribution to be eligible for selection. Not started. Not submitted. Accepted. That means reviewed, approved, and merged or documented.

Day One: Choosing Your Project
Saturday morning. Coffee in hand. Now you face the project list.
Here's my advice, learned from almost making the wrong choice: pick the project where the description makes you genuinely curious, not the one where you already know everything.

I almost skipped the Fedora AI project because I thought "I'm not an AI expert, I'll pick something safer." Then I realized: Outreachy exists specifically to help people learn new things. The mentors know you're not an expert. They're evaluating your ability to learn, not your existing knowledge. Read through 3-5 project descriptions. For each one, ask yourself: "Would I be excited to work on this for three months?" If the answer isn't an immediate yes, keep looking.

Once you've chosen, do this before touching any code:
Join the communication channels. Every project lists how to contact mentors. For Fedora, it was Matrix. For other projects, it might be Slack, Zulip, or IRC.
Here's the template I used to introduce myself:
"Hi everyone! I'm [Name], an Outreachy applicant interested in [Project Name]. I have experience with [relevant skill] and I'm excited to learn about [project area]. I'm in [timezone]. Looking forward to contributing!"

Short. Specific. Shows you've read the project description.

Why this matters: Mentors are watching who shows up early and communicates clearly. In my project's chat, I noticed the mentors responded warmly to early introductions and helped those people find good first tasks faster.

Days Two Through Four: The Setup Marathon
This is the part everyone underestimates. Setting up your environment isn't five minutes of git clone. It's accounts, authentication, configurations, and inevitable "why isn't this working" troubleshooting.
For Fedora, I needed a Fedora Account System (FAS) profile, Matrix account, and blog. Each took 15-30 minutes. Account propagation across systems took another 30 minutes. Suddenly, half a day is gone.

The trick: Treat setup as your first contribution to yourself. Create a document titled "How I Set Up My Environment" and write down every step. When you inevitably need to troubleshoot later, you'll thank yourself. Plus, this document itself can become a contribution if you polish it and submit it as documentation improvement.

During setup, you'll hit weird errors. I spent an hour dealing with a 401 authentication error because I didn't realize Fedora's systems needed time to sync. When you get stuck for more than two hours, ask for help in the community chat. Seriously. Mentors would rather answer setup questions than have you disappear in frustration.

Day Five: Your First Actual Contribution
By now you understand the project better. You've lurked in chat. You've read some existing code or documentation.
It's time to claim a task.

Start small. I cannot stress this enough. Your first contribution should be something you can complete in 2-4 hours, not 2-4 days.
Look for issues tagged good first issue, newcomer-friendly, or help wanted. If none exist, email your mentor: "Hi [Name], I'm ready to make my first contribution. Could you suggest a beginner-friendly task that would help me understand the codebase?"

When you find a task, claim it publicly. Comment on the issue: "I'd like to work on this. I'll have a draft PR by [realistic date]."
Here's what good claiming looks like: You give yourself a deadline. You're accountable. Mentors can see you're serious.

Then actually do the work. And here's the secret: your first contribution will probably need revisions. That's not failure. That's the process. Expect feedback. Welcome it. Respond to it quickly.
My first contribution was fixing a typo in documentation. Took 30 minutes. Got merged in 24 hours. It was tiny, but it taught me the entire workflow: fork, branch, commit, push, PR, review, merge. Now I understood the mechanics.

My second contribution was writing a missing setup guide. Took three days. Went through two rounds of feedback. Taught me how to communicate with reviewers and iterate on work.

The Recording Step Everyone Forgets
Here's where people lose eligibility: they make contributions but forget to record them on the Outreachy website.
After each contribution is accepted, go to your project page on Outreachy.org. Click "Record contributions and create a final application." Add the contribution with:

Date you started
Date it was accepted
URL to the PR, patch, or work
Brief description

Do this immediately after each contribution. Don't wait until the last week and try to remember everything you did.

What Actually Matters to Mentors
After four days of watching other applicants and talking to mentors, here's what I've learned they care about:

Communication over perfection. They'd rather see you ask questions and submit imperfect work than disappear for a week and submit something mysterious.

Consistency over volume. One person made 15 tiny contributions. Another made 2 substantial ones with good documentation. The second person got more mentor attention because their work showed depth.

Understanding over execution. If you submit code you can't explain, that's a red flag. If you submit simpler code with clear comments explaining your reasoning, that's impressive.

Initiative over waiting. When you're blocked, do you sit quietly or do you post in chat: "I'm stuck on X, here's what I've tried, what should I try next?" The second approach shows resourcefulness.

The Mindset Shift That Helped Me
I stopped thinking "I need to impress them with my skills" and started thinking "I need to show them I can learn and collaborate."
Outreachy isn't looking for experts. They're looking for people who can:

Communicate clearly when stuck
Accept and implement feedback gracefully
Work publicly in a community
Learn new things quickly
Contribute consistently

You already proved you face underrepresentation in tech by getting your initial application approved. Now prove you can thrive in an open source community despite that.

Your Week One Checklist
By day seven, you should have:

Read the applicant guide thoroughly
Chosen your project and joined communication channels
Introduced yourself to mentors
Completed environment setup
Made at least one contribution attempt (even if not merged yet)
Started your second contribution
Recorded everything on Outreachy.org

That's it. You don't need ten contributions in week one. You need to show up, communicate, and make steady progress.

Final Thought
It's now Wednesday, March 25th. I'm five days in. I have two contributions accepted, one in review, and a growing sense that I can actually do this.
The panic from Friday night has transformed into focused work. Not because I suddenly became an expert, but because I stopped trying to be perfect and started trying to be consistent.

If you're reading this the night you got approved, here's my advice: Close this tab. Read the applicant guide. Join your project's chat. Introduce yourself.

Then get some sleep. You've got 26 days ahead of you. Start tomorrow fresh.

You've got this.

Discovering Fedora: My First Days in an Open Source Community That Actually Lives Its Values

Ibrahim Olawoyin — Tue, 24 Mar 2026 20:21:05 +0000

Friday, March 20th, 2026. 5:00 PM.

The notification landed in my inbox: "Your initial application for Outreachy has been approved."

I stared at the screen, re-reading it twice. I was moving to the contribution phase.

Now came the hard part: choosing which project to work on.

I scrolled through the Outreachy project list, past dozens of opportunities. Then I saw it: Develop a SLM/LLM using RamaLama RAG based off Fedora RPM Packaging Guidelines. Fedora. I'd heard the name before in Linux circles. But I didn't really know what it was. Not yet. Four days of research later, here I sit, writing this as a newly minted member of the Fedora community. And honestly? I'm impressed.

Let me tell you why.

What Actually Is Fedora?

When I first told a friend I was applying to work with Fedora, they asked: "The hat company?"

No. Not the hat.

Fedora is a free and open-source operating system based on Linux. Think of it like Windows or macOS, but completely free, transparent, and community-driven. But calling Fedora "just an operating system" is like calling a library "just books." Technically true. Completely missing the point.

Fedora is three things:
1. Fedora Linux: The Operating System
Fedora Linux is what you install on your computer. It comes in different flavors depending on what you need:

Fedora Workstation: For developers and creators (this is what most people use)
Fedora Server: For running servers and infrastructure
Fedora IoT: For Internet of Things devices
Fedora CoreOS: For containerized workloads

What makes it special? Fedora gets new technology first. When there's a breakthrough in Linux, Fedora adopts it fast. New kernel version? Fedora has it. Latest GNOME desktop? Fedora ships it. You're not just using Linux. You're on the cutting edge.

2. The Fedora Project: How It All Comes Together
The Fedora Project is the global collaboration that builds Fedora Linux. It's sponsored by Red Hat (the world's leading open-source company), but run by a worldwide community of volunteers and Red Hat employees working together.

Here's what I found fascinating: Fedora isn't just Red Hat's playground. It's a genuine partnership. Volunteers and employees have equal voice in decisions. The community drives innovation, and Red Hat provides resources and infrastructure.

The relationship works because both sides benefit. Fedora gets corporate backing without corporate control. Red Hat gets a testing ground for innovations that later flow into Red Hat Enterprise Linux (RHEL).

3. The Fedora Community: The People Behind Everything
This is where it gets interesting.
The Fedora community isn't just users. It's thousands of contributors from every continent, working on everything from code to design to documentation to event planning. When I joined the #mentoring Matrix channel this week, I was greeted within minutes. Not with "read the docs first" gatekeeping. With genuine welcome and offers to help. That's the difference between a user base and a community.

The Four Foundations: Why Fedora Does What It Does
During my research, I kept seeing references to "the Four Foundations." I assumed it was marketing jargon. Then I learned about Fedora Community Outreach Steering Committee (CommOps) and how the Four Foundations were formally adopted to guide every decision Fedora makes. These aren't suggestions. They're non-negotiable principles:

Freedom
Fedora uses only free and open-source software. No exceptions. No proprietary drivers hiding in the background. No "open core" models where the good stuff costs money. Every line of code is available for you to inspect, modify, and redistribute.

Why does this matter? Because it means I can trust what's running on my computer. No telemetry I can't disable. No features locked behind paywalls. Just software that respects my freedom.

Friends
The Fedora Code of Conduct isn't just posted and forgotten. It's actively enforced. The community genuinely practices "be excellent to each other." I've asked what probably seem like obvious questions this week. Zero condescension. Just patient explanations and pointers to helpful resources.

In tech, that's rare enough to be worth mentioning.

Features
Fedora leads. Others follow.
Systemd? Fedora pioneered it. Wayland? Fedora adopted it early. Flatpak? Fedora helped develop it.

The tradeoff: sometimes things break because you're running tomorrow's technology today. But that's the deal. You get innovation at the cost of occasional instability. For me, that's exciting. For enterprise users, that's what RHEL is for.

First
Fedora doesn't wait for consensus. It experiments, iterates, and ships.

The RamaLama project I'm working on is a perfect example. Instead of waiting for AI tools to mature on proprietary platforms, Fedora said: "Let's make AI accessible through containers right now."

That boldness? It's baked into Fedora's DNA.

What I Find Interesting About Fedora
Three things grabbed my attention this week:

1. The SIG Structure
Fedora organizes work through Special Interest Groups (SIGs). There's a SIG for almost everything: Python packaging, gaming, design, internationalization, AI/ML, security. Each SIG operates semi-independently. They set goals, make decisions, and ship work without endless bureaucracy. It's decentralized decision-making at scale. And it works.
2. Fedora's Relationship with Upstream Projects
Fedora doesn't just package software. They contribute back to upstream projects. When Fedora packagers find bugs, they fix them in the original project, not just in Fedora's version. This "upstream first" mentality means improvements benefit everyone, not just Fedora users.
3. The Diversity Initiatives
Fedora Week of Diversity (FWD) isn't a token effort. It's a week-long celebration with talks, workshops, and genuine community building.

The Contributor Stories initiative highlights individual contributors regularly. Not just core developers. Everyone who makes an impact. Representation matters. Fedora gets that.

What Still Confuses Me About Fedora
I won't pretend I understand everything.

The ecosystem is vast. Fedora Workstation, Server, IoT, CoreOS, Silverblue, Kinoite... I'm still mapping out what each variant does and when you'd use one over another.

The package management system (DNF) is powerful but has a learning curve coming from other Linux distributions. And I'm still wrapping my head around how RPM packaging works. That's actually what my Outreachy project is about, so I'll be learning in public over the next few weeks.

Advice for Future Outreachy Applicants
If you're reading this next year, preparing to apply, here's what I wish I'd known:
Start with the Fedora join page It's the clearest entry point.

Don't wait to feel "ready." I almost didn't choose this project because I thought I needed to be a Fedora expert first. The community wants newcomers. Your fresh perspective is valuable.

Actually join the Matrix channels. Reading documentation helps. Talking to people helps more. The #mentoring channel is specifically for people like us.

Pick a project that genuinely interests you. I chose the RamaLama AI project because I'm fascinated by making AI accessible. That genuine interest will carry you through the challenging parts.

Read the Applicant Guide thoroughly. Outreachy has clear expectations. Meet them.

Why This Matters
I grew up without easy access to tech resources. Open source changed that. It gave me tools to learn, to build, to prove what I could do.
Fedora takes that idea and scales it. Not just "here's free software." But "here's a community that will teach you, support you, and value your contributions from day one."
Four days ago, I was an outsider researching project options.
Today, I'm a contributor with a FAS account, a blog, and actual work to do.
That transition happened because Fedora doesn't just talk about being open. They structure their entire community to turn curious newcomers into effective contributors.

What's Next
I'm diving into the RamaLama project: building an AI model using Retrieval Augmented Generation to help Fedora packagers follow RPM guidelines.
It's ambitious. It's technical. It's exactly what I want to be doing.
If you're curious about Fedora, start at fedoraproject.org. If you're thinking about Outreachy, start at outreachy.org.
The community's waiting. And they actually mean it when they say everyone's welcome.