Creating Open Source Projects: Lessons Learned from Building My Own CSS Framework

Ever dreamt of building something from scratch, proving your mettle as a software developer? I did. A week ago, I dove headfirst into creating my own CSS framework, thinking, "How hard could it be?" I quickly learned the difference between dreaming and doing. This is my story, a cautionary tale, and a guide for anyone considering diving into the world of open source development.

The Allure of Building Your Own CSS Framework

I was inspired by Skeleton, a Tailwind-powered adaptive design system but only utilized a fraction of its components. Driven by the desire to build my own tool, I started "Stratum." This isn't an advertisement; after this experience, maintaining it beyond my own needs is something I don't want to do. Instead, it's a lesson-packed journey into the realities of open source.

The "Fun" Part: Initial Naiveté

The initial idea was simple: take what I liked from Skeleton, add my styling, and maybe even create Svelte components. I'd learn a lot and maybe even build a small community. Reality hit hard. Brainstorming is easy, but executing a CSS framework is another beast entirely.

Diving Deep: The Learning Curve

If I were to embark on this, I wanted to do it right. That meant learning:

• Monorepos: Setup, project communication, and dependency management.
• Tailwind CSS Deep Dive: Custom utilities and cross-browser consistency for native elements.
• A11y: How to build quality, accessible Svelte components.

The challenge was rewarding, but the sheer volume of information became overwhelming quickly.

The Hard Truth: Smaller is Better

Soon, I realized I needed to be realistic. Maintaining a CSS framework in a reasonable time frame with one developer(me) wasn't possible. I created a lot of issues to solve, but I also created more issues. If I wanted to finish, I had to drastically reduce the scope. I dropped the idea of custom components and removed existing features. Even after trimming the fat, it was still a lot of work.

Beyond the Code: The Unexpected Workload of Software Development

Releasing v0.1.0 felt like a significant accomplishment. However, the coding was only half the battle. The non-coding tasks were daunting:

• Automation: How to automate version bumping and changelogs?
• Community Management: How would people contribute? Did I want to manage PRs, and issues, or foster a coding community?
• Marketing: Discord, community building, and promoting my CSS framework.
• Maintenance: Updates, migration guides, and documentation.

The answer to most of these questions was a resounding "NO THANK YOU." Tools like Changesets helped, but the overall workload was too much. Stratum became my personal CSS framework, a valuable tool that fell short of my initial grand vision.

Lessons for Next Time: If I Were to Try Open Source Development Again

Despite not wanting to maintain Stratum, here's what I'd do differently for a similar project:

• Team Up: Even one additional developer provides feedback and halves the workload.
• Realistic Scope: Before starting, assess the available time and effort. My initial scope was fit for a team of developers working over months.

A Newfound Respect

I now have immense respect for open-source maintainers. Whether funded or driven by reputation, their work is challenging, and their expertise could be used elsewhere. Thank you to all maintainers; your work is valued.

Even though Stratum didn't achieve its initial ambitious goals, I learned a lot and completed the core functionality. It will be used for my own projects.