Add RFC: Steam distribution for OBS

[derrod]

Summary

This RFC proposes distribution of OBS on Valve's Steam platform as well as considerations for OBS distribution on other third-party
platforms in the future.

Motivation

Over the years users have asked us to provide a Steam version of OBS for a few reasons:

• Convenience (automatic updates, one-click install)
• Non-Admin Users can install it with the Steam Service taking care of elevated operations
• Other commonly used utilities (e.g. ShareX, Precision, Video editors) already exist on Steam, making it a "One Stop Shop" for many people's gaming content creation needs

Additionally, certain Steamworks feature can allow us to offer a few optional features,
including some that currently are on the mid- to long-term roadmap for OBS, right away:

• Steam Cloud for syncing/backing up OBS settings and scene collections
• Opt-in branches for release candidates (or older builds)

It should be noted that we want to avoid vendor lock-in and thus refrain from adding Steam-specific code to OBS.
All of the features listed above are usable without having to add any code to OBS whatsoever.

The deployment process to Steam appears to be nearly entirely automatable with our current CI/CD solution (GitHub Actions),
only requiring human input to approve non-beta updates.

This makes providing a Steam distribution of just the latest Windows Release a potentially very low overhead affair.

Additionally, the lessons learned may prove useful for other distribution platforms that have been proposed (e.g. Microsoft Store).

View the RFC

[derrod]

PR for the proposed change to disable the updater: obsproject/obs-studio#3183

[Xaymar]

Finally, we likely cannot use the Steamworks SDK within a GPL application ([SDK Documentation about that topic]),
limiting the Steam features we can use to those that work without SDK integration.

It is technically (and legally) possible to avoid this GPL restriction through the use of IPC/RPC, as long as the intermediate language used between the processes is not also GPL licensed. For example, gRPC with ProtoBuf would work - but only as long as they comunicate at "arms length". That means that the steamworks program would need to be generic enough to not count as a part of OBS Studio, and then could be licensed under one of the SDK compatible licenses.

[derrod]

That is true and such a thing already exists and has been used by GPL licensed games that are on Steam: https://hg.icculus.org/icculus/steamshim

However, it's unlikely we'll actually use Steamworks SDK features. If we want more granular cloud sync we can also simply use the Steamworks Web API and not have to bother with writing a bunch of code to somehow link to the SDK.

Unless somebody feels like adding Achievements to OBS of course, then we'd need the sdk :P

[Xaymar]

The SDK would be useful for integrating the Workshop, which could be used by people to share Themes, Scene Collections, and Plugins. This would remove the need to have a DLC, which implies that plugin X is endorsed by the OBS Project, and instead makes it clear that X is provided by Y. Though this would be a massive change that likely has to go into another RFC.

[derrod]

While I've pondered that idea we do not want to rely too heavily on Steam. It's a test-run of sorts for distributing OBS on other distribution platforms (e.g. Microsoft Store) and it offers us some convenience features that we can use at nearly zero development cost since they work without actually having to integrate the SDK. But ultimately things like backups, update branches, and a plugin manager are all things that OBS should have natively and should not rely on a third party platform.

[dodgepong]

My concern with using Steam to do so many things (beta channels, plugin/theme distribution, cloud syncing) is that we're effectively going to need to implement things twice for when we support these features without Steam. I don't want us to start relying on Steam so much that we start directing even non-gaming users to download OBS through Steam if they want Feature X. If we want a beta channel, then let's change our updater and release process. If we want to distribute plugins/themes then let's build a plugin manager. We already have a hard enough time convincing people that OBS is not just for gamers.

[derrod]

Beta branches and cloud syncing do not require any code changes to OBS. Theme/plugin distribution is not directly part of this RFC. Though offering popular plugins such as obs-websockets as a one-click install through Steam may be something we can experiment with.

I do not believe that having these options on Steam disincentivizes development of native versions of those features. However as you know those things are on a long term roadmap. Offering these features optionally to people who want them is possible now and I do not see a reason to not do that.

