So I got a note (several really, and maybe others did too) from Porto, Portugal, where some students are doing a project seemingly analyzing open source projects for development methodology and such. Terasology has come up with some questions asked 
It is good timing as well as I've been wanting to go over the topic again and try to help us get more focused as a team. So maybe we can take this opportunity to not just mention what we're currently doing, but what we could be doing, and what probably isn't suitable for us but may still be very useful for others.
The main challenge
We're an open source, all-volunteer, non-profit project. We repeatedly have been near the sort of "critical mass" needed to have enough activity to attract more contributors to create more activity to attract more contributors and so on, but haven't quite gotten past it permanently yet. Most our long-term contributors have day jobs keeping us busy, sometimes too busy for long periods of time.
This makes following traditional processes from a work setting difficult. Methodologies like Waterfall, XP, Scrum, and any kind of structured planning with objectives, deadlines, and so on is nearly impossible to apply. In agile terms the "focus factor" for us as an overall team is exceedingly low, probably in the single digits (0-9%). We simply never know who will be available, when, for how long.
In a work setting where you're employed x hours a week that is vastly easier to deal with. You also get paid to do the work, which tends to help
Some larger open source projects (or those that are actually commercial ventures with open source components) can manage to organize better as they're far past the "critical mass" point (often by having paid staff involved or a direct monetary incentive). There is enough momentum and time availability to better predict schedules. In other words their "focus factor" is higher.
Questions
Will try to answer the questions to the best of my ability anyway, mixing in some experience from work and some future potential where able. I also wrote a related thread with some ideas quite a while back.
One particular important topic is versioning. We try to use Semantic Versioning, which makes dealing with many small interconnected parts easier, as you should be able to tell the scope of a changed library based on its version number (and automatically pick up some minor change, but not major ones, without changing your dependency configuration). One idea that has come up recently is pushing our engine to v1.0.0 to declare it sufficiently ready for "production" usage, yet still keep the overall game in Alpha (upgraded from pre-alpha). Then stick to the "contract" of having the engine remain fully compatible in the future until such a date we do a new major release (v2.0.0). That in theory should make it easier for modders to create and maintain stable content.
More student / course stuff
Finally, for the students, what other questions may we be able to help with? I got a PDF with a course outline but am still not entirely sure. For instance aspect-oriented programming is on there which is oddly specific if it is about overall project organizing.
We don't use AOP directly although in a sense our entity system is similar. AOP uses cross-cutting aspects (common code) applied dynamically to specific parts of a project in need of it. The Spring Framework for Java webapps is a great example heavily using AOP, and I recently started using jcabi-aspects in my main Spring webapp for my day job to add some nice utility.
Our entity system applies components (data containers) to entities giving them functionality via common code in systems. So a creature would have a model component giving it shape, a health component giving it life, and so on. During game execution the main loop goes through all the systems and each runs the logic on entities with relevant components (so entities with a model get rendered)
Fun fact: AOP as a programming paradigm is patented. I had no idea you could even patent something like that. It made me worry for a bit applying more of it to my main work app - until I learned that the company I work for, Xerox, is actually who patented it, heh. Not like it seems we're doing anything with said patent. Xerox is terrible at monetizing stuff, seemingly just like Sun Microsystem was.
Anybody else feel free to chime in, ask more questions, comment on the above, propose other suggestions and so on. If anybody actually manages to read this whole thing. I swear I was just trying to write something real quick!
I thought I'd get a forum thread up for discussion also as maybe more than one group ended up picking Terasology. On top of that this is a topic dear to my heart that has come up from time to time and others might have some valuable input as well.
It is good timing as well as I've been wanting to go over the topic again and try to help us get more focused as a team. So maybe we can take this opportunity to not just mention what we're currently doing, but what we could be doing, and what probably isn't suitable for us but may still be very useful for others.
The main challenge
We're an open source, all-volunteer, non-profit project. We repeatedly have been near the sort of "critical mass" needed to have enough activity to attract more contributors to create more activity to attract more contributors and so on, but haven't quite gotten past it permanently yet. Most our long-term contributors have day jobs keeping us busy, sometimes too busy for long periods of time.
This makes following traditional processes from a work setting difficult. Methodologies like Waterfall, XP, Scrum, and any kind of structured planning with objectives, deadlines, and so on is nearly impossible to apply. In agile terms the "focus factor" for us as an overall team is exceedingly low, probably in the single digits (0-9%). We simply never know who will be available, when, for how long.
In a work setting where you're employed x hours a week that is vastly easier to deal with. You also get paid to do the work, which tends to help
Some larger open source projects (or those that are actually commercial ventures with open source components) can manage to organize better as they're far past the "critical mass" point (often by having paid staff involved or a direct monetary incentive). There is enough momentum and time availability to better predict schedules. In other words their "focus factor" is higher.
Questions
Will try to answer the questions to the best of my ability anyway, mixing in some experience from work and some future potential where able. I also wrote a related thread with some ideas quite a while back.
- Development process: Nothing formal. This is the challenge listed above. Pretty much we maintain our issue tracker for identified issues / needed improvements, the suggestion forum for ideas, and several more dev forums here to shepherd suggestions through implementation into maintenance. Usually this happens whenever a new contributor shows up and wants to do something. The ideal setup would go something like:
- Somebody makes a suggestion in that forum. Great idea!
- Somebody takes it on for initial design and writes up more technical notes and details on how to implement it
- Somebody starts coding it - might be the same person and often this is the point where the process actually starts (skipping the suggestion phase because a person showed up excited to do something specific)
- We move the concept into the module forum if it fits into a module (most content does), into the art forum if it is to make assets for the game instead of code, or the Core Projects forum if it is for architecture supporting the game engine itself or other library-level functionality (not content)
- The new feature becomes sufficiently complete to be put to use. Modules all live in their own repos on GitHub so authors often push directly without pull requests (PRs). Engine features hit the PR stage, get reviewed, and merged
- We release the new feature in the next game release.
- As for the why to our process: well, it gives what little structure to the process we can apply without getting in the way of people wanting to do work As noted often it gets short-cut when somebody is excited about a feature and shows up with it out of nowhere. Often the first time we as a community learn about a nifty new feature or piece of content is when an author announces it or sends us a PR. Hard to get very structured that way. Naturally this makes planning and estimating anything extremely difficult.
- The team/teams are entirely self-managed by individuals. Everybody sets their own pace that fits how busy they are in RL. This is a huge disadvantage vs being able to treat something as a full-time job. I'm project lead by title but really do nothing but encourage and sometimes badger people to get stuff done. I step in where I can when I have time to do stuff that needs to be done that nobody else is getting to. Being super busy I unfortunately fall short in this constantly.
- I aim to get a release out every 2-4 weeks, but this is highly erratic and depends almost entirely on who gets what done. Is there enough stuff to really do a new game release? Our game releases come with a large list of modules considered "stable" and included with the base game, but are all maintained by different people so it can sometimes be months between updates there.
- No deadlines or formal milestones. We sometimes try to do a discussion on what's most needed at some given time, and with a bit of luck some bits of what we need gets done over the next few months. For instance a few times we've tried to come up with a todo list for hitting Alpha-level readiness. Beyond Terasology's primary game component we've used GitHub milestones with some success for our Launcher and new project Destination Sol, both of which are much smaller projects on their own, making them a bit easier to handle.
- As for bugs anybody can report them on GitHub. Occasionally I'll try to badger somebody specific to see if they can check out and maybe fix a bug, but usually issues just sit there until somebody spots something they want to work on. Both external people new to the project (mainly players) report bugs as well as existing community members while developing and testing content.
- Ideally pull requests get reviewed by at least one person other than the author who is familiar with the area impacted. That person grabs the code and tests it locally to make sure it works and does what is advertised. Then either reports back on the PR or merges it. Often PRs are done for code where the author is the only person really working in that area in which case I'll either try to personally test or merge it or find somebody else more familiar than me who can check it out.
One particular important topic is versioning. We try to use Semantic Versioning, which makes dealing with many small interconnected parts easier, as you should be able to tell the scope of a changed library based on its version number (and automatically pick up some minor change, but not major ones, without changing your dependency configuration). One idea that has come up recently is pushing our engine to v1.0.0 to declare it sufficiently ready for "production" usage, yet still keep the overall game in Alpha (upgraded from pre-alpha). Then stick to the "contract" of having the engine remain fully compatible in the future until such a date we do a new major release (v2.0.0). That in theory should make it easier for modders to create and maintain stable content.
More student / course stuff
Finally, for the students, what other questions may we be able to help with? I got a PDF with a course outline but am still not entirely sure. For instance aspect-oriented programming is on there which is oddly specific if it is about overall project organizing.
We don't use AOP directly although in a sense our entity system is similar. AOP uses cross-cutting aspects (common code) applied dynamically to specific parts of a project in need of it. The Spring Framework for Java webapps is a great example heavily using AOP, and I recently started using jcabi-aspects in my main Spring webapp for my day job to add some nice utility.
Our entity system applies components (data containers) to entities giving them functionality via common code in systems. So a creature would have a model component giving it shape, a health component giving it life, and so on. During game execution the main loop goes through all the systems and each runs the logic on entities with relevant components (so entities with a model get rendered)
Fun fact: AOP as a programming paradigm is patented. I had no idea you could even patent something like that. It made me worry for a bit applying more of it to my main work app - until I learned that the company I work for, Xerox, is actually who patented it, heh. Not like it seems we're doing anything with said patent. Xerox is terrible at monetizing stuff, seemingly just like Sun Microsystem was.
Anybody else feel free to chime in, ask more questions, comment on the above, propose other suggestions and so on. If anybody actually manages to read this whole thing. I swear I was just trying to write something real quick!
Last edited:
