Looking Back (Days 23-27)
Last time, I spent more time on "organization and improvement" than "writing code."
- CI/CD permission fixes and security hardening
- Project management documentation organization
- Detection rule test additions and accuracy verification
- Documentation restructuring
I strongly realized that the behind-the-scenes of OSS development is supported not by flashy feature additions, but by steady improvements and visualization.
Day 28 (8/4) — Reviewing Project Direction
After running for over three weeks, I was caught by one anxiety.
The feeling of "progressing but not seeing where we're heading."
Sure, the code was working, and we could feed Nginx logs to Falco.
But the days were consumed by immediate challenges like "fixing errors" and "reducing noise,"
leaving behind "what shape this plugin should ultimately take."
Background of Confusion
- Unclear feature priorities: Wavering between advancing SQLi/XSS detection or prioritizing noise reduction.
- Blurred user persona: Should we target all Nginx users or focus on a subset of Falco users?
- Documentation chaos: README, Contributing Guide, and others scattered, unclear what's latest and what to prioritize.
Review Process
TK: "Not just the speed of progress, but the direction needs review too."
Me: "I see, a project needs a compass."
Opening a Markdown memo, I organized the following:
- Purpose: "Visualize Nginx attack patterns with Falco"
- MVP: "Support standard Nginx log format, detect SQLi/XSS/Path Traversal"
- Room: "Leave extension points for users to adapt to custom logs"
Results
- Documented as "Project Direction Memo" and added "Problems to Solve" to README.
- Narrowed user persona to "Falco users who use Nginx."
- Organized tasks into two tracks: "detection rule enhancement" and "noise reduction."
Reflection
OSS attracts collaborators by clarifying "what to build." Words become the compass, not just code.
Day 29 (8/5) — Cycles of Implementation and Improvement
This day I focused on code again. Reviewed log parsing logic and added test cases.
Results were mixed. SQLi was detected, but XSS slipped through, and harmless logs were falsely flagged.
Me: "I thought I improved it, but broke something else."
TK: "OSS development is whack-a-mole. Take it one at a time without rushing."
Reflection
Both failures and improvements build strength through small accumulations. The feeling of progress turns into confidence.
Day 30 (8/6) — Saved by Documentation
I forgot the intent of code I wrote a few days ago and got stuck.
What saved me was the development notes.
Reading the line "This conditional is to avoid false positives," I could fix it without hesitation.
TK: "Documentation saves your future self."
Me: "Documentation is like a time capsule."
Reflection
Documentation is the lifeline of OSS. It's a gift to your future self and colleagues.
Day 31 (8/7) — Policy Update Day
Today I spent time on project rule-making.
Clarifying review procedures and making tests mandatory.
Me: "I might be spending more time writing rules than code."
TK: "That's OSS. Rules are the mechanism that protects culture."
Reflection
OSS is culture. Policy gives form to culture. Removing ambiguity lets collaborators participate with confidence.
Day 32 (8/8) — OSS is for People
I suddenly realized. I'm making Falco read Nginx logs, but the real purpose is enabling someone to detect attacks with peace of mind.
Crying over errors, struggling with noise, continuing to write documentation.
I realized all of it is an investment for future users.
Reflection
OSS is not code but the accumulation of trust.
Tasks and Documentation from Days 28-32
Implementation Tasks
- Log parsing improvements and test additions
- Detection rule accuracy adjustments (SQLi/XSS re-verification)
- Repeated bug fixes and improvements
- Minor CI/CD fixes
Created/Updated Documentation
- Project direction memo (clarified MVP and user persona)
- Contributing Guide additions (review and test requirements)
- Policy update records
- Development notes additions (fix reasons and history)
Summary
These "Days 28-32" were a period of organizing not just implementation but direction, culture, and trust.
OSS is both a collection of code and a collection of culture.
I'm still immature, but by recording failures and learnings, I feel I'm getting closer step by step to "OSS that people can use."