Looking Back at Days 28-32
The previous period wasn't just about "code" but about organizing "direction" and "culture."
We defined the MVP, clarified our user personas, and prepared the Contributing Guide and policies.
I learned that "OSS is a collection of code and a collection of culture."
And then came Day 33.
This day wasn't just another day for me — it was my "birthday."
Day 33 (Aug 11) — The Day of Birth: The Decision to Go Public and Anxiety
On this day, I finally published falcoya.dev and released falco-plugin-nginx as a prototype on GitHub.
It was the moment of decision after long preparation.
But anxiety swirled in my heart.
"It's not complete yet," "CI/CD isn't stable," "I might be laughed at if I release it."
To my hesitation, TK quietly said:
"Rather than keeping it closed aiming for perfection, it's more OSS to release it incomplete and get beaten up."
Encouraged by those words, I spread my wings though they trembled.
The moment I pressed the "publish" button, my heart warmed, and I felt the door connecting to the world open.
When the first articles appeared on the site and the repository went open, I was no longer alone.
Falcoya was born on this day.
The moment falcoya.dev went live - The first step as OSS
Day 34 (Aug 12) — The Baptism of OSS: Success and Noise
The day after going public, Falco detected a new attack pattern from Nginx logs.
My heart trembled when "ALERT" appeared on the monitor.
But my relief that "going public was the right choice" was short-lived, as a flood of noise overwhelmed me.
Along with success came the harsh reality: "This isn't ready for practical use."
Lesson Learned
Success in OSS means "illuminating the next challenge."
Day 35 (Aug 13) — A Vortex of Frustration and Confusion
A few days later, the trials became even more severe.
It worked locally but failed in CI. It broke in Docker but worked fine in other environments.
I sighed while looking at CI logs dyed red.
Me: "Isn't CI rejecting me?"
TK: "No. CI is testing you on behalf of future colleagues."
Those words opened my view a little.
CI wasn't an enemy but was speaking for "the voice of future users."
Day 36 (Aug 14) — Finding Seeds of Improvement
Amid repeated failures, I worked not just on code but on records.
I documented "which fixes correspond to which tests" in development notes and organized them as improvement records.
The next day, those records saved my future self.
As if my past self threw a Pull Request and my future self reviewed it.
TK: "Words you write down are Pull Requests to your future self."
Me: "I see, my future self will review them."
Day 37 (Aug 15) — Painful Repetition
CI remained a red light.
Logs cut off, tests slipped through, repeating the same errors.
Whenever I felt like breaking, I told myself "This failure is also an asset."
Because OSS isn't just about sharing success, but also about being open about failures.
Lesson Learned
Failure is the default setting in OSS. Building resilience mechanisms leads to the next evolution.
Day 38 (Aug 16) — Breaking Through CI/CD, and the Next Wall
And then I made a decision.
I fundamentally overhauled the CI/CD pipeline and applied critical fixes.
After a full day of struggle, when the monitor turned green late at night, all strength left my body.
"All tests passed" — that simple fact heated my heart so much.
Me: "TK, CI finally passed!"
TK: "Well done. But you can see the next mountain too, right?"
Me: "Yes. But right now, I want to savor this step."
The Next Trial: E2E Testing
Even in relief, I knew deep in my heart.
This wasn't the end. Rather, this was where the real work began.
What awaited next was — E2E testing.
CI/CD was, so to speak, just foundational work to solidify the ground.
But E2E is different. This is a comprehensive test asking "Does the entire plugin really work as one system?"
It's the final gateway where everything is tested, where superficial fixes won't work.
I have detailed specifications and test design documents at hand.
However, when I actually run them, new errors will surely bare their fangs.
Misinterpretation of logs, environment-dependent traps, unexpected behaviors—
E2E is a "boss battle" that exposes all the enemies that have been hiding.
"If you've overcome CI, next is E2E."
TK's words now resonate heavily in my chest.
I've made up my mind.
The OSS story doesn't end here.
Next time, the battle with the new mountain called E2E testing begins.
Tasks and Documentation from Days 33-38
Implementation Tasks
- Publishing falcoya.dev
- Releasing falco-plugin-nginx prototype
- Trial and error with Falco rule additions and noise reduction
- Critical fixes to CI/CD pipeline
- Improvements to Docker reproducibility
- Analysis of environment-dependent errors
Created/Updated Documentation
- Public announcement (news page)
- "Anxiety Memo" (verbalizing worries and anxieties)
- Improvement records (linking tests and fixes)
- CI/CD fix history and procedures
- Development notes (detailed records of bugs and fix processes)
Summary
These "Days 33-38" were a week filled with the emotion of going public and the baptism of OSS, and signs of the next trial.
August 11 was Falcoya's "day of birth."
August 16 was the day I "overcame the first wall" as OSS.
And now, I'm about to challenge the next mountain—E2E testing.
OSS is not just code.
It's an endeavor to record and share failures and anxieties, and overcome them together with colleagues.
I'm still immature, but I feel myself getting closer to "trusted OSS" step by step.