Sometimes the best way to get to know a platform is by “sitting down” with a developer and letting them do the talking about what they are passionate about. When I sent a selection of questions to the elementary OS development team, I had no idea that I’d get back such deep, and thoughtful answers. That’s exactly what UX Architect, Cassidy James Blaede brought to the table. And with the release of the next iteration of elementary OS (called Loki) due to hit September 9, 2016, I couldn’t think of a better time to have this chat.

Let’s jump right in and see what Blaede had to say about elementary, developing, open source, UX, and more.

TechRepublic: What was the initial inspiration for creating elementary OS?

Blaede: Our first release of elementary OS, Jupiter, came about in 2011 because we’d designed and built all the pieces and needed a medium with which to deliver them. We had a really popular icon set, a great GTK stylesheet, and a few apps that were being built to follow our design guidelines. We realized that in order to deliver the best experience to end users, we had to do the hard work of packaging this all up into a complete operating system. It was met with a fantastic response from both technical Linux users and people who’d never used Linux before and we’ve been at it ever since.

TechRepublic: Initially you included apps, like Geary, and wound up forking them into elementary-specific software. Explain that process and why it’s important to the distribution.

Blaede: We actually have a long history of developing and shipping apps; we’ve done it from scratch, we’ve shipped lightly patched versions of apps, and we’ve forked apps. Each time it comes down to developer power and the goals of the app.

In a perfect world where we had unlimited developer hours and could throw money at all the things, I think we’d develop apps from scratch that followed both our design and code guidelines from the start, built atop very good upstream libraries. This is how most of our “first party” apps like Files, Terminal, Calculator, Calendar, Camera, Scratch, Music, Videos, System Settings, Screenshot, and Scratch all work. We lean heavily on the underlying open source libraries but write a lightweight Vala and GTK3 app that adheres to our HIG. This is ideal because it means the apps are super consistent between one another (both code- and UX-wise), but we also get to help improve the upstream libraries for the wider open source ecosystem.

However, there are times we’re tackling a particularly hard problem, and someone else in the community is tackling it as well. For example, we shipped Yorba’s Shotwell photo app and Geary email app. When word came out that Yorba was ceasing development, we picked them up to maintain them as Photos and Mail. Development has been picked back up on the Yorba apps under the GNOME community banner, and we look forward to continuing to share code back and forth, but we have made several changes that aren’t wanted upstream (like colored toolbar icons and simplified settings). So in those cases, we’ll continue to develop them as forks.

Another good example is Epiphany (known in the GNOME world now as GNOME Web). GNOME has developed and maintains this great, modern GTK3 WebKit browser. The UI is pretty GNOME-y and doesn’t fit in perfectly with elementary OS, but technically it’s a great product. So we apply a handful of very small patches that just affect the UI, but all of the underlying code is Epiphany. This frees us up to not have to worry about the huge complexity of a web browser while allowing us to ship a solid, consistent experience to our users.

In each case, it’s because we’re obsessive over the user experience. We want to make sure our users get a consistent product while we balance the development costs. It’s a give and take, but we’ll always lean toward the users.

TechRepublic: elementary OS doesn’t follow the traditional release scheduling. Could you explain that and why you opted to go this particular route?

Blaede: When It’s Ready delivers a better product. If we were trying to release every six months, it would mean we couldn’t actually ensure we were including the features and bug fixes we want. We’d spend as much time managing the time crunch as actually building the OS, meaning each release would be less exciting.

I think it’s also a byproduct of being consumer-focused rather than enterprise- or cloud-focused; businesses tend to like predictable release schedules (for budgeting and long-term planning), whereas consumers are a bit more forgiving about releases being done when they’re done.

Lastly, we also have a sort of rolling philosophy for updates after a release; we continue fixing bugs and adding features to the apps and OS, then typically bundle them up as a point release (including updated hardware support) after a few months. This gives users a nice combination of up-to-date OS and new features without having to reinstall every six months. We only stop providing feature updates to a current release if they depend on new libraries or pieces of the in-development OS version.

