How a single 3rd party (like Valve), can address and solve most of the Issues from Linux Sucks!

I wanted to go back to Brian Lunduke's Linux Sucks! presentation and detail how a 3rd party developer, such as Valve, can make Desktop Linux profitable. Now, I'm not picking up Valve for pure example purposes. I honestly believe that Valve has every intention of bringing Steam to Linux, and here's why: Valve is in the publishing business to make money.

Many of the independent publishers in Valve's current Windows stable, such as 2D Boy and Penny Arcade's PlayGreenHouse games, are pushing their games on a multi-platform basis. Even if Valve only gets 50cents back for every game sold from Independent Developers, even a really low number of sales, say like 6000 units moved, that is still $3000. Every time one of the independent developers sells a game on a platform Valve does not currently support, Valve is loosing a potential sales commission. My opinion is that Valve wants in on that Independent Market, because it's not going away, and it's not going to get smaller.

From a business perspective, Valve doesn't have a choice in whether or not they support Linux. In order to maintain their edge as the leading digital publisher, they'll have to expand to the platforms that their development base expands to.

Such expansion though could solve many of the various problems Desktop Linux has, as outlined by Mr. Lunduke's presentation. One of the first problems Desktop Linux has is the package fragmentation. Linux is by and large split into RPM and DEB packaging formats... and no matter how many times outside observers suggest merging the two projects or dropping one, such a merge or deprecation is never going to happen. For some Linux developers, their choice of packaging system is almost a holy grail. There have been physical wars less hostile than the flame wars that erupt when somebody suggests RPM or DEB is superior to the other. The Linux Standards Base, or LSB, chose to specify Red Hat's RPM format as the LSB standard. However, the most popular desktop and server Linux's, Ubuntu and Debian (pure) are not built on RPM.

In order to move Desktop Linux forward, let's remove the packaging consideration. The proof of concept is Transgaming's Cedega. For literal years Transgaming has been packing Cedega in a varitety of different formats. Currently Cedega is available in 5 different packing systems. The end-user downloads Cedega in their packaging format, installs it in their native package manager, and then the Cedega System takes over installing and running games from that point.

Under Windows, Valve's Steam has largely matched Debian's Apt and dpkg system for functionality. Users are able to download, update, install, pause installs, stop installs and start at a later date, and launch their programs automatically from a central GUI. Following the proof of concept that is Cedega, Valve specifies a containment folder, and a software packaging for developers to use. Software developers write to the packaging format specified by Valve, and that is all they have to concern themselves with. The game developer doesn't have to worry if the user is on Mepis, Red Hat, Suse, Mandriva, PCLinuxOS, or whatever. The developer just has to worry about producing one package that is compatible with the specification set by Valve.

Valve then turns around and produces different versions of the Steam Client for different packaging distributions. The result is that Valve's packagers are the only ones who have to worry about packing requirements. Again, this type of system is proven to work.

In the same manner, this central specification also solves the duplication of API efforts. Valve's Steam for Linux includes various functions such as allowing users to view and download video content. The production of Steam then would require Valve to select a specific Audio API and Media system. Developers publishing through Valve only have to worry about the API's that Valve Specifies. Distributions who wish to host Steam will have to also make sure they contain the same API's and media backends as the specifications. Those that don't... well... won't be able to run Steam on Linux.

Okay, these methods are going to step on some toes. I know there are lots of people that have worked long and hard on stuff like Jack, Phonon, Gstreamer, Xine, PulseAudio, ALSA, Open Source Sound, and so on that are going to get torqued off if their particular technology isn't chosen. Those who aren't chosen are just going to have to DEAL WITH IT.

So there's the packaging and API issues dealt with. That removes two of the large barriers that prevent some commerical vendors from approaching Linux as a binary client platform. How in the world can this scheme be profitiable though?

The proof-of-concept here is Mozilla and Google. Google effectively pays Mozilla to include Google search as the default search option in Mozilla Firefox, and to set Google as the homepage.

In the same way, a 3rd Party like Valve would pay a Distribution to Include Steam. The problem here is that Linux is largely free to download. How would simply including Steam get developers money?

The proof-of-concept here is Google Ads. Google pays out a minimum for ad-placement and uses a unique identifier for each account to make sure the appropriate person gets paid for the ads.

Valve has a sophisticated hardware and software detection system in place inside of Steam, and their hardware reports are considered to be some of the most accurate examples of real-world hardware usage. Valve simply builds a version of their Steam client with a unique Distribution ID for Distribution partners, and this Distribution ID is part of their hardware / software scanning. Using Mepis as an example, Warren, the creator of Mepis, signs a deal with Valve for a customized version of Steam with a unique identifier for versions of Steam pre-installed inside of Mepis. Every new user with a unique hardware configuration, MAC Address, and ip address that registers with Steam from Mepis is worth a 5 cents kickback. Every game that is purchased from within the Mepis Steam client is worth a 50cents kickback, regardless of Hardware configuration and ip address.

With this sort of promotional scheme, distributions that result in new user accounts are written off as promotional advertisements. In addition, end-users are also unable to flood a particular distribution with new user signups as only one specific hardware configuration can be used to generate the initial kickback. However, distributions that result in new games actually being sold stand to recieve significant financial rewards.

One of the keys here is that not every distribution is going to go for a pre-installation of closed-source software. Valve can also limit the number of distributions that could abuse the system by requireing distributions produce a valid Business Liceness for the state or country they operate out of.

Thus, multiple problems are solved for Desktop Linux. Desktop Linux gains a proven central online digital store that many publishers feel comfortable using. Developers behind API's are encouraged to focus on a small select group of API's rather than re-inventing the wheel over and over. Some distributions stand to gain finanically for pre-installing Steam for their users. Valve's potential financial losses are minimized, and the gains of being an established store-front with near 100% marketshare should be self-evident.

In addition, the realization of the micro-payment financial model stands to help other projects within Linux as well. One of the functions Steam integrates into Windows is the ability make back-up copies of various games. If the Steam client for Linux integrated say, K3B, Valve could be in a position to kick back a percentage of profits from Linux game sales to the K3B developers, thus paying for the development of burning technology. That could get interesting if Valve were to think about implementing a system that allows gamers to record games as they play, then burn those videos to CD's or DVD's.

I've also stated, multiple times, that I don't understand why game developers are not involved with projects like X.org ATi, RadeonHD, or Nouveu. Really, who would be better than Gabe Newell to weigh in on how shader driven hardware should work? Okay, aside from John Carmack and Tim Sweeny, there aren't that many more qualified.

From Valve's perspective as an Independent Software Vendor, it might be in their interest to contribute to open-licensed drivers, if not outright hire developers to work on open-licensed drivers, in order to optimize those drivers to give the most performance in their games. Lets say Valve releases and update to Left-4-Dead that causes problems on a Radeon Crossfire setup with X.org ATi. Rather than waiting for ATi developers to turn around and investigate the problem, Valve could take a look at the source code, right then and there, write a patch themselves, and publish it.

Now, there are some, if not many, in Linux who would detest the idea of a single company perhaps offering such control over Desktop Linux. The reality though is this: Valve isn't the only digital games provider on Windows. They do have lots of competitors ranging from Amazon.com to Good Ole Games. Valve has just risen to the top by offering a superior product for a lower cost. In the same way, Valve may not be the first vendor to spread themselves over to Linux, and if they do wind up being the first, they won't be the only ones. If nothing else, the competition will keep companies honest in their dealings.