I have tried multiple static site generators (SSG’s for short). Everything from the venerable Jekyll to bash scripts and everything in-between. I ended up settling with Roots as by tool-chain for a few reasons, none of them technical.

Here is why I stuck it out with Roots and will use it going forward:

  • Involved project lead (hat tip to Jeff Escalante @jescalan)
  • FAST developer feedback (via Gitter; think Slack for code repos)
    • I got a response to a non-bug in under an hour.
  • Involved developer community (240 Gitter followers, 26 contributors (Graph Here)
  • Corporate backed (and used in house, important!) by Carrot

Here is why I think these factors are important:

Involved project leads can command armies

It’s hard enough to get your own job done as a developer, let alone contribute to a side-project. With a tight constraint on time, we need more than excitement to keep pushing forward on open-source. A good leader inspires their open-source contributors not by the words they speak, but by the effort they put into the cause. Example: Linus and Linux.

Getting to the second “WOW”

I attended the APIStrat conference recently here in Boston and the #1 theme from the conference was “anyone should be able to use your API, and fast.” We call this “time to value (TTV)” in the pitch-decks, but the concept remains the same. In general, the faster you can get users to experience the “WOW” factor of your product, the more likely they will stick with your product. The problem with creating an open-source project, in a crowded space, is getting people who “trial” your project to get to “WOW” fast. This does not count:

npm install package && npm see-it-works!

Your users will screw something up. They have various environments and versions of Ruby, Python or Node. They might get the first example to work, but they will then want your project to solve their specific need.

I got stuck in my journey to setting up Roots, as I do with any new endeavor. The difference here was Roots has a responsive community. Look at the Salesforce.com developer community. Look at Swagger. All of these projects have FAST feedback loops powered by passionate programmers. This is really hard to do via documentation, but in my case was solved by the community.

Bugs are broken

When you submit a bug, you create a task for someone. It doesn’t matter what we call it, but that’s work for a select few people who actually know what’s going on in an open-source project. Due to a small core team and no triage unit, this usually requires one person to manage it all (and fix bugs), effectively taking on a second job. We again have to balance passion with effort.

Unless you’re paid to work on a project, you’re less likely to work on a bugs (long-term) than you are to create and enhance. Which leads us to our next factor…

Corporate sponsorship

It’s a needed evil, but unless it’s a problem that the Internet REALLY needs solved, someone has to get paid. I have friends that have killer open-source projects that get paid with the corporate dime. Vex and HapiPy come to mind. The top development shops today have enough money and human capital to invest in open-source for both lead-generation as well as developer recruiting (sorry, it’s not about karma). In fact, there have been companies that push effort into dedicated, exploratory time, such as Google.

So what’s next?

It’s a crazy idea (like super-crazy) but maybe there is some future where we have “open-source credits” that companies can buy. Kind of like carbon-credits but completely different. It’s a great recruiting tool to sponsor some genuinely interesting work and pay some hard working developers. Maybe some market develops that rewards developers based on their GitHub stars and forks. Until then, I’ll be putting some of my free hours into the Roots community as I am impressed.