#dickbar, the API/client controversy, and shutting down DabbleDB. Not sure if I've seen one company burn through as much goodwill in one week as Twitter just did.
The Dabble people themselves practically announced that they'd be doing this a year ago. They said they'd give notice. They gave notice. What do you want from them?
Exactly, you haven't even been able to make a new database for a year now and it takes about 30 seconds to export your data to excel. I really don't see what the big deal is here.
I get the feeling that dabble DB never truly solved the "excel being used as database" problem and that is why they didn't last.
I still think spreadsheets work really well for storing data (if you don't have time/money to imnplement a RDMS), plus now with google docs and dropbox there are enough ways to sync the data with other users.
EditGrid is still around and free and unlike Google Spreadsheet's broken importXML function (see: http://goo.gl/fWYDi) it has a web_xpath function that mostly works.
But possibly bad for the community in that it pretty much removes the possibility of getting bought by a company that wants your talent/customer base more than they want your product.
Yeah I agree with that previous comment (that I can't reply to for some reason).
I was talking with a potential client this morning about how he used to us Drop.io and built some systems based on it in lieu of the API calls he needed then Facebook acquired them.
It may be the case that the Facebook purchase in this case was about more than talent, but if every startup is only buying time until their big exit a general distrust amongst users may be the result.
Or you do both GPL and hosting offer at the same time. This what we are doing for Indefero and this is working very well. In fact, we secured some big companies because of the ability to easily move in/out of the hosted offer from/to a company installation.
The cost of entry on the market for a SaaS application is so low now, that companies start to ask more and more such kind of insurance.
For some other services, code in escrow could also be a good idea, but when not open sourced from the start, closed source code is often hard to bring back to life as an open source project. Sometimes it works well, for example with Blender.
The choice to shut it down and bury the tech seems a weird route to take by Twitter. What could possibly be the upside if they were only interested in the talent anyway?!
31 comments
[ 2.6 ms ] story [ 59.0 ms ] threadI still think spreadsheets work really well for storing data (if you don't have time/money to imnplement a RDMS), plus now with google docs and dropbox there are enough ways to sync the data with other users.
Also worth noting DabbleDB is one of the (few?) relatively well-known projects implemented in Squeak/Seaside as discussed here: http://www.jarober.com/blog/blogView?showComments=true&t...
Unless they're just removing a competitor, but if that's the case they could always violate the custom.
I was talking with a potential client this morning about how he used to us Drop.io and built some systems based on it in lieu of the API calls he needed then Facebook acquired them.
It may be the case that the Facebook purchase in this case was about more than talent, but if every startup is only buying time until their big exit a general distrust amongst users may be the result.
The cost of entry on the market for a SaaS application is so low now, that companies start to ask more and more such kind of insurance.
For some other services, code in escrow could also be a good idea, but when not open sourced from the start, closed source code is often hard to bring back to life as an open source project. Sometimes it works well, for example with Blender.
Indefero is a code hosting/project management software: http://www.indefero.net
I've also emailed that support@ email address but not sure if that's just for customers or what ...
I last used WizeHive which was ok-ish