[CRAZY IDEA]: Open source the API, free the platform...

It's clear that there are many who value this platform, but as someone who designs software solutions for a living, there are many posts here that show scaling to meet the desires of the market are going to be difficult. So, the real question: what is your real offering? That determines all. Now, take these 2¢ with adoration and insight, please...

If it's a software development group, the work thus far will not scale. You will not be able to meet requests, and your restricted ability to respond will eventually diminish the applicability of your platform. You will wither on the vine. The solution to date is a mixture of technologies, various components, without a clear—at least to me, and I will definitely admit I may just not see it—an architectural vision for growing the platform for the next 5 years. How will you handle scaling, data security, etc. etc.? There are a great many areas that will need to be addressed with something more consistent than a BBS with a storefront running with a Windows client not even on dot net core.

If it's a content engagement platform, now you're talking. The software is not the product. It's the means to distribute the product, to engage the product, to interact with the product. So, the best strategy, in that case, is to learn from some examples and use a community development approach while owning the API. In this approach, you define the API to ensure that you can control the eventual content available on the platform, the means of monetization, communication features, content distribution, and governance, etc. I get it, I really do. Aside from the API though, you should open-source the current Windows client as the lead platform. More importantly, though, *lead* the client effort, but don't try to do it all. Though that approach, other interested parties can contribute additional efforts, creating clients for macos, Windows, Android, and iOS/iPadOS...or even go full multi-platform via Electron or Flutter...expanding the platform's reach and engagement while *concurrently* ensuring that you harness the power of the enthusiastic community. Look at Ethereum as an example on one such community. Then, focus on the solid architectural elements that will be needed to continue the expansion...including plug-in based API extensions, open governance, and new opportunities for engagement (...AR content anyone?).

But...trying to do it all yourself will continue to be a losing proposition. Let us help!

When I heard that D&D Beyond had million(s?) of accounts, I was shocked. D&D 5E has reignited the tabletop industry, and FG has a HUGE competitive advantage. If you retain your current licensing model, but allow other developers help increase the speed of innovation, you could make great strides into growing the FG platform.

It is still possible to contribute to FG without the need to have the source code open. But the interaction will not happen via Git and pull requests the way open-source projects do :)

Quote:

---

Originally Posted by MacDork

When I heard that D&D Beyond had million(s?) of accounts, I was shocked.

---

Yea, those are deceptive and very misleading numbers. I have a DDB account, I logged in exactly twice. Once during the beta and once soon after initial release to see if it had anything that benefited me. I decided it did not have have not been back in, what's it been, over a year? But, they still count me as a user. Just like Roll20 does.

Sure, if the API were open, there is probably some interesting stuff that could be added by the community. But their is already a lot of interesting stuff added by the community without the huge risk of IP theft/loss that granting access to the Unity APIs would introduce.

If their is something really interesting you want to add, develop a proof of concept and approach SW about it and see if they would be willing to do something on a one-off basis.

Quote:

---

Originally Posted by Valyar

It is still possible to contribute to FG without the need to have the source code open. But the interaction will not happen via Git and pull requests the way open-source projects do :)

---

One does not need to open the server-side implementation code when just API access is needed. It would easily be possible to protect IP by segmenting those elements into a decoupled implementation. Many vendors have shown that strategy to work very well.

Quote:

---

Originally Posted by SkinAndMarrow

One does not need to open the server-side implementation code when just API access is needed. It would easily be possible to protect IP by segmenting those elements into a decoupled implementation. Many vendors have shown that strategy to work very well.

---

It might happen in the future. But the small team of FG developers already have enough on their plate that is promised to the community with the Unity migration. And I'm sure the list of things to consider after that is long as well. Perhaps in a year it would be appropriate for them to take a look at what it might take to do as you ask.