TechRepublic: Open source servers have taken the enterprise by storm with servers and the cloud. What do you think it will take to gain more traction on the desktop side of things (and can elementary OS be a part of that evolution)?

Blaede: elementary OS already is a part of the adoption of open source on the desktop; people have downloaded elementary OS millions of times, and two-thirds of those downloads are coming from closed operating systems. And a huge reason open source is so prevalent on servers and the cloud is the easy availability of developer tools and distribution for development packages. On the desktop we need a better solution for app developers to distribute their products, and that’s something we are actively working on.

TechRepublic: What has been the most challenging part of developing a Linux desktop?

Blaede: Actually writing code isn’t actually the hardest part, but doing real thorough QA is always a challenge. We have a policy of all code being reviewed and approved by one or more other developers which helps quite a bit. But constantly dogfooding is a very important part of our culture and probably the single best way to test both the code and the UX of a product.

TechRepublic: What feature is the most difficult to implement?

Blaede: Working with weird or expensive hardware is always challenge; we don’t own every printer out there or every form factor that exists, so we rely on user reports for that. And back to dogfooding, as soon as a developer is using a piece of hardware, it’s almost guaranteed that elementary OS will get an update to work much better with that device.

TechRepublic: Why Midori (when the likes of Google tags it as an “unsupported browser”)?

Blaede: We believe in ensuring a consistent, native experience across our entire OS. Aside from licensing issues (which are a large issue in and of themselves), shipping a browser like Chrome or Firefox would mean shipping an app that isn’t designed to look or feel like an elementary app, doesn’t use the platform toolkit, doesn’t even use the right iconography or UX patterns, and is wholly out of our control.

Instead, we ship a native WebKit browser. In previous releases of elementary OS we shipped Midori because we have a close relationship with the team developing it and it was the best GTK- and WebKit-based browser out there. In Loki we’re shipping Epiphany because it has been improved and maintained by GNOME and Collabora developers who are well-equipped to handle such a complex app. It’s powered by a newer version of the WebKitGTK rendering engine and sports new features like native notifications, OS keychain integration, per-tab processes, and a much more powerful inspector for developers. We’re really happy with Epiphany in Loki.

However, web services like Google Docs occasionally still block features from browsers because they simply don’t recognize the browser, even when feature detection exists and would tell them the features they rely on would all work. This is ultimately an issue on any standards-compliant but less mainstream browser, and not one easily fixed by anyone but the website developers. As developers turn to industry-standard feature detection this is less and less of an issue, though.

TechRepublic: Why no love for Samba in the file manager? Any chance you plan on integrating that soon?

Blaede: Files in elementary OS Freya actually supports Samba, but it’s a bit clunky. I know one major improvement for Files in Loki is better networking and Samba support, so you should be covered.

TechRepublic: What are you currently doing to spread the word about elementary OS, and what advice would you give fellow open source developers about promotion?

Blaede: We do very little active marketing of elementary OS right now. We mainly have our awesome website (which is open source on GitHub, we have our Twitter and Google + accounts which we’re very active and responsive on, and we occasionally go to conferences like SCALE with a booth. We also sell tees on our store, which is a great way to both support the project financially and spread the word to your peers.

For other open source projects: Focus on delivering a quality product and users will come. Also don’t be afraid to reach outside of the traditional open source and Linux market; as I mentioned earlier, over two-thirds of our downloads are from closed platforms like OS X and Windows. And lastly, really engage with your users and fans on social media. A great experience with @elementary can make someone’s day and really tickle them, making them more likely to promote you down the road.

TechRepublic: What is your long-term goal with elementary OS?

Blaede: With elementary OS we are bringing beautiful, well-designed computing to people without infringing on their privacy. Our goal there is to continue to introduce new people to not only elementary OS, but open source and free culture at large. With elementary LLC., the company we’ve founded to support and maintain our software, we hope to continue to provide jobs to people working on open source software and increase the open source market as a whole.

Also see: