A more sustainable business model would be, I think, the safe middle-ground for both the consumer and the developer-- the Atlassian model. Offer an absurdly cheap .jar/.dmg/.exe out of the box which you can run locally for the end-user/small-business (what is it like a dollar a user a year for the self-hosted binaries?) and limit it to 5 or 10 seats. If the acquire-hire-kill by GoogAplTwitSquare happens, you still have a local copy of your data and the ability to migrate off the platform. If >(5||10) employees are using the application as a critical component of your business, making the seat-fee price-jump at that point is worth it (value provided > cost of seats, even at a few hundred dollars a month).
I'm hoping that sandstorm or another hosting provider that makes a business out of reselling open source anyway can try out one or more models where a fraction of the revenue is fed back to the creators / the community to encourage more development.
Don't know if it would work but I can hope.
Hopefully most should see some value in getting their software in the hands of more users while also getting a little money without doing anything extra.
I've started building a prototype of this idea using PouchDB/CouchDB (data is stored locally in PouchDB, synced to your own CouchDB server or Cloudant). As with most of my side projects, it remains abandoned waiting for some love.
I'm the CTO of Fieldbook, we're really proud of what we've built here. In particular, I really like our API explorer that allows you to run real node code right in the browser to explore our API. (And see our realtime updates in action on the same page). That feature is powered by Tonic (https://tonicdev.com)
Its mad fast to setup a database with a REST api with Fieldbook, and we'd love to hear what you think / what could be better / etc.
* Create a template book for yourself
* For each client, make a copy for them and share it with them so they can edit it in Fieldbook
* Read from each book via the API for the live app
It's not whitelabel, but it would give you an independent database (book) for each client, they would each have their own login credentials (to Fieldbook), and you would have access to each (in the UI and in the API).
I deal with large enterprises primarily and I've been looking for a nice relational backend for Excel for years.
So breaking out the roles of a consumer vs. a creator, I would like end users to consume without knowing that there is a different backend to the Excel sheet they are using while still freeing up the creator to do what is needed on the backend.
For example, we have extremely complex pricing spreadsheets that we use to estimate projects, it would be fantastic to be able to collate and manipulate data on the backend as well as data sources while being able to tell an end user to keep using Excel as the front end as before.
Maybe this is a fit, maybe it isn't but any insight/feedback would be welcome. Thanks.
The spreadsheet isn't ideal as the primary UI for a number of reasons. That's why we built our own UI, inspired by spreadsheets but fundamentally breaking from the model to be more like a relational database.
But a spreadsheet connection could be great for reporting, modeling scenarios, etc. – basically, all the things that spreadsheets are actually good for.
Might be worth having a chat with him.
I should add that I was once a Product Manager for core database at Oracle. We had constant requests for an Excel front-end to Oracle. I don't know if we had any major customers who didn't ask for a spreadsheet front-end at some point. But we were busy making money on other things, and it just wasn't a priority (though consulting routinely built hooks.) So I think that this has the potential to be a huge product - especially if it can leverage new technology in ways which Excel can't. Don't let Excel and Microsoft drag this product down.
More info here - https://sheetsu.com/docs/beta
 SQL Server Express + the Express version of the Business Intelligence Suite was free for production use up to 4 GB and 2(?) processors [things might have changed since then, SQL Server 2008]. A few hundred lines of SP's to dump stale data out and the client was golden.
In some situations [such as a cascade delete], the business requirements need the Stakeholder or PM or TL or whomever to authorize certain events due to internal corporate governance policies. At that point, the VSTO add-in route is taken because usually there has to be integration with other governance/workflow software (one of the subsidiaries for Blue Cross/Blue Shield I worked with was notoriously bad re: pushing the buck and over-complicating workflows). Anyways, the MSVS sln I use with that is pretty much the opposite of a VBA pile.
 There's almost never any destructive DELETE's taken, rather a boolean active flag is toggled, and a new row is inserted with a more recent timestamp so you can '...order by timestamp desc limit 1'. That way if auditors come in, not only do they have the full audit log but we can reconstruct state at any given time.
