I feel like he has no intention of implementing this. It's all just justification for it to not hit up against an regulatory objections to combining the companies.
We currently support Stripe, Braintree, WePay and Zendesk. PayPal & Help Scout are in the works! We've got several paying customers onboard already through organic channels :)
Twitter recently stopped apps from offering any kind of bulk management services for Twitter accounts. We completely support Twitter trying to stop spam, but this action does nothing of the kind. Here's my full thoughts; http://blog.manageflitter.com/twitter-drowning-spam-why-thei...
Anyway the point of this service us just to point out how ridiculous the restrictions are. We will really be delivering it, however - the economics work. We're just finalising how we'll prove it's real people, most likely with a live stream going at all times.
We use Braintree, but it's a payment gateway in Australia not a full stack solution. You still need to provide your own merchant and account and deal with the endless hassles that come with it. Merchant accounts are really the hard part of accepting money in Australia at this point.
That's great advice, thanks! Hadn't thought about how it improves the ability of the vast majority of developers to get up to speed with handling edge cases. That's a really good point. Perhaps I'll start with thin wrappers and progressively add deeper bindings to get the best of both worlds.
This is a great post. I'm currently building an API that's really inspired by Stripe's API. I'm trying to mimic a lot of these elements, from the easy authentication through to the really useful error messages.
One of the things I'm not so sure about is the local bindings for each language. I'm tempted to just use off-the-shelf HTTP clients or a very thin wrapper in each language and write code snippets based on them. I'm not sure I see the value in writing full client bindings - I've often found it harder to use in many cases when I use these 'opinionated' bindings in the past. You often end up with a choice of entirely following the libraries views on error handling or digging around and breaking upgrades by modifying these libraries directly. I've always preferred much thinner wrappers that have no knowledge of the underlying API calls. Would love more opinions!
I used to use Fusion on my mid-2010 MacBook Pro and found it pretty much unusable as it was so slow. However I recently installed Parallels on my Rentina MacBook and I've been amazed at the difference. It can run 3 different OSs at once on top of OsX with barely a performance hit. It makes debugging in IE finally practical. Probably the single biggest benefit for me for upgrading my MacBook.
I think it's a great idea that will fail in this implementation.
The first barrier in social networks is people - getting enough people on your network to incentivize others to follow. Is the fact that app.net paid enough to draw people away from Twitter & Facebook? As a developer, perhaps, but as a user, I really doubt it.
A much better sales pitch would be just "you own your data". Give users amazing import/export tools from the get go. Allow third parties to fork your system and allow seamless user migration. Build a protocol, not a service.
With a business hat on, I also worry about the single silo of data in app.net. Say it does become successful, then they're a monopoly again. How can we be sure they'll fairly charge for their API usage when they realise how much it costs to hosts that much real time data? Can we be sure they won't change the playing field again?
Besides all that, I don't get why he wants $500,000 up front. If he wants to "align our financial incentives with members & developers", I would have thought he'd charge a set fee to allow revenue to scale with usage.
Also the language on the site is just so damn confusing. They have lots of ideas jammed in together. Most of the discussion about the idea has been people trying to figure out what they're on about. They need to figure out a sales pitch people can understand and stick to it.
Anyway, lots of huge holes in this implementation IMO. I doubt it'll even get funded.
It looks like it runs very similarly to our current server management systems, but the web UI is a huge plus.
I agree that open sourcing it to run on your own infrastructure would be a big benefit - people tend to be a bit protective of where they put their root ssh keys :)
Well my point wasn't about what it feels like, but the way the reaction was handled.
I would never send an email that said "You fucking changed my CSS". It happens ALL the time to developers. In fact refactoring, telling each other what you think is wrong in the code and how to fix it is a core part of team software development. Nothing is ever perfect. You can't be that protective of any part of your product.
Eh, I think your co-founder has the wrong attitude here. I edit the copy all the time my co-founder writes. Sometimes I tell him, sometimes I just deploy if I'm in the middle of pushing something out. Building startups is all about iteration. One person sees something from one point of view, the next sees it from another. As each person adds their improvements you get a much better final product - you wouldn't be changing it if you didn't see something wrong with it.
By the same token, I totally accept when the things I've spent hours pouring over get thrown out the door. We recently had a design review where someone said one of the elements I put hours into looked like a 3 year old had drawn it (they didn't know it was done by me, they thought it was outsourced). It was the kind of style I was going for, but that reaction made me realise it totally wasn't suitable for the site. I was a little hurt of-course, made a joke about it and brushed it off. We now have a completely new version of this page that's way better than my original vision.
Wrong response:
“You fucking trimmed my copy.”
“I don’t want to get mad but I sat there for FIVE HOURS crafting that yesterday, there’s a reason for every word.”
Right response:
“I see you changed my copy. What improvements were you trying to make? I felt point x,y,z were important and you left them out. If you were trying to make it shorter, here's a shorter version that includes the more important points.“
I've been working on this one for a while. Did a design myself, then shot it over to 99designs for improvement, then iterated again on the best version to get where we are now.
Feedback, suggestions for improvement are very welcome :)
There's a lot of people over-reacting to this situation.
If you read Twitter's blog post its clear that they're following up on enforcing the API "Rules of the Road" they've had for over a year. https://dev.twitter.com/blog/delivering-consistent-twitter-e...
Section !.5. clearly lays out the rules clients must follow "Your Service may be an application or client that provides major components of a Twitter-like end user experience (a "Client"). An example of a Client is a downloadable application that displays user timelines and allows users to create and search for tweets. If so, certain additional terms apply, including:"
These rules are actually pretty generous and plainly lay out their expectations for third party applications. It's unclear what led to Tweets being removed from LinkedIn, my guess would be that Twitter attempted to enforce their branding rules, LinkedIn declined and instead said they would remove the Tweets from being displayed entirely. It doesn't sound like Twitter just cut off access to LinkedIn or came up with new restrictions they haven't already been publishing (and compelling 3rd parties to comply with) for a long time.
Any business must deal with existential threats, be it from competitors, regulation or bad investments. Building a business on top of an API is just another potential risk, you need to decide if they company in question is a safe enough bet to play on, just like you have to decide the same thing for all other risks.
That seems pretty reasonable to me for a professional freelance design from scratch like that. I normally expect individual pages to cost in the range of $1k from scratch.
Whenever you authenticate an app in Facebook that can post to your feed, there is a drop down that lets you choose who can see your activity with the app. I always choose "just me" because of actions of apps like this. It's become the norm not the exception to auto share.
Facebook should add a clause to their ToS saying apps must actively ask for permission before posting. Twitter has done this and while there are a few bad smaller players, on the whole you don't see most apps using these spammy techniques.