• 0 Posts
  • 61 Comments
Joined 1 year ago
cake
Cake day: June 2nd, 2023

help-circle










  • As another poster alluded to, digital goods aren’t really considered property in the traditional sense. Digital property is protected under copyright (and other IP laws). The owner could sell the game, but then they wouldn’t own it anymore (e.g. when one game studio buys another, they are buying the games as well). Instead, they grant a licence to use the game, which is how Steam works as well.

    If Steam let you transfer your account to someone else (e.g. bequeath or sell it), then they would need this in the licence (which they could do in theory). Other than the logistics of that (especially how to handle people selling accounts - and the scammers that inevitably come with that), the AAA publishers are unlikely to agree to those terms. Ultimately the Steam licence is likely a compromise between Steam’s vision and all the AAA publishers that wouldn’t publish on Steam if they didn’t get the licence they wanted. A bit like how Netflix doesn’t really care if you use a VPN, they just have to enforce it so studios will let them use their content.





  • In the official announcement, they have very carefully and deliberately avoided the term “open source”.

    “Open source” has a very specific meaning, and probably the key part for this is if there are any restrictions on what you do with any derivative software you create.

    Can you use the Winamp source code to create a new media player and sell it? If there is say a restriction on if you can use it in a company or on if you can sell it, then it’s not “open source” even though you can publish noncommercial software based on it.






  • Oh for sure. I don’t think this advice applies to projects that already have a following. But many, perhaps most, projects don’t have much of a following even if you intended for others to use it. If you have a pet project that a reasonably small number of users, you might find you get occasional pull requests but they never meet the code standards, or you ask for changes but they never happen and the pull request sits there, or you reject them because you wouldn’t have structured it like that - well consider accepting the pull request and merging as is. Then you can follow up with changes to fix code quality with your own changes.

    This approach shows you appreciate the contribution, even though it’s not perfect. If you find the same person contributing often but making the same errors, then for sure mention it in a way that’s easy for them to understand how to resolve it. But if you’re rigid then you probably won’t get so many contributions as people will think they aren’t up to your standards.

    I’d also argue that merging then fixing up yourself later would be more time efficient than reviewing code and providing feedback on changes to be made 😆