PDA

View Full Version : Are the devs open to external programmers contributing to feature development



ronnke
February 7th, 2012, 19:02
Would the devs be open to external programmers contributing to the feature development of the core Fantasy Grounds software? Like a restricted open source. Obviously, the appropriate NDA's and contracts would be signed and all rights would remain with SmiteWorks.

I'm pretty sure there are several programmers in our community that would love to offer their time to feature development. There is a big todo/wishlist and more coders would certainly help get those features out the door.

Moon Wizard
February 7th, 2012, 22:06
We are definitely open to development, but we typically ask that developers work with us on the ruleset code and utilities, which are easy to manage separately and integrate.

Please drop me an email at [email protected] to talk further.

Regards,
JPG

phantomwhale
February 8th, 2012, 01:36
My personal view, supported in part by other key user/developers of FGII, is that a move towards the community maintaining / improving / enhancing an open-source base ruleset would lift the pressure from Smiteworks to produce these improvements themselves, and concentrate more on enriching the core FGII engine API.

The current effort which best takes us towards that model is probably the foundations-core ruleset, which captures all the great core ruleset work that moon_wizard has done, adds some of Joshua's changes and strips it down to be RPG system agnostic.

If this can get more love, in terms of core development, as well as extensions / forks that build upon it to produce fully functional system-specific rulesets, I think we'll be well on our way.

Lots more info, discussion, and the all important GitHub details over here : https://www.fantasygrounds.com/forums/showthread.php?t=15866

Moon Wizard
February 8th, 2012, 06:52
Since I've actually been developing on FG long enough to remember the previous Foundation ruleset, I have concerns about handing over the ruleset development reins.

The original developers came to depend on the previous foundation ruleset. Then, when the community devs on the foundation got pulled away to other things, the ruleset that FG depended on was left hanging. The original developers were not very familiar with the previous foundation ruleset, and had no ownership for addinf more commercial rulesets.

Also, I found that the previous foundation ruleset lacked a general sense of direction once Joshuha had to step away for other life concerns. A ruleset really needs a "product manager" to make sure that it has a vision and direction, plus they can sift through all the requests to find the ones that help the most people.

I have a feeling that we will end up sharing code between the release and foundation rulesets, and I welcome the interaction. However, the primary difference is that the SmiteWorks code in the rulesets that are provided today are not open licensed. The code and graphics remain the property of SmiteWorks. It's one of the protections we have in place to keep the company going. I deliberately built the most recent 3.5E (previous d20_JPG) and 4E rulesets from the old d20 ruleset before the original ruleset moved to an open license (which was the first foundation ruleset).

If anyone wants to contribute to the existing rulesets, I am more than happy to integrate any additions and/or extensions. However, we need permission from the developers to include, since the code will become SmiteWorks code at that point. For example, DrZ has allowed me to integrate any of his 4E extensions. It actually ends up saving him work, since he no longer needs to maintain them.

If anyone is interested in working directly with me on any specific projects, please send me a private message or email.

Sometimes, it's enough just to talk to people building the ruleset code, so that I can improve the underlying engine for everyone. The feature creep on v2.9 has a direct relation to that, since I had to add a fair bit of API functionality to add the improvements I wanted for the next version. It's one of the reasons that I try to stay active on the forums.

Cheers,
JPG

Valarian
February 8th, 2012, 08:57
The original developers came to depend on the previous foundation ruleset. Then, when the community devs on the foundation got pulled away to other things, the ruleset that FG depended on was left hanging. The original developers were not very familiar with the previous foundation ruleset, and had no ownership for addinf more commercial rulesets.

Also, I found that the previous foundation ruleset lacked a general sense of direction once Joshuha had to step away for other life concerns. A ruleset really needs a "product manager" to make sure that it has a vision and direction, plus they can sift through all the requests to find the ones that help the most people.
I disagree with this assessment of the previous foundation ruleset. The previous ruleset was launched and maintained by Smiteworks (previous owners), with the stated intent that it would be a base for ruleset development. The problem was that it was never supported by the original developers and had issues, especially around the combat tracker. It was the community devs that kept that ruleset going, far beyond when the original devs had abandoned it.

Link to original announcement:
https://www.fantasygrounds.com/forums/showthread.php?t=9000

This ruleset was then replaced by Foen's Base ruleset, which provided more functionality and worked. This has, in turn, been replaced by Joshuha's new Foundation Core.

I strongly believe that ruleset development needs to have a strong Core ruleset, that is fully supported by Smiteworks as a base for ruleset development. This, then, gives ruleset developers a strong starting point for extending and branching for other rulesets. It will speed development, and make maintaining functionality improvements across rulesets a lot easier with a single, common, core ruleset.

joshuha
February 8th, 2012, 16:08
Right the idea of a common community maintained ruleset is to try and lessen pressure on people trying to patch up older rulesets with newer features. If we can successfully divorce what should be CORE FG features from game specific features it makes that much easier. How much time has been spent re-writing Savage Worlds to support newer features, how much demand do I see to add in this or that feature that is in 4E to other rulesets that people bought but are now feeling a little "antiquated"? Like many here, FG is a hobby for me so I won't always be around 100% but moving to Github I have started adding in multiple people that have permission to do merges so I think we are moving in a direction that even if one of us is on extended leave the work can continue.

The question then becomes is if people are willing to write commercial rulesets based off of Foundations Core to maintain that reusablity. Even if not an extension to Foundations Core, if the files are separated well enough you could still design commercial rulesets that would be easy enough to update once bug fixes/new features were added into Foundations Core. I currently have a commercial project I am working on, it has been slow going but it is still being worked on in bits and pieces and hope to have something more to announce in a few weeks.

Moon Wizard
February 8th, 2012, 20:47
Valarian,

Fair points. I was writing about my perception of what happened in the previous post, and did not research the history. By the time I joined, it was more work to save than to move forward with what I had built on my own.

Joshuha,

I agree that it would be better to have rulesets that could "reuse" components easier to allow a set of "common" components to be shared and updated across multiple rulesets.

Given that, I was thinking that it might be a good idea to make a break with v3.0 to change up how rulesets are built. In the last few updates and the upcoming release, I have been working on modularizing the existing D&D rulesets to allow easier portability of features, as well as adding common components and common features into the client directly. The biggest challenge in this approach (and any approach) is that the layout (graphics and text) of every ruleset needs to be highly customizable to support what developers want to do. This makes developing common components much more labor intensive than developing components for a specific ruleset or single person managed rulesets.

Given a blank slate, how would you propose to have the ability to allow rulesets to use common components. These are just ideas that have been bouncing around in my head, and are not necessarily mutually exclusive.

* Continue current process of slowly modularizing ruleset code and integrating common features into client? (low design time, driven by ruleset updates)
* Add another layer for ruleset code (FG common components/graphics, then ruleset, then extensions)? Maybe the common layer is the "foundation"? (requires extensive development and design time)
* Add template/class merging feature for easier extension creation
* Other ideas?

Of course, my primary goal for v3 is going to be map improvements. However, I've realized more and more the need for better ruleset and module management to allow easier community development.

Regards,
JPG

Sigurd
February 9th, 2012, 00:28
Doesn't the openness of the XML make some of this argument silly?

I think if Smiteworks makes the best damn rulesets they can, clearly and with good documentation other developers should be able to run with that. Right now there is no other platform for these modifications so contributing them back make sense.

As long as Smiteworks is ok with this sort of development model would an 'open source' ruleset achieve anything different?

You can always have better documentation, a better library, or cleaner code but I think the community maintaining a ruleset for the sake of it being open source is serious duplication.

What advantages did the old foundation code give Joshua or Foen?

unerwünscht
February 9th, 2012, 03:08
I think it has less to do with what it can do for the people maintaining the open source ruleset and more to do with what it can do for Smite Works, and 3rd part ruleset devs.

The first thing that opens up is that moon can spend less time working on rulesets and more time working on the base program itself and adding new features to the application.

