Thank you for the response Doug. I intended the post to be more curious than implicative though it may have sounded more of the latter. In any case, we¹ve all grown to love the openness of the platform, and the platform itself as such a great opportunity to build. I just got nervous when I started thinking about the work we¹ve put in.
Thanks for being communicative about this! On 6/9/09 9:10 PM, "Doug Williams" <d...@twitter.com> wrote: > Obviously I can't address the impact since we don't have a document > to deliver. Let me be clear, we are not thinking of taking functionality from > the offering, but we are discussing how open we want to be moving forward. > Most of the talks are around what we want to offer through the Streaming API > and to whom should those privileges be extended. We are not concentrating our > efforts on whom can we restrict and why? Remember we built this company on > being open and to that we are committed, especially within the API team. We > are very conscious that you developers are a little weary of our plans but > rest assured we want to augment the ecosystem and its abilities rather than > contract our offering. > > Thanks, > Doug > > > > On Tue, Jun 9, 2009 at 6:58 PM, Justyn Howard <justyn.how...@gmail.com> wrote: >> What are the chances that this new TOS will negate any of the hard work we¹ve >> done up until this point? Can you give us an idea of what will be protected? >> It¹s a little alarming to hear that Twitter might decide to reserve >> functionality that the developer network has built-on and enhanced in favor >> of internalizing as business assets. As there has been no TOS in place other >> than the general Twitter TOS, many of us have spent countless hours and $$ >> trying to build businesses around Twitter. >> >> Not trying to be an alarmist, just curious what this will ultimately mean for >> us? >> >> Justyn >> >> >> >> On 6/9/09 8:51 PM, "Doug Williams" <d...@twitter.com >> <http://d...@twitter.com> > wrote: >> >>> The API TOS is currently in development. It is taking longer than hoped as >>> we are still exploring what we want to give to developers and what we want >>> to protect as business assets. For now, make sure that you understand the >>> general TOS we have in place. >>> >>> We do work with developers if they are willing to answer our attempts to >>> reach out before shutting them off due to TOS violations. We also try to >>> understand what developers are doing and how they may be heading against the >>> grain before issuing whitelisting. Most developers are willing to work with >>> us which is great and works out for everyone. >>> >>> Thanks, >>> Doug >>> >>> >>> >>> On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay <jesses...@gmail.com >>> <http://jesses...@gmail.com> > wrote: >>>> Doug, where is the developer API TOS? I think that's part of the problem - >>>> none of us are being required to enter into an agreement before >>>> developing, therefore we have no idea what we can and can't do with it. I >>>> also don't think most of us even know where any such TOS is, if there is >>>> one. I agree that the OAuth application process should make this a bit eas >>>> ier to manage, and help developers know more about what they are getting >>>> into before starting their applications. >>>> >>>> Personally, I want to make sure I'm following the rules of the >>>> API. I'd also prefer to know what I'm agreeing to before starting a busine >>>> ss on top of it. I feel for the developers of the 2 mentioned apps >>>> because, *if* they are violating any TOS, they probably had no idea they >>>> were doing so before spending so much time developing it. (even if I >>>> disagree with the premise of those apps) >>>> >>>> @Jesse >>>> >>>> >>>> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams <d...@twitter.com >>>> <http://d...@twitter.com> > wrote: >>>>> Brant, >>>>> Thank you for your concern. This is something that bothers us as well. >>>>> >>>>> Moving applications exclusively to OAuth-based authentication will >>>>> certainly help in restricting applications that abuse the service. If you >>>>> find a service that you think is violating our TOS, please email >>>>> a...@twitter.com <http://a...@twitter.com> or send a message to >>>>> @twitterapi >>>>> and we can take a look. As you mentioned, Del is great but she is but one >>>>> person. We do have an abuse team forming to help quickly identify which >>>>> services are violating our TOS. All in all we have a lot of work to do so >>>>> please do help where you can. >>>>> >>>>> Cheers, >>>>> Doug >>>>> >>>>> >>>>> On Tue, Jun 9, 2009 at 2:43 PM, Brant <btedes...@gmail.com >>>>> <http://btedes...@gmail.com> > wrote: >>>>>> >>>>>> This message will hopefully get back to the people who run Twitter API >>>>>> development and spam prevention. >>>>>> >>>>>> I noticed there are quite a few twitter applications that are >>>>>> developed to abuse the service and violate their TOS. They do not >>>>>> hide what their purpose is, yet these applications remain active. I >>>>>> contacted twitter.com/delbius <http://twitter.com/delbius> >>>>>> <http://twitter.com/delbius> who heads Twitter Spam prevention and >>>>>> >>>>>> she said that they do revoke API access to abusive applications. But >>>>>> I don't think they are taking an aggressive stance against them. >>>>>> >>>>>> Abusive Applications: >>>>>> http://www.huitter.com/mutuality/ >>>>>> http://www.twollo.com/ >>>>>> >>>>>> The combination of these two applications is for outright abuse of the >>>>>> service. They have been around for several months and are known >>>>>> applications to abuse the service with. To make matters worse, >>>>>> Twitter suspends accounts of the people who use these applications >>>>>> rather than targeting the root of the problem, the applications >>>>>> themselves. (Sound counterproductive? RIAA uses a similar policy by >>>>>> going after end users.) >>>>>> >>>>>> I propose that applications need to be more closely scrutinized and >>>>>> can even be flagged as abusive by users. Instead of creating >>>>>> algorithms that detect abnormal user behavior, why not detect abnormal >>>>>> application behavior. >>>>>> >>>>>> Taking a stronger stance against gray area applications could reduce >>>>>> server load on Twitter (giving real applications faster response time) >>>>>> and reduce manpower to deal with spam prevention. >>>>>> >>>>>> I strongly encourage anyone who develops Twitter applications to send >>>>>> this link around. >>>>>> >>>>>> Thanks for reading, >>>>>> Brant >>>>>> twitter.com/BrantTedeschi <http://twitter.com/BrantTedeschi> >>>>>> <http://twitter.com/BrantTedeschi> >>>>> >>>> >>> >>> > >
