On May 1st we launched with 10 keys. Our mission to unify Steam gaming on linux. 10 brave souls took the plunge with us. Thanks to this small op we gained just enough info to begin shaping how best to proceed for the next build. Few things I learned... SteamVR Home/Hammer: We were able to do SteamVR on linux. Made notes too. SteamVR Home on linux works, but not the build tools. Old Hammer works on linux with wine/proto (running the game as windows using .exe instead of linux executable,) Source 2 hammer doesn't. SteamOS: Using SteamOS as a dev environment is not the intent of SteamOS but doable in many ways. Steam: (how it works) If we want to grow our user base, we simply need to continue generating new content. Licenses: We also learned a lot about source code licensing. Where GPL makes sense and where it becomes a problem (can't use gpl on steam because it can't be linked to closed source) The last part caused a sort of pivot for us and details on where we are pivoting in the "Where we are going..." part below (and more next month.) The two big things we learned about gpl that we didn't realize are: It is a social contract. The license is designed to put pressure on you to be all gpl or at least fsf approved. How are we handling this paradox of gpl SteamOS and yet the inability to distribute 3rd party GPL compiled source code on Steam? (and we did ask a few libs about getting exception to no avail.) Since linux is gpl, to keep within the spirit of the linux community we must adapt part of our approach to honor this social contract. However, I don't want gotchas popping up for our creators so this needs to be deliberate and strategized from day 1. We also will continue to state clearly we believe in less restrictions and getting away from pressure this is where our heart is on open source free to do whatever with no restrictions and no pressure to do things the way we do them. We want any content and code you add to be yours and for you to be able to use other works in a unrestricted way. This means we are more MIT/BSD/Apache leaning and only use restrictive open source when it is strategic to do so or we are required to do so. Furthermore GPL would only even be an option on server solutions anyways because we can't ship compiled GPL code on Steam. Lastly, our goal is to help small studios, small studios need to operate in the margins to begin to turn a profit and gain funding for their project/community working in the margins is easily blocked somewhere in the dev path with restrictive license mumbo jumbo, let us avoid that and keep it simple. ergo mit/apache/bsd etc. styled licenses. Similar for the art CC by without SA requirements. Where we are going. First and foremost I really want to release our 7 years of content and art and get feedback. I also want to begin revealing the deep universe and world background we have framed that mirrors the real one and get feedback. I also want to show the multiplayer and singleplayer offline feature day one or ASAP. I think we will go a MUD/MUX (multi user experience) early on. So everyone has something to do, can host a MUD on their linux server and run mini MUD communities. MUD tech is really lightweight protocol that should allow a lot fringe use cases and thanks to InterMUD specs we also have the path to allowing your MUD/MUX hub to be part of a larger decentralized world truly owned and controlled by you. For yourself, family / friends or a community. More details early next month on how we will release stage 1. Looking at Java server, with .net client so we can use it within our already existing code base. Also leaning towards Xenko engine for open source upstream details below. The biggest challenge. Shipping an editor along side the game enabling effortless sandbox at your finger tips easily tied to the main game repo. Solutions looked at. 1. Unity3d Pros. Asset and art protected, next gen shaders , 7 years working in unity. Cons. Not shipping an editor, but requiring a download. Not open source, monodevelop for code didn't work with unity editor on linux out of box. 2. Torque3d Pros. Great option mit license with battle tested networking, cons: only recently caught up to standards and rough at times, also c# support is there but needs to be worked on. 3. Xenko. Pros. Good because c#, IDE built in on linux and inspired by unity 3d, newly mit licensed. Con, only PBR shaders nothing next gen yet. 4. OpenSimulator Pros. Mit. Ownership game mechanics. Good self hosted networking with concept of hyper grid, can even run with physics on rasp. Pi. Only business facing solution too. Cons. Dated and pay to win economy in some areas. 5. HiFi. Pros. Apache license. Supports vr and crypto. Good graphics with other next gen feats. Like auto lip sync, dns grid support, networking and runtime content creation with opensim 2.0 styled options. Cons. Top notch bandwidth required, code is there but hidden and not end 2 end - still expected to use hifi account for things. Apache license con for our biz IP.