Expressive is a new kind of web CMS, built with Node.js and Express. It’s an ultra-clean and modern, simple and extendable publishing app for blogs, websites, portfolios and many other kinds of digital content. It bundles common open source packages, and makes it easy for developers to build comprehensive extensions and themes for your site. Expressive isn’t ready for production use yet, but the project is available on GitHub for contributions and testing during the development cycle. This is my first open source project that is available on GitHub before it’s finished. Expressive is set up with Travis CI testing, and Coveralls.io code coverage from Mocha and Istanbul. Before moving to the public GitHub space, I rarely pushed non-critical commits to the world, and now I’m using GitHub Issues and GitHub Wiki for Expressive as well. Throughout the cycle of opening permissions to my in-development projects, I’ve asked myself many questions about what could change through contributions and scrutiny of such a large variety of developers. Here are a few of the answers to my own questions.

Who is going to benefit from my unfinished code on GitHub?

I didn’t discover the answer to this question until I set up Expressive with Travis CI. This is my first project to publicize the development and testing process, and I’m learning new ways to write better tests overall. At home, I run an OS X server powering Atlassian Jira and Bamboo, where I manage my internal projects, time tracking, testing and deployment. I’ve always seen those badges on GitHub projects claiming “Builds pass” or “99% Coverage” and I wanted to jump on the free CI bandwagon. As I was publishing my code, I started challenging myself to write better code. The idea that “this code is going to be seen by all the [one-or-two] people who checkout my project,” pushed me to make sure that I was writing clean, tested and understandable code. No one should be littering up GitHub with shitty projects, and I didn’t want to be that guy.

Will anyone understand the logic to my app’s design?

This is another question that brings up the don’t litter GitHub with shitty projects idea. Since I published my project online, I’ve found many sore spots in my app through testing and code coverage reports. A lot can be said about a complex app, but more can be said about an app that lets you easily start building onto it. I also wonder if anyone really cares that they don’t understand the logic to my app. Expressive’s goal is to be a great CMS for non-technical users and for developers. By giving developers a preview about where my project is now, what it’s going to look like when it’s ready for extensions, and where it’s going to be in the future, I’ve felt better about my project. Of course there isn’t much traffic on the alpha project, but as Expressive develops, I hope to grow an amazing ecosystem of extensions and developers.

What if developers try to turn my app away from my vision?

I’ve seen this happen often in my professional career—where my idea or pull request is quickly crushed by “dirty” code from other developers sneaking into my app—and it was one of the last things I wanted for Expressive. I’ve also found myself struggling to work efficiently on a team of other developers, since control is one of the last things I can give up in a project. Although it’s hard, I have been forcing myself to realize that the projects I build are not for me—they are for the rest of the world and the people who are using the app. So letting the “perfect” code I write be “polluted” by the collaboration of other developers isn’t a loss, because in reality, my code is not perfect and I’m not one to declare other code to be dirty. And if it is, I can just reject the pull request.   If you’ve questioned publishing your content online, write some of what your concerns have been in the comments.

Available on GitHub
Up Next
Demystifying iOS 8 Storage Providers