Avi Bryant demos Dabble db

A good example in this space was DabbleDB[1], a low-code environment for producing web apps that did CRUD type stuff. Their original video demo: ▶ this video I was pretty impressed when it came out. The UI was very intuitive, and it did a better job with things like table relations than it's competitors. They were also releasing new features based on requests faster than what I typically saw. It happened to have used the Seaside web framework mentioned in the article. Sadly, Twitter purchased it and shut it down...I assume they just wanted the team and not the product. [1] link

I've tried a lot of these tools. The trouble is that things go extremely well until you hit a wall. With no way to extend them with something like freeform code, the wall doesn't move. The best ones, then, tend to be the ones that have been around long enough, or had enough foresight to have covered various corner cases. The other issue is that most of them have "per user / per month" pricing, which doesn't work for many use cases. Things like, for example, an applicant tracking app. If you use the functionality to a high degree, every job applicant is another end user license. Two of the better ones: link & link Other ones I've seen: link link link link link link link link link One of the more promising ones was DabbleDB. Twitter acquihired them and shut the tool down. It had a very smooth UI: ▶ this video

Center of Complex Interventions | First Frontend Engineer | Remote (forever) | Full Time | Open Source We're looking for our first frontend engineer to help build a brand new open source product that helps users of all skill levels store, manipulate, get insights from, and collaborate with others on their data. We are heavily inspired by Dabble DB (▶ this video). Our team is based out of the nonprofit Center of Complex Interventions and we are advised by Joi Ito and Reid Hoffman. In addition to great technical skills, we are looking for someone who is an excellent communicator, proactive, product-minded, excited about making somthing new from scratch (with all the collaboration and iteration that entails) and interested in building an open source community around a product. Full job description: link Apply here: link Feel free to email me at kriti<at>centerofci<dot>org if you have any questions. Mention that you saw the HN post.

Center of Complex Interventions | Frontend Engineer, Product Designer | REMOTE | Full Time We're looking for our first frontend engineer and product designer to help build a brand new open source product that helps users of all skill levels use, extend, and visualize their data. We are heavily inspired by Dabble DB (▶ this video). The current team is two engineers, we're alumni of Creative Commons and have experience working on open source projects and building community. We're aiming for an initial team size of four. We're based out of the nonprofit Center of Complex Interventions and are advised by Joi Ito and Reid Hoffman. Full job descriptions and application instructions: Frontend Engineer: link Product Designer: link Feel free to email me at kriti<at>centerofci<dot>org if you have any questions. Mention that you saw the HN post.

I've thought a bit about this, churning around various product ideas. In general I'd say that if it's a typical SaaS, I would probably only trust it with my data, my time (learning curve, adapting workflow etc) if it was a available under a licence that would allow me to self-host it if it was discontinued (or pay someone else to host it for me). This is for stuff like mail, images and other DAM (Digital Asset Management) systems, chat/im, bug trackers/knowledgestores and databases etc. Note, that I don't see any reason to trust Google either. Remember wave? Remember XMPP compatible gtalk? My conclusion has been that if/when I finally get started on my first product, I'll probably license it under AGPL, and make sure there's a realistic self-host story for users -- and then charge for the SaaS/PaaS-bit, but probably not for the client (or server side software under AGPL). Clearly it's a little more challenging -- you might end up with people competing with you for hosting -- but I can't see any other way to build customer trust. Nothing any company would say to me as a customer would make me trust them -- how could I ask anything else from my potential users? Since people still pay for hosted email (even if many, many do run off to freemium services) -- I'd say the business model is viable -- those that can afford to pay, and know that value can be added by proper hosting -- and not having to do everything themselves -- will consider becoming a customer. And I strongly suspect those kind of customers are the best kind of customers. Especially for a start-up. Even though I wasn't a user, the most dreadful death-by-buyout I remember is DabbleDB[1] -- compounded by the fact that the founders went to twitter -- presumably helping with the biggest non-product of our decade -- rather than allowing dabbledb to live on in any form. Also note that having a published API/open protocol/standard isn't enough. For example, the IMAP standard clearly states that message ids aren't necessarily in chronological order. Some IMAP servers make sure that they are and/or that messages are returned in a list ordered by (message) time -- and some will return the message that was latest modified first (eg: a messaged moved into a folder). Some IMAP clients get this right (sort as the user wanted, regardless of server implementation) -- some get it wrong. A small difference (arguably client bug) that can make or break certain use cases and processes for dealing with email. For a b2b setting -- one could reasonably offer source under a different license -- if AGPL seems too open for enforcing whatever business model one has decided on. But I suspect that AGPL would work fine in b2b settings as well. The key aspect is to offer source code and documentation in a form that offers a viable self-help scenario in the case of a bankruptcy or "death-by-acquisition". [1] ▶ this video