First, I want to take a moment to highlight just how wild the last week has been. Bevy was only released a week ago and we've already hit some pretty major milestones:
I didn't in my wildest dreams anticipate a community to show up so quickly and in such force. Clearly the Bevy project resonates with people! This is wonderful, but it also presents some interesting challenges that I thought I would have a lot more time to solve:
Before we try to solve these problems, I think we need to ask ourselves:
I think this is actually a relatively straightforward answer. I think it boils down to:
How can we replicate this process at the new scale of the Bevy community? And how can I personally replicate this now that my job title has changed from "solo incognito moonshot project architect" to "lead architect" / "project manager" / "community manager" of a project with a developer community numbering in the thousands?
I don't think now is the time to get bogged down in complex organizational structures or RFC processes. Eventually we will need those tools, but I don't think we're there yet. Instead I'm going to try to re-create the conditions I've been operating under for the last five months:
I plan on being a Benevolent Dictator For As Long As I Can Manage It. I will personally review every PR that gets merged and every design decision made. Eventually (if we do this right) that will become impossible, but we aren’t there yet. As I build trust in contributors and the project expands I will eventually start delegating. But I will always bias toward “small and focused”. My general skill-set and preference is to be a full time software developer / architect, but I have accepted that I need to balance that with being a project and community manager. My short term goal will be to drive down our massive Issue and PR backlog :)
We have a long road ahead of us. Building an engine is a lot like leveling up a skill tree in a game. Some features can't (or shouldn't) be built until we have built their predecessors. An example of this is the Bevy Editor. Before we break ground on the editor, we need to make sure Bevy UI and Bevy Scenes are in a good spot. I am just one person. I have limited bandwidth to build designs and review proposals, so I can't afford to waste energy on the editor yet.
At a given point in time, Bevy will have 3 focus areas. These areas will receive priority for my time, and I will try my best to direct contributors to those areas. This doesn't mean others aren't free to explore other areas they are interested in. Just don't expect to get them merged quickly. Ideally you're building a standalone plugin that doesn't require being directly merged into the Bevy repo anyway.
I don't want to get stuck in "design hell". We can debate the best way to build a PBR renderer for years. But without implementations and hard data, it is very hard to determine what is actually best in practice. I want to see code. Production-readiness is a non-feature. A good idea is nice, but if there is no implementation it isn't real to me. We need capable people to take good ideas and make them real. The faster we can try different approaches, the better. For now the general process will be:
bevy_prototype_XXXformat for crate names to respect the
bevy_XXXnamespace. This approach will allow us to "scale out" without too much process or centralization.
Bevy has caught the attention of many popular Rust projects. We are currently discussing the best way to collaborate with Amethyst Engine. I'm also talking to a number of other Rust project leads about the best way to make Bevy a good ecosystem player. As much as possible we should be building up common foundations. Please reach out to me (Twitter DMs or on Discord) if you know of potential collaboration areas.
Here are Bevy's current focus areas. I will direct my attention and attempt to direct everyone elses' attention to them. There are no deadlines. We will take as long as we need to get them right. I will work as hard as I can (full-time) to ensure we make quick progress on them:
Before we can start work on the Bevy Editor, we need a solid UI implementation. Bevy UI already has nice "flexbox" layout, and we already have a first stab at buttons and interaction events. But Bevy UI still needs a lot more experimentation if we're going to find the "right" patterns and paradigms. Editor-Ready UI has the following requirements:
Suggesting other UI frameworks or stacks is out of scope. The Bevy Editor will be built on top of Bevy UI. See the Introducing Bevy blog post for my rationale.
PBR is a standard-ish way of rendering realistically in 3D. There is both a lot of interest and a lot of brain-power in this area, so it makes sense to build PBR now. This focus area has the following (minimum) requirements:
Bevy Scenes currently do most of what we want, but they need a bit more work before they can be the foundation of Bevy state management. This focus area is also a requirement for the Bevy Editor.
If you want to hop on this wild ride with us, here are a few ways you can help:
I'm looking forward to seeing you in the Bevy Community!