I’ve created several open-source projects over the years. One unexpectedly did particularly well, reaching more than 230,000 downloads, but from my perspective they all succeeded because each solved a real problem or scratched an itch I had.
As soon as you make your app, package or tool open source, you have to ask yourself: “When is it ready for other users?”
There are two answers. The first is simple: it is ready the moment you make the repository public. The second is more nuanced: it is ready when you consider the project worthwhile enough for other people to spend their own time exploring it.
The second one is complicated. It depends on the project itself, the expected lifetime of the project, its scale and the intended audience. You might not know all the answers when you click the Make public button, but you should still communicate your current expectations to potential users.
Ready when?
Once I thought I had done enough to prove the initial concept, I added a small section to the Prune README. The “Ready for users when…” section described the minimum user journey that I believed would make my 2D game engine ready for other people. At the time, I was still several prototype releases away from completing it.
-> Open app.
-> Pick a scene type.
-> Select object in viewport.
-> Move with handle.
-> Resize with scale tool.
-> Duplicate it.
-> Delete it.
-> Undo/redo all of that.
-> Save.
-> Load.
-> Behaviour still works.
-> Runtime objects do not get accidentally edited or saved.
-> Basic audio hooks.
At the time, I considered the list reasonable. I was still riding the initial high of having proved, both to myself and to my children, that Prune was worth pursuing. It was not long before only one item remained unchecked..
While adding the dirty-state indicator for the scene I realised I needed to do much more to make Prune useable.
OK, that sounds cryptic. What happened?
I was adding a Boolean flag to the command system to record whether an action changed the saved scene state. Scaling an object makes the scene data dirty but moving the camera should not. Prune could then use that state to determine whether to display an asterisk next to the filename.
Then it hit me. The feature was necessary, and implementing it now would be easier than retrofitting it later, but when I stepped back and looked at the editor, the larger problem was obvious. Users could only add defined objects, the game slices are thin and assets have to be defined in the code. I was building a 2D game editor, however to use it you need to be a C++ developer.
The original checklist proved that the editor’s core workflow existed. It did not prove that someone unfamiliar with the codebase could use Prune to create anything meaningful.
A revised definition of ready
I spent the next hour replacing the original checklist with a broader definition of readiness.
When the new list is complete you will still need to be an enthusiast to use Prune but you will be able to do so much more than now and more importantly there will be a reason to use it more than once. I want users to play with the editor and create their own games, not just explore the included examples.
Core editor/runtime
This section proves Prune’s core architectural premise: that a shared editor shell can support scene-specific behaviour layered on top. The editor needs to feel consistent, and the different scene types need to justify their existence.
Editor workflow
This section focuses on improving the feel and reliability of the editor. Does Prune have reliable state management, can you Ctrl-S to save, does it communicate unsaved changes do all the tools behave consistently and respect scene settings like grid snap.
Scene editing
This is the meat of the work. This section details the systems to allow asset management, behaviour management, effects management and all the tools which mean the user does not have to modift the C++ unless they choose to.
Proof Prune works and is usable
This is the polish and the evidence. It is where I demonstrate what Prune can produce. I need to bring the existing game slices to an appropriate level of fidelity and add enough documentation for a new user to get started.
Will it keep getting bigger?
No, I don’t think it will.
The checklist does not contain everything I eventually want Prune to support. the NOTES file in the repo has a much more comprehensive list of features. The checklist contains only what I believe is necessary before I can reasonably recommend that another developer spend time using it.
I may rearrange a few items, add something here or remove something there, but the overall scope should remain stable. Once the checklist is complete, I will consider Prune ready for other developers to spend time exploring.
Ready does not mean finished. It means the project has crossed the line from being useful primarily to its creator to being worth someone else’s time.
