A quick note: your spreadsheet had better support arbitrary-precision currency math, if it doesn't already. That's table stakes for a spreadsheet.
To answer your real question, I'd suggest doubling down on the sqlite side and taking things in a relational direction. Spreadsheets are good at tracking 1:1 or 1:many relationships, but my spreadsheets inevitably grow in a many:many direction and I find myself wishing for queries and junction tables.
All major spreadsheets use double-precision floating-point throughout. I'm not sure where you got the impression they "support arbitrary-precision currency math".
In fact they even typically truncate or round the last few bits.
I would pay you $400 for this tool without hesitation. I would also pay for upgrades. However, the $400/yr subscription model is a deal killer. This is fine if you're targeting business users only, but it puts the tool out of reach for all but the most determined individuals.
You might want to consider the pricing model used for many digital audio workstations -- a perpetual license for a few hundred dollars, with free patches until the next major version. Then the next major version also costs a few hundred dollars. Rinse and repeat.
This gives you a solid income stream, without ripping your software out of the hands of a customer the instant they're short on cash. It also means the program could work without an internet connection or other constant DRM/activation nonsense. This will likely matter for the technical audience you're targeting.
I feel this way too. I was excited, as a beta user, to see this go GA but then I saw the pricing and was forced to move on. Pretty steep indeed. But he has a great piece of software here. Best of luck Eirik!
Looks nice, but the pricing is steep, and the subscription model has drawbacks as other commenters have mentioned.
Perhaps consider a limited free version, say 1000 rows and 10 tables as a limit.
The positive side of this is that it will put it in the hands of many people, most of whom wouldn't have bought it anyway. This lets you get more feedback and find more bugs. A fraction of them will like it and tell their boss to buy the paid version. Do not provide support to free users, it will eat your time.
I always thought of relational databases as a tool for businesses; normally we don't need them as individuals--except perhaps when planning a wedding! Thus the pricing is targeted for businesses and people who get reimbursed by their employers. A second group might be contractors who purchase their own tools.
There might be ways to make a separate tier for private or occasional use, though. And recurring vs. perpetual might be a separate question from the actual total expected cost.
It's a very different conversation when an engineer goes to their manager and says "I think this tool I tried out at home could improve our work" versus "we should buy everyone licenses for this tool that I've never used".
Should you be interested in doing so, my suggestion would be to offer an "offline" version. It could be feature-limited as follows:
1. Do not include the planned online collaboration features.
2. Support only Excel, Access, CSV/TSV, and Sqlite data sources.
Charge a fair one-time license fee for this, and you would create an attractive tier for individual power-users, without cannibalizing subscription sales of the "online version" for businesses and contractors who care about collaboration and interacting with large production databases.
I am trying a similar pricing model for my product.
Something like $399 perpetual license + 1 year free updates/support, and then optional around $99/year. Being self-hosted, you can always keep using it, but to make the company sustainable, it's not wise to promise free lifetime updates.
These subscription models are straight up scam if a webservice is not essential for its working and also then it must be resonably priced. I pay for MS Office + OneDrive probably 7€/month. So how does this shit add up?
> Important for these COVID-19-related findings was the lack of informal communication that the project team suffered in the absence of face-to-face interactions. In the past, JPL's success typically relied on senior members of projects and technical line organizations "walking the floor", dropping in for conversations at office doorways, or chatting in the cafeteria. Without these informal communication mechanisms, contextual clues and situational awareness were lost. Team members working the floor found it difficult to report problems up the chain over Webex, especially when attendees kept their cameras off."
> ... The lockdown conditions contributed significantly to the question of why Psyche and JPL leadership did not know of the severity of the problems with GNC and V&V until it was too late to correct course.
> ... The IRB recommends that, given these exceptional circumstances, the team should minimize remote work conditions.
JPL has been suffering a brain drain over the last few years, and it sounds like the remaining cadre of managers are not so competent. Remote work is a convenient scapegoat, but it is far more likely that the problem is an ossified chain of command and a lackluster set of communication tools (Webex, shudder).
I worked at NASA JSC for three years in the ISS cargo division; although I never interacted with the JPL teams, I did coordinate with a ton of people across SpaceX, Northop-Grumman, JAXA, ESA, Boeing, etc.
I simply cannot explain the level of organizational dysfunction in that institution. In many cases there were thoughtful and talented people in the job roles, but there were many blinding, glaring failures of basic information storage and availability across the entire org. My favorite example is having a hard time finding all of the requested cargo transactions for resupply flights in the cargo database because the "desired flight" field was a free-text entry instead of a drop-down menu connected to a central list of NASA flight title strings. I hammered on that issue for fifteen months straight and got absolutely nowhere with it, and I had a list of similar issues about seventy items long. If all of my issues had been addressed we probably could have reduced the number of people in the loop in cargo logistics by half.
The article is talking about leadership "walking the floor"--we had something similar happen, where I couldn't convince any of the major ISS divisions to fix their cargo data so we didn't have to interact face-to-face, but their higher-ups would call and email me to double check the status of a cargo request. They were "walking the floor" and "staying in touch", but only because they wouldn't (or couldn't) adopt any policies to make a streamlined system work. I don't know if the same thing is happening at JPL, but I have to assume that it is, given the pathological nature of the repeated communication failures I saw.
A well-organized institution should be able to provide clear visibility into their data and projects just through smart organization of their digital assets. If they don't have that basic competence, then they would be extra screwed by remote work.
For the past decade I've worked for a company whose headquarters is 500 miles away. I have 3-6 video meetings a day with engineers at the headquarters (as well as all over the world).
Until the pandemic, I visited headquarters every few months to catch up with the teams. I found that in informal chats (in the halls, walking into someone's office, having lunch) I discovered so much that never came up during video calls. It's similar to, but worse than, formal in-person meetings with agendas; there's an activation energy people need to overcome to bring up something that may seem small but is actually critical to the project.
Someone in a video meetings with their camera off is even worse; you have almost no emotional connection with them, and it's natural for them to only "speak if spoken to".
It's the best thing bosses have going for them in terms of scapegoats.
Although you can't blame them for being uncomfortable with this level of change. Remote work mainstreaming, without the COVID excuse anymore, is a whole new experiment being tried for the first time widely in society.
This is a wonderful tool and goes a long way to scratch the "library itch" I've felt since the start of the pandemic. Projects like this make me very happy that I donated to IA this year, and I'd encourage anyone else who likes them to do the same.
One question: are there any plans to sort fiction by author, similar to what is done in real libraries? A lot of fiction is already available in this tool, filed under DDN 8xx, but the groupings are pretty broad.
This is a great idea. One of the reasons Open Library Explorer is possible is we have a healthy amount of Dewey + Library of Congress classification data for our books. As you notes, Dewey has Literature 8xx. Library Explorer also supports Library of Congress (you can go to the settings cog and change the classification system).
Some classifications (LCCN) are better at encodind Author data and we also have a significant amount of author data in Open Library (we'd just need to integrate it more meaningfully in our search index).
Given our small team size, not sure we'll have the bandwidth to prioritize any time soon, but contributions are also welcome from the community and we (the community) meet every Tuesday @ 11:30am to discuss and unblock together.
The main difference seems to be that Orgzly is a native Android app, while Organice is a (self-hosted) web service that happens to render nicely in a mobile browser.
I didn't to run a a whole separate server just so I could edit my org-mode files from a phone, so I like Orgzly better. But YMMV.
Lately I am trying to migrate to just running the native emacs on my phone with Termux :>
You're right that Orgzly is a native app, but you're spot on in that organice just happens to render nicely in a mobile browser. You also don't have to run a 'whole separate server' to use it.
Came here to say this! This program would be even cooler if it supported the dict protocol in addition to scraping OED.
The dict protocol and CLI tool [1] were invented to solve the exact problem of browsing dictionaries without a bloaty web browser. You may wish to check them out.
On debian, sudo apt-get install dict, and you're off and running.
The most popular dict server may also be queried via a web UI [2] if you'd like to try it out before installing any software. It queries a few public-domain dictionaries, WordNet, plus some fun stuff like the Jargon File.
This being an open standard, you may also run your own dict server if you wish. It's pretty cool. dict has become a vital part of my CLI workflow since I discovered it many years ago. Its only downside is that it's blocked by some corporate firewalls =(
Thanks for the feedback! I will definitely check them out. The problem you pointed out (firing up a bloaty browser) is exactly the problem I am facing, hence the birth of Vocab. I am not a native speaker, so one of my goals is also to add some supporting features to help people learn English.
IMO the article overstates the danger of cubesats. If deployed to a low orbit (~ISS height) they deorbit in months due to atmospheric drag. You don't really run into the problems described in the WaPo article until you start putting them into higher orbits where they will last longer.
Here is a more detailed article describing the cubesat problem and potential mitigations.
A quick note: your spreadsheet had better support arbitrary-precision currency math, if it doesn't already. That's table stakes for a spreadsheet.
To answer your real question, I'd suggest doubling down on the sqlite side and taking things in a relational direction. Spreadsheets are good at tracking 1:1 or 1:many relationships, but my spreadsheets inevitably grow in a many:many direction and I find myself wishing for queries and junction tables.