It's different to be sure, but there are a LOT of parallels. Pretty much every instance where you have a given entity providing a platform you'll run into these kinds of issues, because rules exist, are enforced, and inevitably in that subgroup you'll have people who believe they were enforced wrong.
And sometimes they're right, but it's such a vanishingly small number that you'd be forgiven for mistaking it as a rounding error.
> When you rule by fist and swathing generalizations in an app marketplace, developers (and their incomes) become casualties.
Is it a vanishingly small number or is it one that you can't honestly track because you're not actually investigating on a per case basis?
The alternative is to... maybe not be super unfriendly and unhelpful when your account gets terminated? Maybe issue a warning first stating when and how you're violating a rule so you have a chance to correct it?
> Is it a vanishingly small number or is it one that you can't honestly track because you're not actually investigating on a per case basis?
The problem is this data is not tracked. Internally, an organization would say: Moderation was performed > Moderation was Investigated > $outcome, being either: Correct/Incorrect. But because of the he said/she said factor, if it was wrong, the person is reinstated, and they wouldn't be complaining about it. If it wasn't, that person would then, as is the case of the OP, be posting on their own blog or whatever complaining about it. The point being: those complaining about being kicked out are a self-selected group of people who were kicked out who believe Apple was incorrect in their decision. The others aren't talking about it because it's already resolved for them.
Who's right? Who knows. Even the GP comment we're all replying to conveys information, relevant, that the poster of the blog post decided to omit from their recounting of the events. Information which would prove Apple's actions correct. I don't know if Apple was right to ban him, but the fact that the first reply makes mention of documented instances of the developer breaking the ToS is interesting, since said developer made no mention of it themselves. It certainly dings their credibility as far as I'm concerned.
> The alternative is to... maybe not be super unfriendly and unhelpful when your account gets terminated? Maybe issue a warning first stating when and how you're violating a rule so you have a chance to correct it?
You do. Failing an app review, for example, does not lead to account termination. You're given explicit notes on what's wrong with the app, what you're doing that Apple doesn't like, and the only "consequence" of that is that your new code doesn't go live yet. You're given exactly that: time to fix it.
In the case of the GP though, if we assume this is correct and this person was using their developer access to publish information about upcoming Apple products ahead of their release curve, which is indeed against the ToS, then there's no way to have them "fix" that. They're abusing their privileged access in a way Apple doesn't want. Therefore, revoking that access is the logical next step.
Basically my thinking is this: If you agree to be bound by terms of use, and then do one of the things explicitly disallowed in those terms of use, you forfeit your right to whatever agreeing to those terms of use enabled you to do: in this case, developer account access.
And sometimes they're right, but it's such a vanishingly small number that you'd be forgiven for mistaking it as a rounding error.
> When you rule by fist and swathing generalizations in an app marketplace, developers (and their incomes) become casualties.
And what's the alternative?