While at the same time 3rd party developers would no longer need to waist time with punching out code that already exists, or stripping code out of another ruleset to get it down to a usable starting point.

Need to make a ruleset? Awesome here is the community core, now make a character sheet, add in some automation, design your skin and you are good to go. :)

joshuha
February 9th, 2012, 15:17
Doesn't the openness of the XML make some of this argument silly?

I think if Smiteworks makes the best damn rulesets they can, clearly and with good documentation other developers should be able to run with that. Right now there is no other platform for these modifications so contributing them back make sense.

As long as Smiteworks is ok with this sort of development model would an 'open source' ruleset achieve anything different?

You can always have better documentation, a better library, or cleaner code but I think the community maintaining a ruleset for the sake of it being open source is serious duplication.

What advantages did the old foundation code give Joshua or Foen?

The old and new gave the advantage of quickly creating new rulesets without having to hack out the bits from an old one that you didn't need. Being able to write extensions that extend a base ruleset is much easier than hacking away functions, image references, character sheets, etc. from a ruleset but still trying to figure out the things you want to keep (and sometimes its all intertwined). And then when Smiteworks added features/bug fixes JUST into the 4E ruleset having to repeat that work to extract just the needed improvements is a chore.

Moon Wizard
February 9th, 2012, 19:09
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
February 9th, 2012, 22:57
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
February 9th, 2012, 23:31
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
February 10th, 2012, 11:20
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 :D 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
February 10th, 2012, 13:11
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
February 11th, 2012, 17:46
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
February 11th, 2012, 20:32
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
February 11th, 2012, 20:40
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
February 11th, 2012, 21:26
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
February 21st, 2012, 15:41
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.

Moon Wizard
February 23rd, 2012, 19:08
I agree about the extensibility being limited, and requiring a lot of cut and paste.

If I end up doing a layered ruleset approach, I think it would make sense to enhance the classes to allow a merge model like controls use. It would greatly simplify situations where classes are very similar, and improve extensibility.

Plus, I think it would make extensions less fragile, since they are only replacing one bit, instead of redefining classes.

Cheers,
JPG

darrenan
August 26th, 2015, 20:01
Was any thought ever given to moving the rulesets into github or some other open source management repository? Seems like that would be an ideal way to leverage the community without relinquishing control.

lordjeb
August 26th, 2015, 21:51
I would also love to see some of the proprietary content (e.g., modules from WotC) moved into a private github with fairly limited access. I would love to be able to fix a problem in a module and just submit a pull request to the owner. I do understand why WotC and SW don't want the modules potentially getting out there unprotected, so this group would probably have to have some tight controls and legal restrictions, but it could be awesome.

darrenan
August 26th, 2015, 22:33
I was mainly thinking of the rulesets that are bundled with FG itself (CoreRPG, 3.5/PF, SW, etc.).

For wholly community-generated rulesets, it would be up to their author(s) whether they would be open to moving to this model.

I would imagine the 5E content is under much tighter restrictions, since it is licensed by WotC and not open IP. Moving that to Open Source is probably a non-starter.

Nickademus
August 27th, 2015, 07:13
To my knowledge, the 5e ruleset is not part of the WotC license and open to the community for modification (extensions). The data modules that hold WotC copyright content are locked.

phantomwhale
August 30th, 2015, 13:34
I would also love to see some of the proprietary content (e.g., modules from WotC) moved into a private github with fairly limited access. I would love to be able to fix a problem in a module and just submit a pull request to the owner. I do understand why WotC and SW don't want the modules potentially getting out there unprotected, so this group would probably have to have some tight controls and legal restrictions, but it could be awesome.

I do host all my code (Savage Worlds and associated addons) in BitBucket (free, private hosting) and currently allow one other developer full access, as he has been more prolific than I've had the capacity to be, so it's easier to take pull requests from him and get all the review tools provided.

That said, any developer could submit change requests as .patch files for easy merging (which was what Linus developed Git to do in the first place !) without needing actual access to the Git repository. Heck, I'll even accept people just sending whole files over and I'll merge / figure out the changes myself (although patch files would be better if you know how to generate them with Git).