Hacker News new | past | comments | ask | show | jobs | submit login

I can tell you've never released a popular product on Linux. It's a lottttt more effort than you're implying. To do it well, you need to have Linux as a target from the start of your development, it's not something you can tack on to the end. Linux graphics drivers are very different from Windows (the AMD stack isn't even the same codebase). Linux window managers are... wild. You need to build to an ABI that will be supported across distros, which mostly means the Steam Runtime, which means you need to go learn about and understand that. You can't introduce any platform assumptions ("ehh, I'll just hardcode this path with a backslash... oops"). Once you release, you're talking support for dozens of different distros, different versions of distros, different package managers, different filesystems. I know what you're going to say: "Just support Ubuntu LTS and ignore everyone else". Well, now you've just cut your customer base by at least 75%[1], and your customers on other distros are going to demand support anyway. Do you tell a paying customer to F-off because they're not using a distro with only ~20% of the market?

Supporting Linux is hard. So is supporting Windows, but if Windows makes up 98% of your customer base, it's justified. 2%? Ehhhhh.

(P.S. I love Linux. See my profile. This is the kind of stuff I deal with every single day.)

[1] https://boilingsteam.com/we-dont-game-on-the-same-distros-no...




Open source your games. Open source is the only practical way that existing distros are able to test and support the majority of packages that they ship. If you do that, the cost of supporting all those other things will fall on the distros, not on you, but you need to actually play ball with them and give them something workable that isn't an opaque binary blob that is illegal to redistribute, modify or reverse-engineer. The feelings you're describing (that you need to shelter 100% of those costs and you have no other options) are a side effect of the game industry's cargo-culting of closed-source business models and refusal to even consider that there are ways to make money from open source.


Yeah, the solution to a platform not making enough money to justify supporting it is... giving away your game for free! The self-centered attitude of your comment is astounding, but all too common in open source communities.


You don't have to give your game away for free. I urge you to look into how prominent open source companies are actually making money and think about how it can be applied to games. It's not an impossible reality.

You claim I am being "self-centered" but the fact is if you don't provide something that the distros can work with and instead try to route around everybody and ship an untestable blob then that's your fault. The reason everyone tells you to just support Ubuntu LTS is because they are the only ones who have the resources to support all these random binary blobs for X amount of years, and that comes with all the pains associated with it, as you are well aware of.


> You claim I am being "self-centered" but the fact is if you don't provide something that the distros can work with

Alternative view: distros don't provide a stable platform that developers can target.


Some do provide that, such as Ubuntu LTS and RHEL. Others don't.

Expecting every distro to have the exact same release & support cycle is nonsensical.


Linux LTS releases are not particularly stable from the perspective of someone who wants to distribute applications as binaries. Its API can change with every release, i.e. every two years. It's incredibly unlikely that a binary compiled for Ubuntu 18.04 will be able to run on Ubuntu 20.04 (as in Python etc.).

To contrast, if you take a Win32 game from 2003 that targets DirectX 9, it probably runs fine on the latest Windows releases. (You might have to enable some compatibility mode.)

"BUT BUT BUT if it's packaged with the distro it's no problem." Remember we're talking about proprietary applications (mostly games) here. Having these packaged with distros for years after the devs moved on to the next project is just a pipe dream.


My original statement was that if this is really a problem for you then you need to stop writing and distributing proprietary binaries and open source your game. I know this is a hard pill for game developers to swallow but there is no other way. Open source communities move fast, they are not going to slow down just to support some opaque binary blob that is illegal to redistribute or fix bugs in, and that the original developer doesn't even care about anyway. It is nonsensical to expect these communities to work exactly like Windows. These are not fortune 500 companies with billions in the bank like Microsoft that can afford to keep innovating while also supporting every single legacy program in existence forever. The only way open source communities can provide the same level of support is if you provide source code that other interested parties can keep up-to-date without worry of being sued.


These prominent open source companies that you're taking about make money from consulting or cloud services. There's no well understood and well rested way to do that as a game company.

It doesn't mean that there's no such way, but it does mean that attempting to find it is very risky. Making games is already a very high-risk, high-reward industry, do adding this amount of risk to the equation is advice that's insane for all but most successful companies.


A multiplayer game is just like any other cloud service in terms of economics. And a game that allows a certain degree of customization is analogous to a consultancy. Find the pain points your business customers/partners are having and then charge for solutions. If you don't have any business customers/partners then get some, not having them is a much bigger risk than choosing any specific development model.

One of the ways these companies can reduce risk is actually by using other proven open source components. If they won't even make an effort to try to expand this, then there will never be a well-understood way.


> A multiplayer game is just like any other cloud service in terms of economics.

No, it's not - this is an absurd statement. Cloud services get most of their income from big and medium companies, billing tens and thousands of dollars in privately negotiated agreements. Digital Ocean and AWS don't live on single developers paying them $5. All their real money is on B2B.

Multiplayer games either get a flat subscription from all their playerbase, or rely on micropayments. Either way, they spend much less on account management where they interact with customers as individuals, and much more on analytics, where they measure and work with their customers in aggregate. These are completely different business models, that completely shape companies that operate on them.

> Find the pain points your business customers/partners are having and then charge for solutions.

Games are not solving any problems - they are entiertainment product. I've seen people who have tried to reason about games in the terms you're using, and it always yelded hillarious (but also sad) results.


Open sourcing doesn't mean you need to provide all the souds/music/3d models/assets/etc. Those can all be copyrighted separately.


> Open source your games. Open source is the only practical way that existing distros are able to test and support the majority of packages that they ship

Which might be one of the reasons Linux Desktop is so awful to develop for.


The "Linux Desktop" is not and has never been a thing beyond a vague marketing term. What you're thinking of is a loose collection of unrelated projects. Pick a single stack and go with it and things get better.


....Which might be one of the reasons Linux Desktop is so awful to develop for.

You wonder why people ignore your platform? Saying it isn't actually a single platform and instead is dozens of different platforms just means each of those platforms is even less relevant. Saying you're not just one platform with 10% market share but actually 20 with 0.5% each doesn't make the case for shipping on Linux Desktop any better.


I'm not making a case for shipping on the "Linux desktop" because that doesn't exist and has never been a real platform. Most smaller distros are not trying to be "relevant" to whatever the gaming community's fad of the day is. They're perfectly fine filling what niche they do. If you want to target those smaller distros as a platform, you can give them some source code to work with, or you can pay all the cost of maintaining things yourself, or you can just ignore those. They will do fine without your game.


So what are you saying? Developers should just choose a major distro and target that, then get all the flack for issues their product has on every distro that isn't supported? Because that's basically what's already happening and developers hate it, which is why they often don't ship on Linux at all.

And many proprietary pieces of software license components from other proprietary pieces of software, so that even if they did want to open their code they'd have to strip pieces out of it anyway which doesn't really help the cause of distros integrating it. And even if it did, then the developers are reliant on the maintainers for their relationship to their customers. Have an issue with the product? Oh, it turns out that's because of this patch made by the maintainer of the package for that distro, who now has to be contacted and convinced to fix it, which they may decide not to for arbitrary reasons. Even open source developers have problems with this!


In general, distro maintaners can't help you with legal conundrums you created for yourself (you signed restrictive NDAs and proprietary license agreements and didn't consider the fine print until it was too late) or with other unrelated market problems (lack of popularity, lack of developer interest in supporting your game).

If you need to strip out some parts and there is enough will in the community to replace those pieces that you stripped out, then it will happen. If you have a product that is anywhere near being popular among the FOSS developer communities then I don't think it makes sense for you to claim that this will doesn't exist, or that distro maintainers will lose interest.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: