Building Lemmy in Public

It is really hard to find for-profit projects that are built with any meaningful level of transparency to the users, and I know because I've helped build several. It's something that has always bugged me about the software world, especially as a developer who would love the chance to learn from the hard-won lessons of other firms and their development teams.

Some larger firms and application development teams like Slack, Transit, and GitHub do have pretty excellent developer-centric blog content, but most often this presents a strictly rosy picture of the engineering world at these organizations. Having worked for several firms, from startups to larger companies, I can say definitively that things inside the walls are not always rosy. There's a realness that I find missing from this content, and not only that, there are problems being solved over and over by team after team that, if we were all just a bit more transparent about what it's like to build software, could be avoided.

When I set out to build Lemmy, I decided that I wanted to do things differently — I want to work in public, and not only that, I want to share details about more than just the rosy. There are aspects of the process of building software that are messy and I think it's important that other engineers who have interest in building applications have a window into this reality.

I am building Lemmy as a for-profit project, and so it's not part of the plan to make it fully open source, but I plan to use this blog as a way to bring transparency and insight into what is going on behind the curtain during development. Here you can follow along as I build features, squash bugs, gripe about state management, never have enough time, and hopefully build an application that will be of exceedingly high quality and the utmost utility to users.

This is the very start of the journey for me, and I hope that you join me as I build!

— Cheers!