Are the devs open to external programmers contributing to feature development

[Moon Wizard]

Don't get me wrong, I definitely see advantages to doing a foundation ruleset. All of the things that you guys mentioned are good reasons. However, it is always a challenge straddling commercial and open source development in a way that makes sense for a business.

Off the top of my head, here are some of the concerns that I have. Perhaps you guys can work with me to figure out how to address.

1. Making all ruleset code "open source" creates a situation where people can potentially create and sell rulesets outside of FG store. I'm not sure this is a huge concern at the moment, but once the cat's out of the bag, you're stuck with the results regardless of what happens in the future. As you have seen from the annual reports, FG is not such a money maker that we can afford to lose control of the store. How can we address?

2. One option to address "open source" concern above is to change the FG EULA concerning usage of only official commercial rulesets to add the protection. This actually is a better protection than the current closed source anyway. Does anybody see an issue with this?

3. When a project has many contributors, we still need to have one person in charge of determining "releases" for quality control. I would then be able to pump these releases into the client version release schedule. I'm assuming that would fall to SmiteWorks, since community members could come and go. I need to look into GitHub more, but I assume that we can "branch" the code as needed to create stable versions for releases and patching, while development continues on main branch.

4. With many contributors of varying experience, there could potentially be quality issues. How can we address?

5. Again, with many contributors in an "open source" environment, you can easily run into the problem of "too many cooks in the kitchen". How do we keep changes within the foundation ruleset part of a central, extensible and game-system independent vision? Maybe a short summary of "guidelines" on GitHub relating to style and applicability would be useful and a good start?

6. The FG software as it stands now is not as conducive to a foundation ruleset as I would like. Right now, the foundation would be more of a base set of files to start from, but each ruleset would be a snapshot of those files. Any ideas?

7. A couple ideas I've thought about regarding the integration of common components to address the item above:
* Add another "layer" beyond "ruleset" and "extension", or multiple "ruleset" layers (i.e. include another ruleset). Needs some design thought and discussion.
* Build-in common features/components directly into client. Ongoing effort.


I'm sure I will have more questions as we drill in, and I want to talk with Doug a bit about this as well to get his thoughts. As I originally stated, I am open to the idea, but I have concerns I need to address first.

Thanks,
JPG

[Valarian]

2. One option to address "open source" concern above is to change the FG EULA concerning usage of only official commercial rulesets to add the protection. This actually is a better protection than the current closed source anyway. Does anybody see an issue with this?

If this is suggesting what I think it is then, yes! I read this as you would be in breach of the EULA if you used an unofficial or non-commercial FG2 ruleset. That's the majority of my games. I've not run a game on a commercial ruleset for about 18 months, then only as a one-shot. I run Summerland, FATE (Dresden Files, Starblazer, legends of Anglerre), and more recently The One Ring. All of these are on rulesets I've knocked up and some no more than the character sheet. They would not be commercial quality, and some would not get the backing of the publisher for licensing restriction reasons. It basically kills the idea of the community ruleset. If this becomes a breach of the EULA, I'd have to stop using the product and this is the best VTT out there, in my opinion, so I wouldn't want to do that.

[Moon Wizard]

I'm not saying that we would prevent people from using unofficial, community products (i.e. free). We just need something to push people who want to "sell" their rulesets, modules, etc. to come to us for distribution through the FG store. Unlike Apple, we don't have a walled garden to protect ourselves.

It was just a thought as a way to protect our investment in the ruleset code that we continue to develop.

Regards,
JPG

[phantomwhale]

My journey so far has taught me the following:

Extensions are brittle : so offering a "Base ruleset" that can simply extended to provide various usable rulesets will require constant work as we go to make the points where the extensions "hook" into the core ruleset as robust as possible.

Sigurd mentions the "openess of XML" making the argument silly; ironically it's the openess of XML and the extension model that makes it vital - it's hard to produce a robust extension that does much more than graphic changes without it breaking on each minor ruleset change. Which is fine (although annoying) when it's the same author, but hardly encourages a larger development community.

Copying and pasting feature over isn't easy : the closer a ruleset is to another, the easier copying over features is. Thankfully SWEX and 4E had a common genesis of the 3.5E ruleset, so updating the SWEX ruleset to have 4E features wasn't impossible. But each time, your essentially trying just to merge in the change you need, without picking up bits you don't need, which involves you needing to really understand the depth.

Anyone in software will tell you merging is HARD. Google it ! So whilst this is the "current" model going forward for keeping rulesets in sync, it's certainly not ideal. And doesn't offer much / anything to help with new rulesets.

Testing is a big effort - 4E has beta cycle testers and the ability to push patches, and SW has Doswelk It takes a while to get this right, and getting it wrong means a new release which is tough without a third-party patch pushing mechanism (which has two issues - the technical work, and the fact that third-party code still needs to go through extra verification by the Smiteworks staff).

An open-source ruleset could, over time, develop stable versions but still allow people to pull the latest "cutting / bleeding edge" version. And allow others to pick up what it a known, and well tested ruleset.

I understand the need for a ruleset to have a good product manager - this is vital, especially without any automated testing around the software. And understand Smiteworks need to keep the commercial rulesets in-house. But for the points above, I don't think merging is the best, or a rewarding way, of keeping rulesets up to date with the latest core ruleset features and well tested. And I suspect pushing core ruleset features into the engine will only get us so far.

