Our insight after getting into the audio space was that podcasters are relatively happy with monetization. This is obviously not a popular opinion, but that's what we saw first hand. Ad rates are pretty good, and unlike other content types, listeners enjoy host-read ads. Meanwhile, Buy Me A Coffee started getting a decent amount of traction even among podcasters, so we wanted to go all in and build it out :)
We are the same company/team, and our goal is to help creators get paid for their work. With Brew, we focused on audio creators. Everything we built so far revolved around this vision :)
I don't want to speak for YC, but the partners want you to iterate and succeed. Many of the successful YC companies (Reddit, Brex) got accepted for a completely different idea.
Hey, I just came across your tweet [1] and wanted to say that we think about this a lot. The most effective way to attract more contributions is to offer something extra or exclusive. Obviously, this is not possible for everyone, so we designed Buy Me A Coffee in a way that every supporter and their comment gets featured on the top. We then notify the creators and encourage them to reply. This way, the act of supporting itself becomes the reward.
Thanks again for the feedback, and thank you for your blog!
We do have a bug bounty and encourage bug reports from our users (https://twitter.com/PJijin/status/1186904518341955584). The policy mentioned above is to avoid any damages to the creator(s) on the platform. Thanks for the feedback!
You have a policy that guarantees every single security researcher that inspects your platform will be in violation of your TOS. But you're telling us on an Internet forum that you won't use that policy unless someone does something completely awful. That's asking us to put a lot of trust into you -- trust that you're not willing to reciprocate back to us.
People shouldn't need to break your TOS to report a bug to you, and they shouldn't need to rely on purely your goodwill to protect themselves. Security disclosure is already a really scary process, researchers need explicit guarantees that they won't be prosecuted or sued. If a company tells me that I should just trust them that they won't sue me or ruin my life over a bug report, I stop going through their official disclosure channels, because it's no longer worth the risk. Policies like this are a really good way to get security bugs reported as anonymous Pastebins in the press instead of to your official channels.
I would also note that outside of security research, this bans people from building tools around your site -- browser extensions that automate common tasks or alternate clients that call into unsupported or private APIs. I think that's a really regressive restriction for something as fundamental as a payment platform to have.
Again, maybe your actual policy will be not to go after people who build useful tools -- but in that case, why start out with a TOS that encourages an unhealthy power dynamic, that means you could shut down someone who interops with your service for any reason?
The point of a TOS is to create clarity -- it's an agreement so that both users and platform owners know what's expected of each other. I don't expect a TOS to enumerate literally everything that might happen, but I instinctively recoil away from a TOS that includes onerous restrictions that I'm told to just ignore. A rule that everyone is expected to break is really just a blanket license to selectively punish anyone on your platform for any reason. Why should I as a user trust you with that kind of power?
In regards to protecting creators and avoiding creator damages -- hacking is already a federal crime. What's something that this policy protects you against that couldn't be handled by the Computer Fraud and Abuse Act?
Instead of "you are not permitted to reverse-engineer", maybe "you are not permitted to interact with the server except through the user interface produced by a web browser in accordance with the HTML-based instructions sent to your machine by our web server unless given explicit permission by us"; that effectively prevents people from using that reverse-engineered knowledge to attack your site, whilst still permitting bug reports.