Edit: I also updated the RFC with some changes to make it clear that I do not want to add any Steam-specific code to OBS. The part about cloud sync is there to illustrate a problem (credentials in profiles) and offering multiple approaches (still backing them up, not backing them up, or investigating changes to OBS that also accomodate other backup approaches as well) that are up for discussion (it is a request for comments after all). The plugin part is an example of optional features Steam has that we could play with (like the Linux Runtime) but not a requirement.

[Xaymar]

Steam Cloud Syncing only requires a configuration file on the Steam servers, and requires no other modifications to OBS Studio. Beta branches are also not something that require special code dedicated to Steam

If we want to distribute plugins/themes then let's build a plugin manager.

Is there an RFC for a plugin manager that goes into full detail on the necessary changes?

[dodgepong]

I do not believe that having these options on Steam disincentivizes development of native versions of those features.

That's very optimistic of you but we've seen this happen repeatedly on this project. Yes, there is always a struggle between "perfect is the enemy of done" vs. "there's nothing so permanent as a temporary solution." My fear is that relying on Steam to enable these features in the short term will perpetuate a wrong message to our userbase about who the program is intended for and what its intended purposes are. I can't imagine us telling a church to install Steam on their streaming computer so they can get cloud backups.

Is there an RFC for a plugin manager that goes into full detail on the necessary changes?

I'm not certain how complete this is, practically speaking, but yes: #4

To be clear, I'm not at all against distributing OBS over Steam. I am against it being the sole avenue for several program usability features that users have been asking us for.

[Xaymar]

IMO this RFC should be reduced to just distribution via Steam and adding the necessary Cloud Sync configuration, anything else is extra and should be a different RFC.

[derrod]

Okay I would propose the following changes:

Remove mentions of unused Steam features

This includes DLC and the Steam Linux Runtime. While the latter is something I'd still like to investiage a Linux distribution is not part of this RFC and the newer runtime that will be released sometime later might offer a better basis to build on. When that time comes we may revisit that as a separate RFC.

Remove now obsolete sections

Specifically the section about the updater and removed features as well as "Future Work"

Remove nightly branches

I would still like a branch for release candidates, as those are also published as "Releases" on GitHub and could be uploaded by the same automation that handles normal releases.

Reword cloud save section to make it clearer how they work and are implemented

While I understand your concern @dodgepong I do not believe that we should hold off on what comes down to basically just checking a checkbox on a web interface because a native implementation is not yet available.

My fear is that relying on Steam to enable these features in the short term will perpetuate a wrong message to our userbase about who the program is intended for and what its intended purposes are.

I think we can gear our communication towards cloud backups being a feature that is being worked on, we can also choose to simply not advertise the fact they're enabled for the Steam version at all. It also feels a lot like NIH to not use a feature that exists, just because we haven't built it.

I can't imagine us telling a church to install Steam on their streaming computer so they can get cloud backups.

I don't like this argument, it assumes that a) there is currently no way of having OBS settings automatically back up, and b) that Steam will be the only option for cloud backups in the forseeable future.

If somebody asks us for cloud backups, our current answer is

You can use workaround A, B, C, or D.

with Steam that answer would merely change to

You can use workarounds A, B, C, D, or Steam

If anything this tells us that available workarounds (e.g. running portable mode out of Dropbox, symlinking settings folders, or backups via cronjobs) are not sufficiently documented.

I have some ideas for how cloud backups could be done, but there are lots of different approaches with various degress of difficulty and there will likely be a rather long discussion around how to actually implement it. I would volunteer to start the RFC process on that as well. Because right now we don't have anything except a few ideas being thrown around on Discord.

[derrod]

A little update: I contacted Valve to make sure OBS would be shippable without the SDK and also asked about the fees. Their response was affirmitive and the fees for publishing OBS on Steam would also be $100 (same as Steam Direct).

[derrod]

As of March 22nd OBS is available on the Steam Store: https://store.steampowered.com/app/1905180/OBS_Studio/

This RFC is outdated in various aspects compared to what the actual implementation ended up looking like. There is no real reason to keep it open at this point, and given that the changes were implemented outside of the RFC system, I don't see a reason to merge it either.