So right now, the best vision I have is to push the foundations-core as a platform to build off, get some projects interested as either extensions or forks of the code. And then put in some work to try and make the foundations-core much less brittle for extensions - and that sort of work is going to need to good API design and code work, so will need good peer review.

It's a model that would suit new ruleset developers better than anything else on offer. Currently, it wouldn't suit Smiteworks at all, and I wouldn't expect them to release the next 4E as a foundations-core extension ! I suspect it would have to go quite some way until any better collaboration model between the Smiteworks codebase and third-party open-source code can be formed. So if there is interest from others in developing this, I'll certainly be acting as one keen product manager for the foundations-core ruleset, assist with third-party extensions in the Workshop forum where I can, and hopefully slowly improve the core ruleset too.

[Valarian]

So right now, the best vision I have is to push the foundations-core as a platform to build off, get some projects interested as either extensions or forks of the code. And then put in some work to try and make the foundations-core much less brittle for extensions - and that sort of work is going to need to good API design and code work, so will need good peer review.

Having done one ruleset extension (unfortunately one that can't be distributed, even as a community set) based on Foundation Core, I certainly plan on updating the rulesets I have on the FGWiki that are currently based on the old Foundation or on the Base ruleset. I think that this is an excellent platform for starting off.

[ddavison]

I think a lot of the reusability has to come from the developers implementing them. This is as true for FG development as it is for any business development. I've seen a large amount of ruleset code that is tightly bound to a specific ruleset's xml data structure or UI, when a loosely coupled 3-tier solution would have been possible. This is evidenced by the difficulty of implementing extensions. Some features are so embedded that you end up having to replace entire chunks of code just to make a simple change. When the base code changes for a new ruleset version, this means you have to go in and merge all those changes back in with your extension code.

While a lot of the newer ruleset code is getting better at this, we have the additional challenge of making everything backward compatible with older add-ons. The approach of bringing on new developers to work through that process in exchange for future commissions is working fairly well. To make this easier, I've asked Moon to look at implementing the test and patch tool for commercial rulesets just like we have for 3.5, 4E and the core engine.

Once a product gets licensed for a commercial product, we make all code from any other commercial ruleset available for re-use. Occasionally, we will release specific functions for use in unofficial rulesets as well. Both commercial and unofficial rulesets are important for FG's continued growth. We admittedly want to focus a little more on the commercial rulesets though.

[Moon Wizard]

When Doug refers to the test and patch tool, we are talking about the ability to push third party rulesets in the update utility (release, test, dev modes). Most of the work is already done of this, just waiting for me to finish v2.9 updates.

Cheers,
JPG

[Moon Wizard]

phantomwhale, thanks for your detailed thoughts. I agree with all that you said.

As I mentioned previously, I am actually excited and open to the idea, as long as the correct protections are in place to let FG grow smoothly. (i.e. stable releases, etc.)

Also, I'm really leaning towards building some sort of "layered" rulesets capability for a future version (v3?). It's going to take a bit of planning, since rulesets are so core to FG, and they interact with extensions and modules. Once I get v2.9 a little closer, I think I will start the discussion on the this forum.

Cheers,
JPG

[StuartW]

For my 2c, and I'm far from current on these things, having a rules-agnostic core, from which branches are made when a new ruleset is needed, seems like the best compromise.

While developing the few rulesets I made, I had a non-system Base Ruleset to which regular enhancements were added. When I wanted to create a new palayble ruleset, I'd start from the most recent version of the base and build from there. If new features were added to the Base later, they wouldn't be automatically available in the branched rulesets, but that wasn't really a problem (a ruleset has a 'vintage').

If a common core is used and extended, there is some effort required by the ruleset developer to upgrade to a newer set of functions, but:

• if the earlier version and the later version both herald from the same core code path, it is likely that the upgrade isn't too traumatic; and
• the burden falls on the ruleset author (who often has more interest in delivering the upgrade and hence is prepared to put in the effort), rather than creating some leviathan for Smiteworks.

Just a point of view!

Stuart

[RosenMcStern]

I'm not saying that we would prevent people from using unofficial, community products (i.e. free). We just need something to push people who want to "sell" their rulesets, modules, etc. to come to us for distribution through the FG store. Unlike Apple, we don't have a walled garden to protect ourselves.

I see this as feasible. Basically, it would work like the scenario editors for PC games. You can distribute anything done with them, if it is original contents, but you cannot charge anything for your products unless it becomes "official". It works.

As for the core ruleset, I strongly agree for the need of an open core. Please note that "open" does not mean "anyone can change it", just that "anyone can explore it". If the core keeps the ability to be forked for privately used rulesets, but official evolutions for commercially released products remain in the hands of Smiteworks and selected contributors, I can see no issue on the horizon.

However, I think there are some technical issues with how the whole thing is implemented. I am halfway through the process of doing our first commercial ruleset, and have worked with both the old foundation and the new foundation_core. It is really, really hard to work by extending and not by copy/pasting. Even templating does not always work. The system is designed as customizable, but not always as extensible, and you lack a hooks where your code may be inserted into a standard behaviour, forcing you to copy/paste instead of extending. In some cases, copy/paste is simply unavoidable. This does woudl definitely get in the way of an "intermediate layer of common components" model.