What Should Valve Do For Linux & Open-Source?
Phoronix: What Should Valve Do For Linux & Open-Source?
What should Valve be doing for Linux and open-source software? They don't plan to just release the Steam client and select titles for Linux and then suddenly scream "MISSION ACCOMPLISHED!"..
Release source code to antiquated games (gems) like half life 1, doing so will allow the community to keep these games alive for as long as users are around. Data content is still required so, they still can make revenue (and maybe even more since customers know they can play the game on any device they own)
Valve can push things to happen more than the average linux user can. They could push for documentation and opening of device drivers more so than the end user could ever do. They could finance open source developers like nouveau .
Contribute to KDevelop / QtCreator to make the platform more attractive for developers used to Visual Studio. While I personally can't stand VS, in the research lab here it is basically the only reason most are using Windows.
While QtCreator is very solid, it's code analysis is still somewhat basic.
KDevelop on the other hand has some very nice features here and there, but it unfortunately still is, in some circumstances, too crashy or unreliable to really be recommendable for productive use.
I agree with pickle, open sourcing their Goldsrc back catalog would be one huge thing Valve could do. They are hardly expected to open source Steam itself since that is a DRM platform and they are still actively using Source for current and upcoming games. But Goldsrc is older and so they won't be revealing any precious secrets by open sourcing that. The fact that it is based on the Quake 1 engine shouldn't be a problem since I am sure that id Software would gladly allow them to do it since they themselves have already released the Quake 1(and Wolfenstein 3D, Doom 1/2, Q2, Q3A, Team Arena, RTCW, RTCW:ET and Doom 3 for that matter) source code.
Just by doing their job conscientiously and solving/fixing the problems they come up they'll benefit everyone. I'm sure there are a plethora of all kinds of bugs and problems with the drivers and the system. If they can fix some of those and document the rest they'll do a lot more than any conscious effort to improve something in Linux.
- Buy the S3TC patents and burn it with fire.
- Help improve Mesa, Wayland and the FOSS in-kernel/in-tree drivers (Nouveau, Radeon, Intel, etc).
That's the two things that are coming to my mind right now. Thanks so much Valve and Michael.
Last edited by asdx; 07-17-2012 at 10:21 AM.
I agree with Pickle in that open sourcing their back catalogue, such as Half Life, would be awesome. Also, improving Linux game development tools would also really help things. Anything that makes game development easier and fast. As an example, a Linux port, or an open source release, of the Valve Hammer Editor would be really helpful for game devs.
Sometimes I look at Unity3D and wish we had a Linux equivlanet. Unity3d's strength isn't is power, but how conducive it is to rapid iteration, of getting something up and running really quickly, and supporting fast changes (I guess Panda3d is a bit like it, but you see what I mean). There are a lot of development tools for Linux, but ones that make game development easier and faster would always be apprecaited (look at what Ren'Py has done, to give an example).
This will be an unpopular opinion on this board, but I don't think that open-sourcing their back catalog is the best use of their time.
Originally Posted by Sofox
I agree that it would be awesome, and open-sourcing anything is always good. But I'd much rather see a lot of other things come out of valve first.
There are 2 reasons:
1. Valve really supports their old games well to begin with. I can buy a copy of Half-Life (from 1998) right now off Steam, and it is fully supported. I can also get Half-Life Source, which is the same game ported to their more current engine. Based on past results, I fully expect to still be able to buy a supported version off of Steam 10 years from now. Or rather, I'm sure i'll get it for free, because they bundle that with a bunch of their other games for free.
2. Old Valve games were heavily MS dependent. It wouldn't be like Q3 or some ID code drop, where the code already basically works on linux. You'd have to essentially do a complete rewrite of the game - the benefit, of course, would be that you could always see the reference to look at exactly how the original game was done, but it would be a ton of effort for any project to get things working. At least past the WINE stage. To avoid that, you'd need to start with games that had already been ported to the Source engine, and that's new enough that i don't think Valve would be very receptive towards open sourcing that.
Be visible within the community
It might sound odd, but just being visible can reduce friction and potential problems.
It's really frustrating when people run into the FOSS community, do something amazing, then disappear.
Maybe send a guy to some of the larger FOSS conferences (LinuxCon, OSCON, etc.)
It also reassuring to know that you're aware of the next couple of evolutionary iterations.
Windows has traditionally been very slow to evolve (haven't used windows in some 10+ years, so ignore this if not applicable anymore), with long periods (years) of stagnation then a sudden, large jerk forward.
Linux is much more iterative, with lots of smaller changes over much shorter time-scales, and may require a different mind-set.
This is particularly apt for closed source software where we can't just recompile against the latest libraries.
Picking a project out-the-air just as an example; Wayland.
Knowing that you're aware of it (because you're visible in that community) is very reassuring to those who wonder how Valve's software will evolve over time.
Open-sourcing as much as possible is also a good way of ensuring your project stays on top of future advancements.
I realise that maintaining control over the platform is important, but also understand that the more open a "closed" project is the less of a burden it'll be to support everyone.
It should be possible for your project to be completely agnostic on a lot of plumbing infrastructure.
Eg. Display managers, as mentioned above, but also sound, distro packaging or any other plumbing piece that can be swapped out for something else.
It should be perfectly doable for example, to get the project into a state where any distro maintainer can create a package for Steam, or any of it's games.
Then the burden of packaging is not Valve's concern, but that of the individual distributions.
And lastly, communicate.
The last thing you want is to get into a situation like nVidia is now or xFree86-of-old where the only way people seem to be able to get things changed is to scream to high-heaven until they're hoarse in the throat and frustrated enough to usurp you in favour of a grass-roots alternative.
Keep the steam-client as open and flexible as possible, use sane library loading not locking it to the ubuntu/debian style and pointless version requirements like we see in many half-closed projects.