Either way, a naive VBA implementation that doesn't appeal to system tables for all the schema info can easily be written (in a maintainable fashion, as maintainable as VBA goes at least) in under a week.
This is the most detailed explanation I found regarding the VBA method: http://www.toadworld.com/platforms/sql-server/w/wiki/10392.e...
And the company you linked originally gives away a generic VSTO add-in: https://www.ablebits.com/excel-addins.php#sql-server
The part I was missing was when you said 'audit tables [and] audit trails' (etc.)... it sounds like this would all be build-it-yourself.
Apparently so far he thinks that data structure you have in your app is most approachable for non-programmers:
I can imagine using this as a way to get users to build simple prototypes. They can chuck data at it for a few weeks, then hand the data off to developers to build a first cut of a web app. If said developers could easily click a button and get a gzipped SQL file compatible with, say, Postgres, that'd be a really useful feature.
We don't handle image uploads yet. Definitely something we want to support in the future. Of course, you can put urls in the cells and build things that way... Definitely something we want to improve in the future :)
We don't scale as far as we want to right now. For a good experience, we're limited to about 10k rows in a book. Definitely something we want to improve a LOT in the future.
More info here:
I think we've focused a lot more on relational support. For instance, on a detail page, you can view and edit all linked records, and add new ones inline: http://docs.fieldbook.com/docs/go-beyond-the-grid
We have a full-fledged query UI: http://docs.fieldbook.com/docs/focus-on-relevant-items
And we have a grouped view (think Trello meets spreadsheets), which is great for any kind of pipeline/kanban view: http://docs.fieldbook.com/docs/track-a-workflow
I know it's extremely important to strike the balance of complexity, capability and UX so this area is notoriously difficult to tread but I think whatever solution does it right without sacrificing customization extensibility is going to win big!
Fieldbook looks great and I hope it keeps getting better!
The spreadsheet model is fairly intuitive for the end-user. He and Rich Hickey both are pretty convinced that a Datalog-esque query engine is the way to go. 20 years ago, Lotus' Improv's model (where you separated the data manipulation from the data type constraints) was way ahead of its time and guaranteed so much more internal/referential integrity than 1-2-3. Modern-day Quantrix is probably the closest you'll get to it, used pretty heavily in niche finance.
MSR puts out some interesting work on the PLT behind alternate spreadsheet grammars which are quite interesting too. Other than the obvious issues (ETL, ACLs/RBAC, presentation/extensibility) MSR has put out quite a few interesting papers out there. This is a very interesting problem domain to say the least. I've developed up-to-the-Pareto-point for this in the past for clients and if you get it right, it's a license to print money.
[both conventional a la SSIS and Informatica, as well as a Pipes-esque query; a premium feature you could easily charge into-the-Oracle-rates would be a Pipes-esque service with an SLA. I've been in enterprise consulting long enough to know that whether you're Ingersoll Rand, Haas, an REIT or Cravath, sanitized, guaranteed data is worth a lot, integration is worth even more.
Last time I researched this category, the best options I could find were MS Access and FileMaker Pro. I'm often annoyed with overly use-case-specific apps, as they do not have good flexibility in interacting with the data they use. It seems like many use-case-specific apps would be better suited as templates in a generic database UI tool.
Chris Granger's Eve is also tackling the database UI problem, and they are investigating wider-scoped UI patterns, beyond spreadsheets.
It's a great product I'm going to use more. Big fan - there have been several side projects where I've wanted to use Google Sheets as a prototype DB - with the simpler API and better relationship model, I'm going to use Fieldbook from now on.
I understand being leary of business model changes. While we can't make any guarantees in the wild world of startups, we can say that we want a free tier to remain forever, and would give plenty of warning if it were ever to change. A little more information available here: http://docs.fieldbook.com/docs/security-and-privacy
We don't currently have any short term plans for a self-hosted version.
How does it handle data types? Can you put any type of data into any cell? If I want a column that is numbers is there anything that stops a user adding a string to one of the cells by mistake?
Longer-term we might offer more fine-grained locking or permissions control.
Obviously, using the API you could build a restricted interface on top of fieldbook, but that probably isn't what your looking for, I understand :).
We're also considering doing a mode where you can't change any of the metadata (sheets/fields) but can add/remove/change rows.
Maybe display an error if I name 2 columns the same? Or disambiguate somehow in the JSON?
One of the key advantages of Fieldbook is actual relational support. You can create a relational model by “linking” sheets, and then linked records are returned by the API.
Also, the Fieldbook UI is more suited to being used as a database than spreadsheets are. It's much easier to do queries, for instance, and sorting/filtering won't mess up your book.
Lots more on Fieldbook vs. spreadsheets here: http://docs.fieldbook.com/docs/what-is-fieldbook
I had high hopes for DabbleDB before Twitter bought them and shut it all down.
TrackVia is another interesting alternative, they started as an Excel replacement (and very good one at that), but have since gone more towards mobile and simplicity in the new version.
Knack is in the conversation as well, but it seems like Fieldbook & AirTable are now the ones to watch.
(Sadly went nowhere and subsumed by Twitter.)
I think our UI for creating links (relations) and for doing queries is unique, both were developed through hundreds of usability tests to be both accessible for novices and satisfying for power users. Check it out.
Can you share which frameworks you used ?
Did you use a template for the front page ?
Not much of a framework on the front end, but we do take advantage of Bootstrap and Backbone.
What are some real world use case for using fieldbook?
Here is a story of Data Analysis tracking sales leads: https://medium.com/@fieldbook/data-analysis-tracks-sales-lea...
And here is one about how Continuum Analytics uses us to track their professional service work:
Also check out our templates for more examples: https://fieldbook.com/templates
Because of what happened with DabbleDB, I worry about these awesome startups getting acquired. Again, great for the founders, but not for customers.
Doesn't sound too far off from Kinvey and Parse except for the fact that MBaaS services have been around a lot longer and have much more robust mobile and web SDKs.
The use cases people have been most excited about need both. For instance, set up a configuration database or CMS for your app--an engineer can create the schema and read via the API, then anyone on the team can view and edit the configuration.
With the BaaS offerings I've seen, you get the database and API, but you have to build any UI you want yourself, including any web or admin UI.
Not true, you get a spreadsheet data grid like UI out of the box.
They are more general purpose - that is true.