My internship for Mozilla was crazy: the noise floor from people screaming about what should be done is very high. When anyone can participate, anyone will participate. Working on Namecoin (where day traders come in and make lots of demands) made me jaded: I was pretty ruthless when using moderation tools. Sadly, Github doesn’t provide great moderation tools and changes to web standards attract enough attention that you can’t even read through a comment thread. But creating a stand-alone wiki and Q&A forum meant duplicate access-control and content vetting.
Patreon is a great way to filter user input to only those willing to pay money! Someone needs to invent a pay-fo-answers Q&A site….
Someone needs to invent a pay-fo-answers Q&A site….
On a related note, I’ve been considering ignoring issues on my GitHub repositories and offering some sort of paid support instead. Maybe something like “pay me $42 and I’ll publish a 1 hour video of me working on your issue”? I’m not sure how you’d deal with leftover time, since some issues can be resolved in 5 minutes, but I’d really like to be able to give attention to people who care enough to support open source.
This reinforces my somewhat unpopular opinion that, despite the common ideology, open source is good for developers, and irrelevant or sometimes even harmful to users. The “user benefits” of open source are only obtainable through the work of developers. Users can’t contribute source (by definition: that’s what I mean by “user”) so they are in the same powerless position whether the software is open or closed source. The difference is just what developers the users get to deal with. Do they work for an old school proprietary software company so you get a binary every year? Are they independent guns for hire who will plug together your solution from open source components for cheap? Are they, as in this case, a messy battlespace of good guys versus jerks, with the jerks winning because the users really don’t care where the software comes from?
Where the users are developers, as in so many common success stories for open source (editors, compilers, operating systems, databases…) it works pretty well. Otherwise, there’s a chasm that’s hard to bridge.
Users can’t contribute source (by definition: that’s what I mean by “user”) so they are in the same powerless position whether the software is open or closed source
(I will rather talk about free software than open source, but in this particular case, it is interchangeable)
Even if the users do not understand the source code and are unable to read or write it themselves, they benefit from the free software. If the software is free, they always have the opportunity to ask someone else than the original author to improve/modify the software. This is not possible with proprietary software. The users might chose anyone on the market, the best opportunity, to provide the service (either paid or for free). Yes, sometimes you have to pay for someone’s else work, but it is normal – you can not (ethically) force other people to do what you want for free. In case of proprietary software, the original author has monopoly to do changes in the code. In case of free software, anyone can do it (either personally or ask or pay someone else to do it).
If the software is free, they always have the opportunity to ask someone else than the original author to improve/modify the software. This is not possible with proprietary software. The users might chose anyone on the market, the best opportunity, to provide the service (either paid or for free). Yes, sometimes you have to pay for someone’s else work, but it is normal – you can not (ethically) force other people to do what you want for free.
It sounds like this was more or less the dynamic going on with the third-party builds talked about in this article - the core Citra developers cared about keeping a clean git history and a maintainable codebase, which traded off against feature and performance velocity. So third parties forked the Citra codebase and threw together something messy but functional, in a way that solved at least some users’ problems better than the official fork: “Users trusted these builds that violated Citra’s license over Citra’s core development team.” Of course it’s problematic that these third parties violated Citra’s license (which looks like the GPL v2) by not releasing their own source code, and there’s nothing wrong with demanding that those third-parties do so. But assuming they were adhering to the terms of the GPLv2, being able to fork code like this to do something different than what the original developers wanted is part of the point of free software to begin with.
Which is part of my point: If you believe the author, the third parties didn’t solve the problems, they just misled the users with “fake news” and derailed the project overall. In which case this is an example of open source allowing “bad developers” to take over the product process and harm users.
This is where my formulation is unclear, but I’ll try to improve. The user always has to get help from a developer to implement what they need — regardless of whether the developer is proprietary, freelance, or the user’s own employee — that’s why I say users are powerless without developers. That fact is independent of whether the software is open source or not. Open source just allows a larger choice of developers; it doesn’t inherently make the relationship between users and developers better. In fact, it arguably makes it worse because it tends to subvert the standard ways users have convince developers to meet their needs (i.e., giving them money).
In other words, users don’t benefit directly from the source being open, and they may benefit from having a larger range of developer options. But in the case where the users aren’t themselves developers, I see a much weaker story for why that’s a net positive benefit.
This is a very interesting read, but I’m not sure how much this translates into “normal” open source development. I think that the audience for these kinds of products might skew “younger” - or at least not be as immersed in open source culture as other users.
I do find the discussion about closed source development and Patreon funding fascinating too. I’m a firm believer in straightforward funding for development projects, something that still has to be hashed out to mesh with open source.
I think you nailed it re: the audience for this kind of stuff. Games are an interesting space here - you could argue that most of the users really don’t care about open source and just want to play their games. For better or for worse, they also don’t care where the executables/games come from.
It was really fascinating to read about the legitimate reasons for being closed source, and how it actually could benefit the user by shielding them from bad executables and so on. I used to consider the Patreon pattern you see CEMU and Yuzu doing a bit shady, but now that I better understand the context I respect the decision.
It might sound too formal, but I would recommend adopting a project methodology like PRINCE2. At least as a metal experiment / simulation. Define the roles and responsibilities. Define the business case. And imagine the processes and interactions as described by the methodology.
My internship for Mozilla was crazy: the noise floor from people screaming about what should be done is very high. When anyone can participate, anyone will participate. Working on Namecoin (where day traders come in and make lots of demands) made me jaded: I was pretty ruthless when using moderation tools. Sadly, Github doesn’t provide great moderation tools and changes to web standards attract enough attention that you can’t even read through a comment thread. But creating a stand-alone wiki and Q&A forum meant duplicate access-control and content vetting.
Patreon is a great way to filter user input to only those willing to pay money! Someone needs to invent a pay-fo-answers Q&A site….
On a related note, I’ve been considering ignoring issues on my GitHub repositories and offering some sort of paid support instead. Maybe something like “pay me $42 and I’ll publish a 1 hour video of me working on your issue”? I’m not sure how you’d deal with leftover time, since some issues can be resolved in 5 minutes, but I’d really like to be able to give attention to people who care enough to support open source.
This reinforces my somewhat unpopular opinion that, despite the common ideology, open source is good for developers, and irrelevant or sometimes even harmful to users. The “user benefits” of open source are only obtainable through the work of developers. Users can’t contribute source (by definition: that’s what I mean by “user”) so they are in the same powerless position whether the software is open or closed source. The difference is just what developers the users get to deal with. Do they work for an old school proprietary software company so you get a binary every year? Are they independent guns for hire who will plug together your solution from open source components for cheap? Are they, as in this case, a messy battlespace of good guys versus jerks, with the jerks winning because the users really don’t care where the software comes from?
Where the users are developers, as in so many common success stories for open source (editors, compilers, operating systems, databases…) it works pretty well. Otherwise, there’s a chasm that’s hard to bridge.
(I will rather talk about free software than open source, but in this particular case, it is interchangeable)
Even if the users do not understand the source code and are unable to read or write it themselves, they benefit from the free software. If the software is free, they always have the opportunity to ask someone else than the original author to improve/modify the software. This is not possible with proprietary software. The users might chose anyone on the market, the best opportunity, to provide the service (either paid or for free). Yes, sometimes you have to pay for someone’s else work, but it is normal – you can not (ethically) force other people to do what you want for free. In case of proprietary software, the original author has monopoly to do changes in the code. In case of free software, anyone can do it (either personally or ask or pay someone else to do it).
It sounds like this was more or less the dynamic going on with the third-party builds talked about in this article - the core Citra developers cared about keeping a clean git history and a maintainable codebase, which traded off against feature and performance velocity. So third parties forked the Citra codebase and threw together something messy but functional, in a way that solved at least some users’ problems better than the official fork: “Users trusted these builds that violated Citra’s license over Citra’s core development team.” Of course it’s problematic that these third parties violated Citra’s license (which looks like the GPL v2) by not releasing their own source code, and there’s nothing wrong with demanding that those third-parties do so. But assuming they were adhering to the terms of the GPLv2, being able to fork code like this to do something different than what the original developers wanted is part of the point of free software to begin with.
Which is part of my point: If you believe the author, the third parties didn’t solve the problems, they just misled the users with “fake news” and derailed the project overall. In which case this is an example of open source allowing “bad developers” to take over the product process and harm users.
This is where my formulation is unclear, but I’ll try to improve. The user always has to get help from a developer to implement what they need — regardless of whether the developer is proprietary, freelance, or the user’s own employee — that’s why I say users are powerless without developers. That fact is independent of whether the software is open source or not. Open source just allows a larger choice of developers; it doesn’t inherently make the relationship between users and developers better. In fact, it arguably makes it worse because it tends to subvert the standard ways users have convince developers to meet their needs (i.e., giving them money).
In other words, users don’t benefit directly from the source being open, and they may benefit from having a larger range of developer options. But in the case where the users aren’t themselves developers, I see a much weaker story for why that’s a net positive benefit.
This is a very interesting read, but I’m not sure how much this translates into “normal” open source development. I think that the audience for these kinds of products might skew “younger” - or at least not be as immersed in open source culture as other users.
I do find the discussion about closed source development and Patreon funding fascinating too. I’m a firm believer in straightforward funding for development projects, something that still has to be hashed out to mesh with open source.
I think you nailed it re: the audience for this kind of stuff. Games are an interesting space here - you could argue that most of the users really don’t care about open source and just want to play their games. For better or for worse, they also don’t care where the executables/games come from.
It was really fascinating to read about the legitimate reasons for being closed source, and how it actually could benefit the user by shielding them from bad executables and so on. I used to consider the Patreon pattern you see CEMU and Yuzu doing a bit shady, but now that I better understand the context I respect the decision.
It might sound too formal, but I would recommend adopting a project methodology like PRINCE2. At least as a metal experiment / simulation. Define the roles and responsibilities. Define the business case. And imagine the processes and interactions as described by the methodology.