Marc ensured the market expanded with his wise bet. I doubt he has any regrets. Who knows whether Instagram would have expanded unless they were motivated to get to a point of turning their backs on A16Z. $ talks.
> If you've been friends for a year that's probably enough
thanks. is there any reason it is not now time to add this point of data to the application. definitely a question i as well as many others have wasted thought cycles pondering. though i do like the privilege of having access to this information.
Haha, I appreciate the sentiment. And yeah, Amazon's marketplace is pretty exciting for us as well - their approach is obviously quite different, but it's very cool to see movement like this higher up on the stack.
if anyone wants to port the Ruby script to python, put it on kickstarter and ill start u off with $50. i want a link to my webpage, CompassionPit, on the page for the final tool though. and one on the kickstarter page if ur feeling generous =)
p.s. anyone think we need a developer-tools kickstarter? paul, lmk before i give it to my friends at tech stars
A Kickstarter for dev tools would be a great idea. As well as new projects, it could also be beneficial for large changes to existing projects. Some combination of Kickstarter and bounties for GitHub issues would be interesting.
My only concern would be for the potential drama caused by members of the community who find the idea of paying for open-source development abhorrent.
Why does the script need to be in Python? Isn't Fake S3 just a server that you run and connect to from any codebase? I'm curious because Python is the language I use most, but I could easily see myself writing a Fake S3 in golang or clojure or even C.
I think I'm not being explicit enough. What would you use a Python version for, for which the Ruby Fake S3 implementation isn't suitable? I'm purely looking for a sample use case here. What problem does a Python Fake S3 solve?
No. Prettier != better, as one other commentator pointed out. I think there were many things that Kyro did better than the current design, but his design wasn't something I'd be comfortable putting on the site in it's current form.
To address some of the points in the other thread: Yes, the current Exec design looks like something that was done by a non-designer in an hour. That's because it was, by me, the night before we launched. And I'm comfortable with how it works; when we have a full time designer in house they will iterate it based on achieving specific goals.
I don't believe in changing design for the sake of changing design or just having something prettier. I believe in design that achieves specific goals and functions, and that defining those goals and functions are actually the most important parts of the design process. Because of that, I do not believe that it is possible for us to use an outside design without first coming up with new goals for the front page. I don't want to invest my own time in doing that right now, because my time is extremely valuable and I don't think our crappy front page is our current bottle neck on Exec (actually, I know it isn't). So, any effort we made in improving it at the moment would wasted. So, I'm not changing it.
Yeah, there's a side project I've been wanting to build for a long time, and it needs search. But the way these prices have been presented, it seems that CloudSearch is just not economically feasible for a SaaS / free multiuser offering.
We think our prices actually compare pretty well to self-hosting. Hosting a search engine is not cheap when it comes to memory and disk IO, and I don't envy anyone trying to shoehorn production Solr traffic into a small VPS.
Not to mention, we've got transparent replicated redundancy on all our indexes—one of our better-kept secrets, I really need to update our marketing materials—so double your VPSs there.