In my last post I described how, during this year’s GUADEC, members of the GNOME community came together to plan where the project could go in the next 18 months or so. The slides from Xan and Juanjo’s talk give some of the background to those discussions. We took copious notes during the planning sessions that were held; these will all be available online soon, so you can get a more detailed picture if you want one. In what follows I’ll try to give a bit an overview.

But first, a clarification. The idea of GNOME OS has been around for a couple of years, and there has been a fair amount of confusion about what it means. Some people seem to have assumed that GNOME OS is an effort to replace distributions, so let me be clear: that is not the case. While the creation of a standalone GNOME OS install does feature as a part of our plans, this is primarily intended as a platform for testing and development. In actual fact, all of the improvements that we hope to make through the GNOME OS initiative will directly improve what the GNOME project is able to offer distributions.

Many of the things that we want to do as a part of GNOME OS are old ideas that have been around in the GNOME project for a really long time. The aspirations that are driving this process include things like providing a better experience for application developers, automated testing, sandboxed applications and broad hardware compatibility. While each of these goals could be pursued independently, there are enough interconnections between them to make a holistic plan worthwhile. Yes we could call the initiative something else, but GNOME OS has stuck, and it kinda fits (as I hope to explain a bit better below).

We’re setting out to drain swamps, fix the most glaring issues in our ecosystem, and establish a new model for the future. We don’t know whether we’ll succeed, but there are enough people in our community who care about these issues that we just might be able to do it. The best part is: you can help.



So what does GNOME OS mean? Here are the main areas that we addressed at GUADEC:

Application development and deployment

Right now, it is far too hard for developers to create and distribute applications for GNOME. Our APIs are a constantly shifting target, and application distribution is slow and fragmented. It is also very difficult for application authors to maintain their brands or to generate revenue streams from their work.

We want to change all of this. During the GNOME OS BoF we discussed how we can make it easier for application developers to create software for GNOME, and how we can make guarantees about API stability for application developers. We also talked about how we can safeguard users from rogue applications.

GNOME contributors will be creating a proposal for a new model for application development and installation in the coming months. During the GNOME OS BoF we spoke about how we want to make this framework available to existing GNOME distributions if they want to use it. The benefits for distributions: sandboxed applications that will be compatible for years instead of months, less packaging work, and maybe, just maybe, lots more apps.

How you can help: once we’ve worked out a proposal for the new application framework, we’ll be looking for your feedback, particularly if you are a distribution or an application author.

SDK

This area directly relates to the last (you can’t have an SDK until you know what your application framework will look like), and some parts of it will have to wait until we’ve worked out the details of our plan for applications. Nevertheless, an application development SDK remains firmly in our sights as a part of GNOME OS. We’ve set a target for a new version of the GNOME HIG, and we are developing plans for the other GNOME development tools.

How you can help: there are already plans to modernise GNOME’s development tools; if you work on these components, or would like to, get in touch with the design team to see what needs doing.

Testable

The way that GNOME is currently built and tested has major limitations. Our automatic build systems are rudimentary and they don’t allow us to do automated testing. It is extremely difficult for contributors to build and manually test the current GNOME development code, or to create a development environment. We constantly hear how they burn time and energy trying to simply get the latest code to run (this problem is especially acute for new contributors).

The existing GNOME build system also has major problems when it comes to lower levels of the stack. It often breaks down when new versions of dependencies are required to run the latest GNOME development code. It also gives us little – if any – opportunity to test our code against the stack with which it will be deployed.

We are setting out to correct this situation as a part of GNOME OS. Work is already underway to create a new build system for GNOME. This will enable us to have automated builds and testing. It will allow us to do continuous integration across the stack as we develop GNOME, ensuring that we spot bugs as they happen, not weeks or months after they were introduced. It will also enable us to generate downloadable development images that can be used for testing.

During the GNOME OS BoF we set some goals for Testable GNOME. In six months’ time, we want to have a build bot that is actively used. One year down the line, we want to have an installable image that contributors can use for testing and as a development environment. Members of the GNOME Release Team have agreed to push this process forward. We will also be making moves to acquire a new server that can be used for the automatic build service.

Existing distributions will directly benefit from these enhanced testing activities. It will mean that the GNOME software they distribute will be higher quality, better tested and more efficiently produced.

How you can help: join #testable on irc.gnome.org, try out OSTree, check the build logs and help to fix build errors.

Core UX

GNOME 3 is an ongoing project. In addition to constantly refining the core UX, we are also in the process of creating a new suite of GNOME applications, which we plan to grow into a new model for accessing content, whether it is stored locally or online. We have already made good progress along this road, but there are still some missing pieces. We need a target for when those missing pieces will be in place.

During the discussions that took place at GUADEC, we talked about which parts of the core UX need to be prioritised in order to deliver a complete GNOME 3 user experience. We set the goal of having all of these components incorporated into GNOME within the next 18 months.

How you can help: get involved in the development of Documents or Photos, or work on one of the other applications that we have planned, like Music or Transfers. People are already stepping up to help in this area, but we will need more contributors if we are to make it happen.

New types of devices

The increasing popularity of mobile and touch devices represents a challenge to existing desktop solutions. This situation is complicated by the emergence of new hybrid devices that combine keyboards, touchpads and touchscreens. During our discussions last week we talked about how existing types of devices – primarily laptops and desktops – have to remain the primary focus for GNOME. These are what the members of our community use every day, and they are the primary market for existing GNOME-based distributions.

At the same time, we also want to ensure that GNOME remains compatible with new hardware. Some work has already been done in this area, but we set out to make it a bigger focus for GNOME. We are already working on a new effort to track and address issues related to GNOME on touch devices, and we are going to try to obtain hardware that can be used for development and testing purposes.

We have set the goal of having a touch-compatible GNOME 3 within a maximum of 18 months.

How you can help: help to fix the bugs on the touchscreen wiki page. Test GNOME on a touchscreen device in order to help us identify compatibility issues.

Wrap up

What is an OS? To some people it is simply a kernel. But I agree with Jon: it is something else. In fact, an OS is two things: it is a user experience, and it is an application developer experience. Neither of these can be thought about in isolation: you cannot define APIs without first knowing the user experience that they are supposed to provide. The user experience and the application developer experience are two halves of a whole.

That is why we are calling this effort GNOME OS. We are in the process of defining a new user experience. We need to set targets for that experience, and we need new systems to ensure that it is high quality. At the same time, we can use that UX as the basis for a new application developer experience.

Each of the areas that we are focusing on for GNOME OS – a new framework for applications, an SDK, better testing, a well-defined core UX and enhanced hardware compatibility – tie together. You can’t define applications without first defining a core UX. You can’t talk about an SDK until you’ve defined your application framework. We have to target a range of areas if we want a coherent plan.

Sure, these goals are ambitious, and maybe they won’t happen. The targets that we have set for GNOME OS aren’t as unrealistic as you might think though. People within our community are already working in these areas. OSTree is already happening. The technologies that can be used for a new application framework already exist. There is already a draft version of the new HIG. People are already stepping up to help us complete our plans for the GNOME 3 user experience.

The GNOME community contains a huge amount of talent and expertise. Many of us have been around for a while; we know the history and have learnt from it, and there are many of us who think that we can improve on the current status quo. If we keep our focus, and if we receive your help, we can do it.