Ello is now open source by default.

(Cross-posted from Ello)

From the very beginning, one of Ello’s guiding principles has been openness: we strive to maintain a spirit of transparency throughout everything we do.

That manifests in various aspects of Ello’s operations: how we communicate internally, ways we solicit feedback from people on the network, how we plan and implement product decisions, how we update policies and terms, and many others.

One thing we haven’t done a great job of to date is exposing the work that goes into building and maintaining the software that runs Ello. There’s a lot of amazing engineering that goes on behind the scenes here. The engineering team is comprised of some of the most talented individuals I’ve had the opportunity to work with (@mk, @666,@sean, @colinta, @holmezi, @alanpeabody, and @totallymike). Many of the challenges we face are by no means specific to our product or our team. Talking about those things openly is not only a great way for us to share what we’ve learned, but also to talk frankly about challenges and issues that arise along the way.

Our own engineering efforts are standing on the shoulders of giants in that much of Ello is built on a foundation of open-source software. Everything from our webapp (built in Ruby/Rails), to our iOS app (written in Swift and heavily inspired in architecture by Artsy’s Eidolon) to our infrastructure (deployed on Linux and Heroku) to the dozens of other libraries we use for a variety of other functions make use of open source components that have come into existence through thousands of hours of effort from people outside of Ello. We do our best to be good citizens within that ecosystem, contributing upstream when we fix or improve the dependencies we use and opening up reusable libraries (to date, largely infrastructure tools and things like a port of Rails’ time_ago_in_words to Swift). In our view these things are table stakes, however, and we can do better.

Artsy, 18F, and Buffer have codified approaches that involve making their engineering teams’ work open source by default. They’ve all written about their experiences extensively, and in fact, we had a great conversation with Ash and Orta from Artsy a few weeks back that crystallized a lot of our thinking about our own approach. In talking with our team over the course of the last few months, it’s become clear that the benefits to us far outweigh any drawbacks, and to be honest, the level of excitement that these discussions have engendered is a great positive indicator that we’re onto something!

So — as of today we’re taking the plunge and Ello is going open source by default.

What this means is that we’re going to begin sharing more and more of what we do, both here on Ello and through Github. Our goal is to get as much of Ello out from behind the curtain as we can, though some pieces will take a bit more time and effort to get tidied up than others. And of course, there are some components that may never be opened up, not for a lack of will, but because the effort required to do so would just be far greater than any potential benefit. But fortunately, that’s not the case for most of what we do.

Today we’re starting out by opening up two components:

• WTF is a Jekyll app that powers all of the static content in our help and about pages. Originally built for us by @gb, with a workflow and tooling inspired by the approach Github takes to managing their docs, it’s an independently-deployable app that gets proxied into the main Ello app via Nginx. Our engineering team maintains the code for the site and @anna and her customer service team manage the content.
• Streams is a RESTful Go wrapper and Ruby client library for interfacing with Soundcloud’s Roshi CRDT service. We’re slowly migrating the time-based activity feeds within Ello from our sharded PostgreSQL cluster to Streams/Roshi instead. While that’s a topic worthy of a post of it’s own (which is in the works), the TL;DR is that there are substantial cost and operational benefits of the CRDT approach over our current approach, and we’re excited to keep rolling that out. Most of the heavy lifting on Streams was done by @rtyer.

We feel strongly that it’s important to set clear ground rules about what we’re expecting from this and how we want to interact with potential contributors:

There are two different categories of code we’re opening up, each with its own set of expectations for community and contribution.

On one hand, we have library and infrastructure code — things that are more generic and reusable. These are the sort of things that we can more easily envision starting to grow communities around, albeit small ones.

On the other hand, we have custom-built applications, which are likely to have limited utility outside of their current purpose due to size and coupling to other parts of Ello’s infrastructure (the Ello API, for one). We don’t envision these apps building much of a community around themselves in the way that most open source tools and libraries do, and see the primary value in opening them up coming as a result of increased transparency. That having been said, we’ll certainly accept pull requests that fit our product roadmap and engineering standards, should anyone feel like jumping in and contributing!

We’ve chosen to release these two projects under the MIT License. We debated internally whether MIT or Apache would be the more appropriate choice for us given both our stage and our goals as a company. MIT is far easier to manage (no need to manage CLAs, for one), so for now we’re going that route, but in the future Apache may be something that is worthwhile to explore.

We’re not looking to seize ownership of anyone else’s contributions to Ello, but it is important for us to ensure that we have the rights to use any code that gets incorporated into Ello — otherwise the contributions wouldn’t be of any use to the Ello community! It’s possible to do that under MIT, but a CLA does make it more explicit, which isn’t necessarily a bad thing. At our current age and stage, we feel like the reduced friction associated with non-CLA MIT-licensed codebases is more aligned with what Ello represents and the kind of community we wish to build.

We take security very seriously and do our best to deal with any security-related issues responsibly and promptly. This move doesn’t change anything about that approach. For more information, reference Ello’s security policy.

Ello was created by idealists who believe that the essential nature of all human beings is to be kind, considerate, helpful, intelligent, responsible, and respectful of others, and we want to carry that spirit with us into the open source realm. To that end, we will be enforcing the Ello rules within all of our open source projects. If you don’t follow the rules, you risk being ignored, banned, or reported for abuse.

We’ll continue to provide updates here as we open up more of the code behind Ello, and have more to share about our engineering approach.

The entire Ello team is excited about this new, more radically transparent mode of operation, and we can’t wait to share the journey with you. The code for both components is available right now at https://github.com/ello.

Feedback and/or pull requests are very welcome!

Jay ZeschinChief Architect & Co-Founder at Ello@jayzes