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> 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> 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 > easier 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 business > 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> 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 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> 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> 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> > > > > > >
