Typically a release article is focused on a few key points of a new product. We’d highlight the new features, problems solved, and encourage you download the latest version right away. But if you’re reading this right now, chances are that you’ve been following along. You’ve read our Beta1 and Beta2 articles along with the miscellaneous app update articles as well as our updates on typography and icons. So instead of that song and dance, we’re going to tell you our story.
In April of 2011, a small group of high school and college kids released an Ubuntu 10.10 remaster that we called elementary OS “Jupiter”. And for us, it was huge. It was a demonstration of a desire to create a Linux-based OS that championed consistency and great design. It featured several home-grown apps and heavy patches to the UI of others.
It was well-received and its focus on first-party apps felt like a first in the world of Linux distributions that otherwise shipped a compilation of the most popular apps. But it was just the beginning and work was already underway on the next big thing.
By June of 2011, the team was already running experimental builds of our new desktop environment “Pantheon”. Late one night, developer Avi “aroman” Romanoff recorded and uploaded a video that quickly spread far beyond his original intended audience of elementary developers.
It was clear from the get-go that Luna would be all about getting things done, and a major component of that is apps that open and close instantly. But aside from optimizing the code, there was a push to optimize speed on the design side as well.
Early in the Luna cycle, new technologies caught our eye. We’d been using GTK2 as our toolkit, but GTK3 was coming and promised better widgets, theming, and functionality. We’d unofficially adopted Python as our programming language due to its relatively low barrier of entry and popularity with the Ubuntu community, but the newcomer language from GNOME, Vala, was faster and offered vastly tighter integration with GTK and other core technologies.
Everything we’d done up to this point was built on those old technologies and we didn’t want to fragment our efforts by supporting two generations of tech on our desktop. So we made a clean break: our development effort shifted completely to using GTK3 and Vala. Our old apps were either ported or scrapped. We made it a point to ship all GTK3 apps in a time when other Linux-based desktops didn’t even have GTK3 on the radar.
It was a massive undertaking; one we had largely underestimated. But on the other side of the transition was a platform with a single, fast, compiled language tightly coupled with a modern toolkit. The goal of providing developers with a concise set of technologies in turn made development much more straightforward and brought in contributors of all skill ranges.
As elementary grew, we saw that we were repeating the same techniques for developing apps that looked and worked beautifully. One developer would discover a way to make a slicker sidebar, then the other developers would copy and paste its source code, adapting it to their needs.
While this is one of the advantages of open source, it also became a burden when each implementation contained minor variations or inconsistent features, and bug fixes weren't always being shared across code bases in a timely manner. Creating Granite enabled us to set a solid foundation beneath our apps, round up the best implementations of widgets and utilities, and make them available to all apps. This helped immensely with widgets such as our sidebar, tabs, search, and more. If we ever find a bug or want to add a feature, we can do it at the Granite level and all apps will benefit.
Similarly, we created a new data-sharing component of the elementary desktop called Contractor. It was designed as a sort of middleman between apps so they didn’t need to be hardcoded to work with each other. Since then, we’ve worked to make it as seamless and robust as possible. It allows us to facilitate interoperability between apps without the apps having to be made specifically for one another. It also cuts down on code bloat by preventing each app from having its own implementation of a specific feature. And it offers a way for apps to be extended with new functionality without having to wait for an update.
In August of 2011, we announced Switchboard. Now referred to on the desktop as System Settings, it was a new app that gathered all system- and user-wide settings and put them into one place. In order to combat the idea that our fledgling desktop environment was less customizable than GNOME 2 (something that many Linux users valued highly), we made sure that it was built around third-party extensibility. We also announced a development sprint to populate it with many of its “plugs,” or options, that you see today.
In November of 2011, Daniel “DanRabbit” Foré posted an article on the elementary website explaining a new change that had just landed in developer builds of Luna. Most controversial was the decision to drop the “minimize” button from the default configuration. By this time a plan had already been laid out for the new standard of elementary apps: They would open and close instantly and even better, they would save their state before closing. Certain apps, like Music, were made to intelligently continue to run in the background when closed. For users, this meant a negligible difference between “close” and “minimize” with the side-effect that apps that weren’t in use wouldn’t be sitting around consuming resources. It’s no surprise that all of these changes would lead up to rethinking the way that elementary deals with multi-tasking.
That same month, while attending the Ubuntu Developer Summit, Allen Lowe, Avi Romanoff, Cassidy James, and Daniel Foré hosted a session to demonstrate the things that elementary had been working on. While the elementary team expected to be met with excitement, which we were, we were also met with caution and criticism from more experienced developers. Some called our fork of Nautilus hacky, questioned how long we might even be around, and were generally unimpressed with the lack of structure in our development process. Later that day, we sat down and had a great talk with Jason “DBO” Smith who put it bluntly by saying, “You guys are a great design shop. But you’re not a great code shop.”
Those words stuck with the team and we decided that we needed to bring more professionalism to our game. The first and most obvious thing to implement was code reviews. Up until that point, we’d trusted ourselves to push great code to the mainline development branch on the first try. But as anyone with experience developing software as a large distributed team knows, this doesn’t work. It was around this time that we adopted Cody Garver and David “Munchor” Gomes to our team.
When dozens of developers from different backgrounds work together on the same project, certain rules must be created to ensure that code remains clean, organized, and consistent. Without such rules, it is only natural that the code base will rapidly devolve into chaos. This is why many open source projects adopt coding guidelines which specify how code should be written and formatted. In addition, these rules also make it easier for new developers start contributing to the project.
With that in mind, a code style guide was assembled, discussed and approved. The guide was written with the existing code base in mind, while trying to look as similar as possible to most Vala code out there so experienced Vala coders still feel comfortable. David become the champion of coding with consistency and now stands vigilant watch over merge requests to ensure great, legible code. Cody became the project manager we so desperately needed, organizing bugs into milestones and focusing our development efforts on the most important issues.
Any time a large change occurs in a community of volunteers, it is going to create backlash. Code reviews aren’t really fun and egos can be bruised when someone’s hard work is rejected or needs to be revised. When faced with the need to be more stringent, some developers moved on. Most notably, Ammonkey, the lead developer behind Nautilus-elementary (the first elementary app) and later Marlin, decided to break ties with elementary.
The structure of the community was changing and the politics during this transition period hurt. However, growing pains are natural and from this change emerged a brand new elementary with a much tighter grasp on quality control. We’re now better organized and more prepared to handle the vast amounts of code we touch.
In early 2012, Daniel Foré began corresponding with Ian “Hexual” Cylkowski about a new professional identity for elementary. Much like our old code, our design was inconsistent without a canonical way to present our brand.
Ian worked extensively with elementary and the community to craft the best brand story that was both unique to us and a reflection of our ideals. He researched our users, interviewed our contributors, and tirelessly toiled away at our new identity.
After working with Ian, we revealed our new branding and unified it across our social media accounts and website. We’ve since grown into it and adopted it for our merchandise and everything official from elementary. We still have plenty of room to grow and continue to define the overall image, but Ian’s foundation has been a phenomenal addition to elementary. This new face set a tone for an elementary that is both high tech and also very human, with thin accurate typography, a minimal aesthetic, playful curves and bright colors.
In October of 2012, we retired the Jupiter release saying, “Jupiter has fallen behind. It was an awesome achievement for us when we released it, but we no longer feel confident offering it up for download on our site”. Work on Luna and an influx of users had shown us that Jupiter was flawed and couldn’t be supported. Additionally, the availability of developer builds of Luna on Sourceforge caused great confusion when eager testers expecting to see the new Pantheon environment downloaded Jupiter and instead got GNOME 2. This confusion between the latest public release, Jupiter, and the in-development Luna flooded our website’s “Answers” system, prompting us to close it at that time.
With all the changes happening on the desktop, we needed to make big changes on the web as well. The version of our website released alongside Jupiter may have served us at the time, but it was no longer up to our standards. Worse, it didn’t explain who we were, why we did what we did, what elementary OS was, or why people should care about it. It also carried a lot of the Apple-like design that we had worked so hard to shed with our new branding and the changes we’d made on the desktop.
Daniel Foré, Harvey Cabaguio, and Maxwell Barvian began churning out new designs. The new elementaryos.org needed to be spacious, feel clean, and directly communicate elementary’s mission to a wider audience. It had to reflect a new focus on providing great typography and a return to a much lighter design aesthetic.
Working from their designs, Kiran Hampal headed up our new web development team and created our brand new website. They worked from a fresh codebase, implementing all the features we needed to better serve our community. The new site is faster, prettier, more informative, and much more useful to our users, developers, and fans.
Almost immediately after retiring Jupiter, we released our first public beta of Luna, showing off everything we’d been working on in the last year and a half. Though we labeled it as an unstable beta, we intended it to be more like a release candidate; we hoped to squash any corner-case bugs in a relatively short amount of time, then release the final version. However, as is often the case, we discovered more bugs and more work for our developers.
About 6 months and over 300 bugs later we released our second beta with refinements to nearly everything in the OS. It was even more well-received by our testing community, but while it was clear that while Luna was running great for tech-savvy users, it still wasn’t quite where we wanted it to be for everyone else.
Late in the Luna development cycle, we adopted Google+. We created an official page for news and common interest items, which spurred discussion and encouraged people to share elementary with their friends. Soon after, Google+ opened communities: forum-like gathering places for people with common interests. We opened the official elementary Google+ community and saw a tremendous influx of testers, fans, and inquiries. With thousands of users and no software or extra servers for us to maintain, it has been the perfect way to encourage community development and discussion.
While Dan or an elementary developer would get an occasional interview for an open source blog, it never seemed too frequent or formal. However, as the anticipation around Luna grew, so did the interest of larger publications. Various news sites interviewed us, and recently the ever-popular Linux User & Developer magazine took out a three-page interview for members of the team. The increased publicity has helped spur continued healthy growth in community involvement.
The bigger elementary got, the more obvious it became that we needed to have an official entity responsible for everything it did.
We began selling shirts in the past few months as a way to promote elementary and to bring in some income. To do so, we needed to work with another company and order in bulk ahead of time. We’ve been pretty successful with sales: shipping shirts around the world to our excited fans. The proceeds from these sales go back into our funds to help fund future ventures.
You may have seen some elementary bugs with bounties attached; they’re bugs that, when fixed, provide a payout to the volunteer who fixes them. We’ve put our money where our mouth is on some of these bugs, and we’re excited to see them get fixed while providing a financial incentive for our contributors.
Of course, with all of the work that we do for free for elementary, there are intrinsic costs involved. We must pay for servers to host our fancy website, support materials, and documentation. We have to pay to maintain a merch store. We purchase shipping materials, paper, and traditional office supplies in order to be able to operate our merchandising business. We needed an official organization to manage such transactions and to ensure accountability with funds.
While elementary OS will always be community driven and open source, we’ve recently secured our position as a legitimate legal entity: elementary LLC. We’re now better prepared for a future of delivering goods, providing online services, funding development, and ensuring accountability.
It’s all come down to this. The countdown is up on the homepage while we get the final pieces in order. Cassidy James sends CDs to pre-orderers and gets new CDs, t-shirts, and stickers ready for shipping. Cody Garver waits, itching to upload the final ISO of Luna. Daniel Fore wordcrafts his remaining edits to this article. The entire web team sits in eager anticipation for the timer to run out and the new website to go live. Our fans frantically guess and take bets at what’s about to be revealed.
And when it’s over, you see the new homepage. You read this article. You finally know that after over 2 years, we are so incredibly proud to release elementary OS “Luna”.
Users can download Luna from the elementary website using the simple pay-what-you-want button on the homepage. Physical Luna CDs, as well as branded t-shirts and stickers, are now available and ship out starting today. If you pre-ordered a Luna CD, it is already on its way (or may have arrived; check your mailbox)!
It’s been a long road to Luna, but we’ve arrived in better shape than ever. Congratulations and our sincerest thanks go out to the entire community for riding along on this incredible journey.