Has the Piston project a too large scope?


Just some words about this because that is a common outside perspective.

The ambitions behind the Piston project are hard challenges which requires an overall planning and architecture. Most people without many years of experience would stick to a single project and might feel the scope of the whole project is too big. That is understandable, but still underestimate the ambitions of the project. Planning, architecture design and maintenance is the easy part!

The hard part is:

  • Provide a work environment where people have creative freedom but enough feedback to drive innovation forward
  • Continuous integration and collaboration across projects
  • Pursue ideas that have long term value, in particular ideas that can not become real otherwise, because people outside the project do often not understand the idea before it brings results
  • Communicate clearly such that the project continue without major obstacles, without intervention or pressure from people not aligned with the goals, without burnouts, at a pace that can sustained over many years
  • Maximize the benefit to humanity over the course of the project and through end results

The only way to achieve this is to let the people who work on Piston to direct the projects, and use analysis as much as possible to work around obstacles. It is easy to see in hindsight that the direction was right, but since the future is much more unpredictable, it will feel like “the project is heading the wrong direction” to outsiders. This is where you should be aware of hindsight bias, because people knowing their stuff are a lot smarter than you think! Besides, there is always some risk of making wrong decisions, but we calculate this into the analysis and make the best guess we can make.

When sailing at sea one sets a course toward the horizon. The goal might be beneath the horizon, and for a person unfamiliar with that ocean it seems like the boat could be heading anywhere. In software, goals are very complex and difficult to explain, and the territory to get there is often unfamiliar. You seek something new, try and fail, and that gives you the experience to spot where the gold is next time. There is not one particular project or technique that has all the gold in it, but all combined that has value. The integration is the treasure of gold!

Programmers have often the idea that simplicity is the goal, but things that look simple turns out to be quite complex under the hood.

See Living with complexity - a talk by Don Norman

A big software project is too large than any single person can fit it inside the mind, so by default, it feels large for everyone. That does not mean something is wrong - it is just the way it is.

The policy we have in Piston is that by default, we trust people who work on stuff. They decide what to do, and this often leads to better results than any single person thought upfront. This kind of working environment is one I like, because I get excited by what will happen next!


You mention a list of hard parts, is there a roadmap or other sort of list of things that try to tackle those problems?

Where is that feedback given? On the project themselves? Who can provide feedback? Who decides of the ‘end goal’ towards which feedback is given?

You mention CI, however it doesn’t seem to be fully used, for example one of the ‘main’ projects currently fails to build on master: https://github.com/PistonDevelopers/piston_window

Automation would allow for a more solid appearance. Rust, Cargo and Semver are very powerful when used together with something like Bors/Homu, any reason why it has not been used yet?


We have a policy that are taken as guidelines, but no strict rules. The environment we try to create is that people working on some project can more or less suit themselves of how they like to work.

Anyone can give feedback by opening up an issue on the individual repo. If there is some feedback of more general nature, one can post it here in the discussion forum.

The people who work on a project decides direction. Each individual project can set up goals and non-goals. When you start contributing, people working on the projects will notice and take your feedback into account. People working on projects knows who are working on it, they learn about how the others are thinking and decide together the direction. Anyone can give feedback across projects, but the people who work most on a project are those with most control over the direction.

There is no formal appointment of roles besides contributing, work on stuff and take responsibility. Anyone that contributes to the Piston project is given write access to all repos, in order to make it easier to contribute across projects, or switch project when you tired and need something else to work on. It happens that people get stuck on a project, then work on something else, and after a while comes back when things falls into place.

CI will be disabled temporarily on some repos because of an upcoming breaking change in Rust. These will be enabled on next Rust stable release.

There is no reason Bors/Homu is not used yet.