3 ms·
There are definitely some challenges with getting people to pay for OSS, but I wouldn't be so quick to blame that all on what happened in this situation. I thi
by freedomben 3y ago
There are definitely some challenges with getting people to pay for OSS, but I wouldn't be so quick to blame that all on what happened in this situation. I think you'd be experiencing the same (or worse) if your app was closed source for reasons I'll mention in a minute.
I'm the exact type of person who would be in your target market and likely to pay, but aside from having never heard of your app (which may be your biggest problem), these are the reasons I'm not buying. I'm only sharing this in the hopes that it helps you, not trying to make you feel bad or anything like that. Overall I think you're awesome for making your app open source, and I have a mountain of respect for you for doing that.
1. You're targeting a very crowded and competitive market where top-quality options are 100% free. This would be a huge challenge regardless of whether you're open source or not.
2. Your app is still very young/new. Winning in such a saturated area is going to take some time to even build awareness, let alone get mature/feature complete enough to get people to change.
3. With something like notes, you're looking at people with substantial pre-existing sources. Migration is not trivial either, so there's a big barrier of entry there for people to use your software.
I wish you the best, but I think you'd only be harming yourself by closing your next app. You definitely lose people like me for whom my notes are incredibly important and I won't risk losing them to a proprietary tool. Open is mandatory for me to even consider it.
I'm pretty happy (maybe even in love) with Logseq, but the performance is definitely a downside and the idea of a C++ app is highly appealing to me, so I'm going to give your app a try.
Side note: If your GUI was compatible with logseq's on-disk format, that would make your app quite compelling to me
- rubymamis 3y agoI appreciate your opinion. Notes has been quite a success for me. With over 1,300,000 downloads[1], and being featured in awesome tech websites[2]. Just on Ubuntu alone there are 7000 weekly active users (that have downloaded it from the Ubuntu Store). My new app Plume is going to be a big improvement over Notes. First, your data is and will always be as simple as Markdown/plaintext. My new block editor is based completely on plain text while still offering advance views (with a minimalistic syntax). It's also faster than any other in its category, even faster than native apps on macOS! I'll soon put benchmarks on the website. All I can say is, sign up to get an email update and check it out when it's ready. Most of the features will be free with only some advance features paid. BTW, what do you mean by "logseq's on-disk format"? That it's local-first? If so, Plume is also. [1] https://tooomm.github.io/github-release-stats/?username=nuttyartist&repository=notes https://tooomm.github.io/github-release-stats/?username=nutt... [2] https://www.omgubuntu.co.uk/2022/09/open-source-qt-notes-app-major-update https://www.omgubuntu.co.uk/2022/09/open-source-qt-notes-app...
- freedomben 3y agoWell dang! I didn't realize it was that big. That is impressive and definitely changes my opinion a bit. It's quite unfortunate to have such low paid numbers with that many downloads. By logseq's on-disk format, it is local first but it's a stricter subset of markdown with a handful of extensions. The strictness is because Logseq parses all the markdown into an in-memory graph database, and in order to make that work with markdown the top-level has to be a list and needs some IDs and other identifiers in order to properly link/embed blocks and pages and such.
- rubymamis 3y agoThanks! With Plume I use a tree data structure (just with parent child relationships), although in the future I would probably use Boost::ptree. The things is, the underlying data structure is just plaintext, so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app). But I'll add some special syntax to allow this feature for specialized blocks.
- freedomben 3y ago> so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app). Indeed, this is definitely a problem for Logseq. For example here's some of my recent Logseq notes. This is one page where you can see an "ID" (represented by `id:: <guid>` is created. Then helpful images/diagrams are displayed. This is then referenced later: - Parts of a [[Neuron]] id:: 64f4bdc3-29de-4b6c-bc41-20a5f052badf - Dendrite: https://en.m.wikipedia.org/wiki/Dendrite - {:height 411, :width 718} - Axon: https://en.m.wikipedia.org/wiki/Axon - {:height 471, :width 718} Then in a different page, this is referenced by ID. In this case it is "embedded" but you can also reference and other possibilitie: - #vocabulary [[Brain Myths Exploded]] #Notes - {{embed ((64f4bdc3-29de-4b6c-bc41-20a5f052badf))}} - Encephalization Quotient (not a good measurement)