Thank you, Valve! But...

Posted Jan 25, 2014 1:21 UTC (Sat) by rahvin (guest, #16953)
In reply to: Thank you, Valve! But... by rahulsundaram
Parent article: McGovern: Valve games for Debian Developers

AFAIK Valve does not require remuneration for anything posted to Steam, for example the free to play (pay to win) games that are in numerous abundance. They also do not charge for access to, or use of the steam tools for use in distributing software via Steam and only collect a margin on sales.

Though I know of no examples of free (libre) software on Steam I highly doubt Valve would care if such software was offered through Steam. In fact the distribution and automatic updates could make it quite convenient. It's more likely that developers don't see the value if offering free software through Steam because it's just as easy to stick a download up on the internet.

Thank you, Valve! But...

Posted Jan 25, 2014 1:27 UTC (Sat) by khim (subscriber, #9252) [Link] (9 responses)

It's more likely that developers don't see the value if offering free software through Steam because it's just as easy to stick a download up on the internet.

It's much harder for the developer and much simpler for user because Valve will not distribute just any program, they need to review it first. There are process for large publishers and there are greenlight for indies, but I'm not sure if FOSS games ever tried to pass it.

Thank you, Valve! But...

Posted Jan 25, 2014 3:39 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

FOSS from the start? I don't think so. I have the source for Penumbra on my machine as well as source releases for Aquaria, Luguru and a few other games which have been part of the Humble Bundle. All of these are on Steam. Valve certainly hasn't rescinded their Steam distribution rights because of it.

Thank you, Valve! But...

Posted Jan 25, 2014 4:21 UTC (Sat) by raven667 (subscriber, #5198) [Link]

If FOSS game developers think their stuff is any good they should try to distribute their work where more of the public can see it, on Steam. It'd be cool to see tux racer or wesnoth up ther next to everything else and if they do charge money for the binaries it could be a small revenue stream to cover the costs of making the games.

Thank you, Valve! But...

Posted Jan 25, 2014 11:29 UTC (Sat) by kleptog (subscriber, #1183) [Link] (6 responses)

> It's much harder for the developer and much simpler for user because Valve will not distribute just any program, they need to review it first.

Wait now, is this a counterpoint to the recurring argument "distributions are unnecessary, every developer should be distributing directly to users"?

Looked at this way, Valve is doing for games what Debian does for FOSS: providing a stable platform for developers to work on.

Thank you, Valve! But...

Posted Jan 25, 2014 14:50 UTC (Sat) by khim (subscriber, #9252) [Link] (5 responses)

Wait now, is this a counterpoint to the recurring argument "distributions are unnecessary, every developer should be distributing directly to users"?

Please stop inventing strawmans. Whenever problems with distributions are discussed the opposite model is not “direct distribution to users” but rather “appstore model”: developer is given API and it creates package then “appstore” does the rest. It can be coupled with “direct distribution to users” (as in Android) or not (as in iOS), but the important thing is that there are stable API, there are SDK and developer just need to built it's package once and developer determines how it should look and work. Distribution channel may reject something if it does not think it's adhering to the guidelines but under no circumstances can it change package without developer's knowleadge. Compare with distributions where mere mention of the want to control the package leads to temper tantrum.

Looked at this way, Valve is doing for games what Debian does for FOSS: providing a stable platform for developers to work on.

Not even close. Valve just provides platform for developers. Yes, with some rules, approvals and so on, but still in the end developers decide what is launched when and how. Debian developers take stuff from FOSS developers and try to create coherent whole from that. Developers themselves have no control over their creation: packagers determine when and what will be shipped and in which form. Big difference. Even Apple does not have hubris to demand that from developers—they have strictest rules out of all “appstores” (they can get away with that because they are sole gatekeepers to hundred of millions of paying users), but even Apple does not dare to demand so much from developers as Debian or Fedora demands.

Thank you, Valve! But...

Posted Jan 25, 2014 17:14 UTC (Sat) by vonbrand (subscriber, #4458) [Link]

What do Fedora, etc "demand"? Anybody can set up their own software repository (and many thrive).

Thank you, Valve! But...

Posted Jan 27, 2014 19:19 UTC (Mon) by anselm (subscriber, #2796) [Link] (3 responses)

Developers themselves have no control over their creation: packagers determine when and what will be shipped and in which form.

Nothing prevents developers from packaging their own software for Debian if they want to control how that is done. The only requirement is that the resulting package must comply with Debian policy.

The upstream developers don't even need to be accredited Debian developers/maintainers themselves if they can find somebody to sponsor uploads of their package into Debian.

Thank you, Valve! But...

Posted Jan 27, 2014 21:05 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

You're missing the big picture. Here's what you need to say if you want to be accurate here:

> Nothing prevents developers from packaging their own software for {Debian,Fedora,Arch,OpenSUSE,Gentoo} if they want to control how that is done. The only requirement is that the resulting package must comply with {Debian,Fedora,Arch,OpenSUSE,Gentoo} policy.

That's quite a bit higher of a bar. Five *different* packages need to be created which have 5 different sets of rules which need to be applied. What khim is arguing is that upstream needs to be able to create *one* package for Linux users and that's *it*. It also should, ideally, not need redoing 3 years down the line when the project has zero money left.

Thank you, Valve! But...

Posted Jan 27, 2014 21:17 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

You have to decide what you want. If you don't want to take the trouble to create a Debian package for your software, then chances are you will find some Debian developer who would be happy to do it for you. If you want to have complete control about how the packaging is done, you can do it yourself.

Khim can argue for a unified packaging method until he is blue in the face but that doesn't make it more likely to happen. For the time being, the distributions are what software producers need to work with, and claiming that getting a package into Debian means giving up control of how the packaging is done is simply not true – there are lots of options for achieving this, including ones that do not require giving up any control at all.

Thank you, Valve! But...

Posted Jan 27, 2014 22:11 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> Khim can argue for a unified packaging method until he is blue in the face but that doesn't make it more likely to happen.

I agree with the sentiment, but that doesn't make the problem go away either. The root issue is that the relationship with distros and upstream is backwards. Usually the distributor chases developers to use their mechanisms (we have umpteen thousand users!) whereas in a distro, the upstream has to chase the distro to ship their software "properly". The alternatives are to bundle libraries so that they can't be left stranded when everything moves from underneath them (the best solution today) or to keep chasing the distro when things upgrade (which requires money with near-zero ROI and therefore won't be done).

Personally, I prefer the .sh bundles that are available on Humble Bundle because I can put them on a separate partition (I run ~5–10GB for / which won't fit many game assets). They all get installed to $prefix/games/root/$game which also makes uninstall easy (rm -rf). I also don't have to worry about suid problems since root never touches the files.