Scenario One: Pissed Off Developer Develops Desktop App.

1) Desktop app instructs user to register his own OAuth app in his own
Twitter account, and enter the consumer key & secret in the desktop
app.
2) User gets his own vanity anchor text & hyperlink in the source area
of his tweets.
3) If Twitter suspends the app, it affects only that user.

Scenario Two: Pissed Off Developer Modifies His Web App

1) Web app instructs user to register his own OAuth app in his own
Twitter account, and enter the consumer key & secret on his user
account in the web app.
2) User gets his own vanity anchor text & hyperlink in the source area
of his tweets.
3) If Twitter suspends the app, it affects only that user.

The solution is _not_ in suspending applications and creating
uncertainty, anxiety and fear in the developer community. The only
thing you accomplish is creating a bigger nightmare for yourself.

On Feb 15, 9:51 pm, PJB <pjbmancun...@gmail.com> wrote:
> Yep, that should have been implicit in my post.
>
> Anti-spam actions should be chiefly aimed at abusive users, rather
> than developers.  After all, it may be pretty easy for Twitter to
> limit what Web-based apps can do, but won't such behavior just shift
> to the Desktop, in even more flagrant and ridiculous flavors?  And
> won't legitimate business uses be unfairly taken out (or never get off
> the ground) in such developer dragnets?
>
> Sadly, it seems as though a chief impetus behind the OAuth push is for
> exactly that reason: to more tightly regulate and limit third-party
> Twitter apps.
>
> On Feb 15, 5:24 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
>
> > Well PJB, there is always a completely different approach that Twitter
> > could take.
>
> > They could bolster their internal coding and defenses against what
> > they consider to be abuse, much like they did for duplicate content,
> > and then not suspend applications at all.
>
> > That way applications can try whatever they want. If they run into a
> > Twitter defense, such as a rejected update, then no harm is done on
> > either side, except maybe wasted bandwidth and processing resources.
>
> > On Feb 15, 9:16 pm, PJB <pjbmancun...@gmail.com> wrote:
>
> > > Frankly, I sort of hope that Twitter DOESN'T further define their
> > > nebulous rules.  Why?  Because when they do, the axe often falls on
> > > legitimate app developers (rather than abusive users or problem apps)
> > > in really short-sighted ways.  Moreover, their rules are usually
> > > blanket pronouncements without regard for important business cases for
> > > certain features.
>
> > > For example, Twitter used to say that follower "churn" was against
> > > their rules.  Okay, that's certainly fair and fine.  But now they've
> > > recently changed their rules page (in mid-November, to be exact) to
> > > outright ban ALL automated following, except -- bizarrely -- follow-
> > > back.
>
> > > This is really silly.  It kills an entire functionality space for all
> > > apps simply because some uses of it are abusive.
>
> > > For example, auto-follow is a hallmark feature of Google Buzz.  It was
> > > loudly included in all press mentions of this product.  Namely, in
> > > that app, you auto-follow anyone you frequently email with.  (Google
> > > has apparently curtailed this feature due to privacy concerns.)  So
> > > what about a similar Twitter app that offers this perfectly reasonable
> > > feature -- namely, auto-follow anyone that you @tweet more than, say,
> > > 10 times.  Will that be banned?  Apparently.  (And there goes the
> > > whole CRM market with it!)  Or what about an app that unfollows anyone
> > > who tweets spam or swear words?  Nope, such an app is apparently
> > > outlawed.
>
> > > Twitter should err on the side of allowing developers the freedom to
> > > build great apps.  This should mean hand-holding even the smallest app
> > > (not just the biggies).  But, more than that, it should mean offering
> > > flexibility and good faith when it comes to deciding what's an
> > > appropriate use of the Twitter API.  Blanket, mid-stream, and
> > > developer-focused restrictions are non-constructive, unfair, and will
> > > stifle innovation.
>
> > > Many of us support our families with Twitter development; and it is
> > > cavalier and bruising to know that developers are apparently not
> > > offered at least some level of back-and-forth communication, good
> > > faith, and case-by-case leeway when their apps are examined in
> > > relation to Twitter rules.
>
> > > On Feb 15, 3:36 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
>
> > > > I apologize for my choice of words.
>
> > > > Now, can we get back to discussing Twitter using OAuth as a mechanism
> > > > to heavy-handedly suspend applications as witnessed by the two recent
> > > > cases we know of, while measuring the guilt of the application against
> > > > nebulous rules that nobody knows exactly what they mean?
>
> > > > Please.
>
> > > > On Feb 15, 7:17 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
>
> > > > > > Oh for crying out loud, is everyone now going to stare themselves
> > > > > > blind at the phrase "Gestapo-like" and forget about the issue at 
> > > > > > hand?
> > > > > > It is meant to portray a one-sided action where the accused party is
> > > > > > not afforded a voice, or his/her objections, rationale, or
> > > > > > explanations are ignored.
>
> > > > > Then say that instead of throwing bombs. Don't tell me you used the 
> > > > > term
> > > > > in order to provoke absolutely *no* reaction at all.
>
> > > > > --
> > > > > ------------------------------------ 
> > > > > personal:http://www.cameronkaiser.com/--
> > > > >   Cameron Kaiser * Floodgap Systems 
> > > > > *www.floodgap.com*ckai...@floodgap.com
> > > > > -- This manual has been carefully for errors to make sure correct. -- 
> > > > > classiccmp

Reply via email to