I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often.
I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management instead of doing it in the frameworks and programming languages themselves (which are what you are asking people to write apps in).
The Linux enthusiast community actively fights against anything like this because they want everything to be modular and made to fit specific applications.
Linux does have a de facto set of standards, they're not quite as stable because they change them and deprecate old stuff, but it's better than it looks, and with Snaps you can at least partially solve the issue.
But people choose distros that don't have those standards, and then you lose half your potential users if you don't support all the niche configurations.
The so-called "Linux enthusiast community" is better described as the Linux corporate enterprise community. Understanding this makes your comment make a lot more sense. The "specific applications" are in fact merely the priorities of the giant corporations who fund the overwhelming majority of Linux development for the purpose of accumulating profit.
>Win32 (via Wine or Proton) is the most stable target for Linux right now
Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass.
Pretty wild that the same thing is not the norm in other OSs.
Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point.
That core would be GNOME or KDE frameworks, coupled with the FreeDesktop standards, at least that was the plan about 20 years ago.
However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions.
In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and naturally those are the winning Linux distributions for regular consumers.
You are talking about Android and Chrome OS right?
I agree, those are the top two Linux distributions, and everything else is behind by an absolutely huge margin
Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their binaries have version names requiring at least a glibc 2.36 (often, rarely not). They have to force the right version names with... the binutils gas symver directive (see binutils manual) until all their version names are compatible with a glibc reasonably "old" (I would go for a reasonable 5 years... 7/8 years?):
Of course normal game devs have not the slightest idea of those issues, and even so, they won't do it because it is a pain, that for 1% of their market. Not to mention they better statically link libgcc (and libstdc++ if they use c++) to avoid the ABI issues of those abominations (the word is fair) which have been plagging game binaries for TEN F.... YEARS ! (getting better has more and more game binaries default to -static-libgcc and -static-libstdc++, if c++, gcc/clang options).
There is light at the end of the tunnel though as godot engine is providing build containers which are very careful of all that (unity seems clean there too, dunno for UT5.x though).
But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run. And packaging properly a full google blink engine for binary distribution targetting a wide spectum of elf/linux distros? Yeah... good luck with that.
elf/linux is hostile to anything binary only, that due to manic ABI breakage all over the board, all the time (accute in the SDK and core libs).
If it is already that hard for game binaries, good luck with apps. I can hear already their devs saying: "we don't care, just use and install microsoft suze gnu/linux, every else is unsupported"... I think you get the picture where all that is going.
I agree. I recall a talk from Linux Torvalds on how bad the glibc folks break things and why he won't ship a binary version of his scuba tool. If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel.
If they're going to put the game on Steam then they should be using the Steam Runtime which is available here[1]. Otherwise they're shooting themselves in the foot.
> If it is already that hard for game binaries, good luck with apps.
Video games are some of the most complex and most difficult pieces of software both to build and to get right. Modern games are coded so poorly that driver makers have to release patches for specific games.
It's the gamedev world that can't get its shit together. Valve settled on an Arch-based distro for the Deck. The specific distro doesn't matter since Steam already establishes its system requirements and comes with a runtime.
Beyond that, I really don't see the issues you're talking about. Generally, any issues you have are fixed by symlinking the correct .so files. This is a side effect of targeting a specific version of software instead of keeping to its more base features. That's on the dev, not the user or distro.
You act like Windows has never had ABI breakage or versioning problems. I'd like to see the specific issues you ran into; maybe there's an easy fix like a symlink.
> But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run.
Hm, not sure what you mean here.
At least with the nw.js toolkit (from which Electron was forked IIRC) I've never gotten a report of a distro where it would refuse to run because of an incompatible GTK version.
> Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their binaries have version names requiring at least a glibc 2.36 (often, rarely not). They have to force the right version names with... the binutils gas symver directive (see binutils manual) until all their version names are compatible with a glibc reasonably "old" (I would go for a reasonable 5 years... 7/8 years?):
Or ... just build against the oldest glibc they want to support.
If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. Having such a wide selection of tools to readily reach for with zero consideration about how long it’ll be supported, which fork is best, how well it meshes with a pile of other third party libraries, etc is amazing. It reduces friction massively and you just build stuff.
The KDE Qt ecosystem and its GNOME/GTK analogue are closest but still aren’t quite there.
> If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday.
I doubt it. More likely, you would be complaining that you need to spend effort rewring your code to use Linux frameworks for a tiny userbase.
That's why most cross-platform software ends up using OS frameworks only where neccessary and ships its own version for most stuff. Coincidentally, that approach matches which stable ABIs are available on Linux.
Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.
Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.
And on a lower level, `fgetwc()` gets crashed deliberately in `libc` when applied to a stream created with `fopencookie()`. It should be incredible, but Linux `libc` is not Unicode-capable in 2023.
Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments.
At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that.
There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal.
Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money.
There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases.
> On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often.
I would not use MacOS as an example of stability, each version breaks and deprecates a massive amount of API and old apps will require changes.
Windows is the only OS with serious backward compatibility.
People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.
Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java.
Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework.
So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
As someone who uses Linux as a daily driver, I can recognize these gargantuan apps a mile away and stay away from them. They are absolute hogs of system resources, and for something simple like Etcher there's no excuse.
Things like Electron are good for devs but bad for users. We have more computation power than ever and yet programs still run slow.
Targeting only a hand full of frozen releases is not abi stability. Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).
Maybe I'm just too ignorant to know the pattern that determines whether I need to specify 'dev' and 'version' on a package or some random trailing '1' or '0', but the first linux distro with a sensible and consistent naming scheme for packages is the one that wins my heart.
The number is a version for when they provide more than one that can be installed at once (excepting where it's part of the library name, presumably like xcb1).
I.e. at some point you could probably install libgtk-3-0 and libgtk-2-$something at the same time. They likely leave it that way when they get rid of libgtk-2 so that existing tutorials that reference libgtk-3-0 don't fail because the package is now libgtk.
The libwayland-server0 one does get me, I don't know why there's a 0 at the end. I do know that in /var/lib there is often the same library with various .$number endings, but I've never looked into what that accomplishes.
Separating binaries from sources is a Debian convention. If you're just using a library, non-dev is sufficient. If you're developing with that library, you'll also want -dev, which will install the headers.
Nothing special about the trailing 1 or 0; that's just part of the package name/version.
Arch and its derivatives (mostly) don't have any of that.
Though -dev means stuff only needed when developing against it.
Number means major version number (so compatibility number). This way you can easily install multiple major versions as dependencies for different packages without clashing or breaking.
If you are building a program, install the -dev package. Numbered -dev packages are usually not relevant; there should be an unnumbered one that forwards if needed.
During the build of a program, you record which numbered suffix (= ABI version, should be the same as the .so.N suffix but that's not how you look it up; this allows you to install multiple incompatible copies of the library and they will be used by the appropriate, though distros usually prune these after each major release) is used. This should be automatic. (if there's more than one number, all but the last are part of the library name itself. There might be exceptions for BSD-style libraries?)
When installing, you should be automatically using the dependency you recorded during the build.
This is one of the biggest issues holding the Linux platform as a whole. It's often cited as a strength, but I don't see it as such. Many times, the plethora of choice is pushed forward by devs as an advantage of Linux ("you have so many choices to pick from!") but for many users this presents the paradox of choice - and pushes many people back to the platform they came from.
You get less choice on macOS and Windows, but the choices available are much more polished and less fragmented.
i.e. How many different tiling window managers do we need? Can't we take the best tiling wm's and start developing better docks and applets for them? How about apps and launchers that integrate with the tiling WM paradigm? Instead we end up with 10 different varieties of tiling wms and half-baked half-assed workarounds and programs for them.
People don't make choices by exhaustive analysis they consider a small quantity of options and by popularity or proximity select one and run with it. Successful ecosystems make it reasonably to pick a highly visible option and come out with something good enough. The proliferation of Linux distros is largely small difference that don't meaningfully decrease fitness because only a tiny minority who themselves had little problem finding a distro think its an issue.
By contrast issues like Wayland wherein your plumbing and hardware suddenly matter and you have to become at least somewhat familiar with the plumbing in order to select a usable set of options DO matter because they increase the chance of crapping out when you stroll down the aisle metaphorically and pick a box and end up somewhat satisfied.
It honestly makes little sense to compare Mac or Windows to Linux. In the eyes of 95% of consumers an OS either an immutable characteristic of a computer or a feature thereof and they aren't interested in it as a separate product. They might well buy a computer with that OS if the overall package makes sense but they sure as hell wont install it on their windows or mac machine. Those who are technically literate enough to be satisfied are unlikely to be confused if people add 3 more Ubuntu derivatives and 2 more arch ones.
But writing a tiling wm is fun. Writing software collaboratively is the point in itself, not just the means of getting some kind of artifact in the end.
Being an open source developer means having agency over your goals and means to get to them, which you often don’t have when doing commercial software development.
You sure end up with roughly edges, but the. IKEA-effect kicks in and you like it anyway.
Right and this holds the platform back. I'm all for hobby development- I've been an supporter of open source software for over 2 decades. But nothing much has changed since that time in terms of UX and user-friendliness. (Yes I am aware a lot of things have changed, but as much as things have changed - much of it is still the same.)
This is a problem that is meant to be solved by distros. People who don't want many choices should be using a distro that makes a bunch of choices for them, instead of pushing to remove choice from the ecosysytem altogether.
Everybody using the same software creates a monoculture which is more prone to attack than a diverse ecosystem. There's a reason Windows was targeted so much by viruses: not only was the target BIG, but it was also consistent. If you broke into one normie's Windows machine, you could probably break into the rest. You're going to have a harder time of that if you target Linux.
Also, it's libre software. Unless you pay someone to do something for you, most of it is volunteer activity. And who are we to tell someone what they should do with their volunteer time?
It's also an indictment of the dominant social structures if there are all these groups and nobody wants to join them. They could start by getting rid of Codes of Conduct that give them permission to punish you for out-of-project behavior. Try that.
> People who don't want many choices should be using a distro that makes a bunch of choices for them, instead of pushing to remove choice from the ecosystem altogether.
You don't need to remove choice to push better UX and software. It's not a zero-sum game here; we can foster better conversations with people in the Linux community and start talking about what would make the experience better for the average user, not just technically proficient power-users.
> Everybody using the same software creates a monoculture which is more prone to attack than a diverse ecosystem.
That's wrong - you're using a sort of strawman argument. What makes Windows a monoculture? There's a much larger, thriving developer community on that platform with many more developers making free and/or open-source software.
> You're going to have a harder time of that if you target Linux.
"Achkshully..." Linux has had some serious bugs, but the damage was relatively low to end users because of it's low adoption rates. It has very little to do with "Linux is more secure because we're diverse" and everything to do with "1% of end users use Linux, so the target is less likely to be worth my time." And furthermore, that 1% - the majority will be more technically proficient and less likely to be tricked into running arbitrary software.
> one normie's Windows machine
This. Is. The. Problem. Framing an end-user as a mentally deficient 'normie'. Why? What's the point and what's to be gained from this?
> And who are we to tell someone what they should do with their volunteer time?
No one is suggesting we tell hobbyists / volunteers what to do with their time. What people are suggesting is that we spend a little time talking about tackling common problems together, rather than re-inventing the wheel every single time.
I would say there are even more launchers and docks then tiling WMs.
Also I don't know what would need to be better about them. Something like ulaucher or Albert is much more powerful than what is available in other platforms and I don't know how one would improve their UI.
Maybe the work needs to go into developing better UX, not so much UI or what the various tools can do. Look at PySimpleGUI (of which I was reminded of from a recent post here) for a good example of a nice project for the masses - we need better software for users.
More software? Wonderful! I'm all for it, but before starting something from scratch why not contribute to something that already exists, or possibly pick some project that was abandoned or simply needs to be worked on for example to be built with newer compilers, run on newer hardware, etc. Which makes me wonder if there is somewhere a database of dormant/dead projects that would deserve to be resurrected.
That something that already exists may not be built in the way you are aiming for.
That other something might be led by a dickhead that you can't get along with, or a community that's not receptive to your suggestions or patches.
Social processes and blockages can lead to losing motivation to contribute. Not everyone is cut out to be this happy-go-lucky team player that has no personality.
As for myself, I'd rather start from scratch because 1) I'll control every variable, 2) I don't have to mess around with some existing social and tech infra, 3) I don't have to talk to anyone and convince them my ideas are good, 4) who wants to spend more time arguing or discussing than writing code?
The solodev experience is just better. You're not hamstrung by politics and social process. Being a team player has only led to misery for me.
Yes, I would echo this. In most categories there are loads of subpar efforts when putting all that effort behind the top few would yield a handful of excellent apps.
Collaboration can seem daunting and hard work, but it's work that will yield results which is time better spent than that devoted to projects that end up abandoned.
I'm not convinced these efforts to put everyone's ideas in one place and one software are good. Often, design disagreements arise which are incompatible. Under this model of "everybody love everybody" lameshit, if you can't get the group to accept your idea, it doesn't happen.
You don't run into this problem when you write alone.
I wonder if any of the major Linux package repos collect statistics that let you search for apps that are both (a) widely used and (b) unmaintained/feature-incomplete.
There's a lot of complaints that there isn't much in the way of tooling to create cross-OS compatible apps but I disagree. Just looking at solutions which aren't Electron:
- Telegram uses Qt and ships a performant native app across all three OSes
- Flutter compiles down to native code across all three (and mobile)
- Kirigami is a QtQuick framework that will give you an executable app across all mobile and desktop targets
Go and build your app. There's no reason this needs to an excuse to flame on Linux.
Except Flutter is a subpar experience on every platform because of just how slightly different it behaves and Kirigami / Qt Quick is just not a viable thing, there's barely any community and/or "serious" project on Windows, macOS or mobile. I'm not trying to discredit the KDE folks, but that is reality. Also, Qt Quick licensing is not so easy (or very expensive if you go commercial) for iOS.
Whereas electron has a) big major corporations betting on it shipping extremely polished,
Production-ready tools and b) a gigantic community and library ecosystem, plus not any obscure programming language (such as Dart).
Telegram really goes the extra mile, though. Their client is amazing.
> Except Flutter is a subpar experience on every platform because of just how slightly different it behaves
I'm not sure this is true. If you check the pulse of social media, most Flutter devs think Flutter is great for Android, iOS and desktop but needs help on web. Canonical at least rewrote their installer in Flutter and anything new they develop is in Flutter. Devs are hoping that the WASM support currently shipping in `master` [1] will solve for web.
The problem is OSS software not even trying to compete with the market. People using OSS software taking it for granted that the UX is going to be subpar, and it really is. Regular propriety software faces the risk of their users not paying, therefore adapting to make end user experience great. OSS usually doesn't have that risk. Open source needs to be exposed to risk from end users.
I tried to change that with Notes[1] but I find it hard to live on solely on ads. I tried to incorporate paying for some premium features (like Kanban) but the app is still fully FOSS therefore everyone can compile it from source easily.
I think I'll close-source my next app[2] before it launches. I just can't risk not being paid for my hard work. I also believe the Linux community will benefit from that, since getting paid will allow me to invest more in making UX-focused apps on Linux. I might open source some parts of it tho (or maybe all of it in the far future).
There is a large intersection of Linux users and people who cherish their freedoms. For many people, using non-open source note taking software is a non starter because of the vendor lock-in and privacy concerns. Thus, you'll probably lose out more by not open sourcing the program than by open sourcing it and risk having some people not pay. I wager a lot more people is willing to pay than use proprietary software. Also note that open sourcing doesn't require you to distribute the code to everyone, you can give source code only to paying users if you are charging them money, though they will have the right to modify and redistribute. If they don't care about open source, they might as well just use Notion or Evernote. If someone is looking for an open source state of the art note taking program, I recommend Logseq.
I'm a big believer in open source software. I've had wonderful contributors and I'm using qutie a few open source libraries/components in my own apps. That's why I open sourced my own app.
I've tried many different options so I could make a living with it (ads, donations, premium features). There are definitely more ways to explore. But for now, I need to ensure that my financial situation is stable before anything else. Then, maybe in the future I'll be able to afford tinkering with a sustainable way of open sourcing.
I've also started to notice many VCs starting to invest in open source software (just today saw Godot featured on HN). So that can also be a potential route.
There are some programs that sell binaries but also give away the code.
The premier pixel art editor Aseprite is free (source available, not open source) if you're willing to build it from source yourself, but most users buy the prebuilt binaries. I think this way you satisfy both the privacy conscious / cheapskates, and also the developer's economic needs. RMS doesn't approve I'm sure, but you can't please them all.
I think you're making the right decision. Open-source is extremely difficult to make even a living wage off of - the number of people who do is orders of magnitude smaller than those who make a living off of commercial software.
It's definitely possible to make a decent living with FOSS software. One of the main contributors to my note-taking app is @bjorn[1] who developed the awesome Tiled editor[2] and managed to figure out a sustainable way to earn a living from donations/sponsorships. There are probably more instances of that. I tried to go the same route, but other than a $5 monthly payment on Patreaon (thank you awesome contributor!) I couldn't figure it out.
I hate serving shitty Google ads. They are also not a stable source of income and the revenue is low in my case. It's time for me to move on.
>Open-source is extremely difficult to make even a living wage off of…
So are you saying it’s even possible? I wish to learn at least one option to do it. Few is even better. How at all you can realistically make living this way?
Ok, not living , just partial income.
Ok not partial. Some income?
I am not making fun of I honestly look some way .
I understand that if you maintain 10 years some essential part of essential software project then people eventually come to you for consulting or will pay you to shift this part toward their requirements.
But other then that? Like can you write useful free software program and really have some money from it ?
I understand your frustration, but I have a couple of counter-examples, and I don't offer them in any derogatory way.
1) Notes looks a lot like Standard Notes. If you built Notes using copy-left, OSS it's hard to complain unless you pay "royalties" to all the programmers whose work was incorporated into yours.
2) I am probably atypical. I have used Linux for over 20 years, but I can't write so much as a Bash script or a Perl one-liner. Yet I have spent a whole lot more money on software than I would have (or most individuals do) on other platforms. Because I can't code and appreciate the work of others and the freedom it gives me I support the following (not exclusive):
* Kaisen (my distro) and Debian (the distro Kaisen is built on) both
* tFSF for both core utilities and Emacs
* My DE (KDE), and even if I prefer the UI of other applications I mostly try to use those provided by KDE,tFSF, Debian, or Kaisen (e.g Akregator over RSSGuard) unless I donate, like:
* Mozilla (for Firefox), but
* Betterbird for my email client
* Syncthing
* LaGrange (gopher/gemini)
* Joplin
* ClipTo
* and more, including services (e.g. SoulSeek, envs.net)
Some annually, some monthly, some one-time.
In fact, when Standard Notes first came out I paid for a seven year subscription, and then ended up using it for about 2 months before becoming dissatisfied. There are some, like Alacritty, that I use extensively but which I have found no way to donate to, but I try to keep it to a minimum.
There are some amazing people that valued what I'm doing. One person even donated $1000 years ago. But that doesn't make it sustainable.
I think it's time for me to compete on the market. I believe Plume is going to be a good addition to the pool of productivity apps today, but I'll let people judge that when it's released. I hope you will sign up to get an update[2] and let me know what you think of it when it is released.
BTW, are you suggesting I copied Standard Notes? Not really, I don't like their design. Notes is in active development since 2014 (first commit on GitHub in 2015), back then I didn't even know about Standard Notes and the core design barely changed.
Personally I think KDE is light years ahead of macOS and Windows.
In fact I find macOS to have been be of the worst window managers of all the popular platforms (sure it’s pretty and easy to use, but trying to do anything beyond the basics requires magical incantations that are impossible to discover organically).
Well, I'm a Qt programmer (and love it!), so I know a bit about this ecosystem. Unfortunately in terms of UX and aesthetics, KDE apps don't come even close to the macOS ecosystem.
KDE is the definition of all UI and no UX. Like there's no one actually planning out how a user would/should actually use the thing. That's why I generally prefer Gnome despite it's faults. Even if I don't agree with every decision and lack of customization at least it feels like there's some vision on how it should be used.
Can you elaborate more? What features you are talking about?
I can criticise Mac OS endlessly and was even actively downvoted here when reported facts of my personal experience with bugs on newly purchased M1 (you can dig the history if you wish). I was shocked how quality degraded in my opinion.
People here were even claiming that it’s my specific faulty machine was to blame. This ‘faulty’ machine by the way works to this very day without any hardware problems except flickering of the monitor which is idiotic in my opinion design decision (to use PWM).
So as you can see I am very critical of macOS and consider using Windows after macOS like completely unbearable. And yet your comment have puzzled me.
When I was learning macOS after years with Windows I remember that certain things were like you say “impossible to discover”. Yet with all that being said I find other GUI implementations in GNU/Linux not any better.
Perhaps I’ve missed something in KDE? What did I miss? What “doing anything beyond basic” means in your usage? What kind of tasks/workflows are those ?
How KDE better in those?
1. I've never heard of your app, and I follow this space closely. It's extremely competitive.
2. I clicked to check how much you're asking for premium. It's reasonable on an annual basis, but I only saw an option for a monthly subscription. That's not happening.
3. I'd be more likely to give you a donation than to pay for a premium version for an app like this. That model has worked well for Obsidian. I don't think getting early access to features is worth much, but a lot of people have paid them to support their work.
4. My observation is that a closed core product with a large open source ecosystem around it gives folks a reason to pay.
> but I only saw an option for a monthly subscription.
What do you mean? The annual subscription doesn't work? Or something else?
> I'd be more likely to give you a donation than to pay for a premium version for an app like this.
Well, for my Notes app, I can understand. Hopefully you will find my new app as a breath of fresh air in this space. Sign up to get an update please! I would love to hear what you think when the app is out.
> My observation is that a closed core product with a large open source ecosystem around it gives folks a reason to pay.
Overall, I think people will pay if an app gives them enough value.
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
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.
> People using OSS software taking it for granted that the UX is going to be subpar...
After using the abomination known as Windows 11, I'd argue that the UX of Linux is well beyond par, especially when par for Windows 11 is showing Microsoft ads at you while you're using almost every application.
I am in an interim CTO position and the year before the title of a role I acted as had "Principal" in its title. I still write Commonmark files to render them to HTML and PDF with Pandoc.
There are dozens of Markdown note taking apps out there. There are half a dozen Notion clones out there. I know which one will overwhelmingly win mindshare due to a special feature but I won't give away why (the feature itself is more valuable than a Notion clone or even Notion itself).
You might be able to get paid for providing something valuable to others. Sometimes hard work is involved in providing value to others, but performing hardwork doesn't necessarily mean you have provided value to others.
> Open source needs to be exposed to risk from end users.
Why do open source applications need that? You said yourself that users of open source software accept the subpar UX, so what problem are you trying to solve? Making open source development somehow 'riskier' for programmers without simultaneously providing more reward would only drive programmers away.
Users of OSS software accepting the subpar experience is the problem. You don't think they look away to their macOS counterparts and wish these polished apps were available on their Linux machines? I used Linux as my primary device for 2.5 years, then switched to macOS and never looked back. Now I want to bring the same polished user experience to other operating systems using Qt. I believe my latest attempt [1] is the closest to get there without the awful sacrifices of Electron apps.
I really like the functionality of your notes app, but I don't think emulating Apple UI design is the solution to subpar UI on Linux.
Linux users expect basic desktop conventions like toolbars, dropdown menus, and not mobile design concepts like cramming everything into a hamburger menu.
Have you even tried using my app? It doesn't have any of the "mobile design concepts" that you're talking about.
> cramming everything into a hamburger menu
- Import/Export
- Check for updates
- Start automatically
- Hide to tray
- Change database path
- About Notes
- Quit
Is that EVERYTHING?
No. It's not. I don't like using hamburger menus for everything myself. This is why the options are minimalistic. Look at other Gnome apps using hamburger menus, no need to go as far as "Apple UI" (which actually discourages hamburger menus for desktops apps).
Plume's editor is a block-editor I wrote completely from scratch using C++ (model) and QML (view). This allows me to create an advance editor that can have complex elements (like Kanban, Columns, advance image components, etc) within the text. The performance using Qt C++ compared to Electron is a mssive improvement over current web apps (like Notion and the likes), and actually, i's even faster than native apps on macOS (Craft, Bike) and apps made in Flutter (AppFlowy).
Hows it different from Obsidian or any other note taking app that has a larger community. I'm sure OP put in lots of hard work and it looks good, but it's not apparent to me why I should abandon my existing platform (stickiness) for another one. There are a lot of note apps out there already which probably makes it hard to sell.
Thanks for sharing. Appreciate your fighting the good fight, and sorry for the results so far. Maybe apply for a Futo scholarship for one? But definitely close source for Plume.
No need to be sorry, really. I'm just learning how to navigate this world. I've been pretty lucky so far. Notes is one of the top results in Google (for the keyword "notes"). So I get a lot of traffic and a nice passive income. But it's not something I can fully live on (plus it's unstable and I hate serving ads).
on your ‘com’ site mentioned in github page download button does not offer (near by) payed options. Why? Why it is only in the separated Pricing link? Why not to present the same choice in download ?
In principle maybe, but all present implementations fall a bit short. Why can't I use my mouse to position the cursor in any shell? Placing the cursor with the mouse is something people commonly do in terminal editors like vim or emacs; the efficiency arguments against it fall flat because this is entirely optional and besides, many people use laptops with either a track-point directly in the middle of the home row keys or with a touchpad directly below the keyboard.
And there's no technical reason it couldn't be done; years ago I once did it as a proof of concept. It just hasn't made it into any major shell yet.. besides eshell anyway. It does work on eshell.
Anyway, it's not really a big deal, not important enough for me to pursue, but I do think it counts as a counterexample to disprove the "peak UX" claim. Command line interfaces in principle are great but in practice we're doing it by emulating hardware that went obsolete decades ago and piling cludges and hacks on top of that to make it feel a bit more modern.
Another example; there are a few ways to inline images in a terminal emulator but they're all kind of shit in their own ways; graphical thumbnails have clear utility when listing some directories; every serious file manager supports it but to do this in a terminal emulator is cludgy hacks.
Utter nonsense. The CLI lets you do complex custom things that you sometimes can't do with a GUI. But it is pretty awful from a UX point of view. Terrible discoverability, terrible UI, very unfriendly, no contextual help, etc. etc. I can't think of a worse interface from a UX perspective.
That's what people who gained their technical competence in a CL environment always think: we're always most productive in the interfaces we are familiar with. I'll agree that most technically competent people probably prefer using the command line for many tasks, but correlation != causation. It's really easy to mistake our own preferences for being objectively good, generally... which is why designers exist, why most user-facing commercial software doesn't require reading a single line of documentation, and why most FOSS projects-- almost entirely indifferent to or hostile towards deliberate design-- are only useful to people who have a working mental model of what's happening under the hood.
I was strictly a vim guy for a decade and a half... my coworkers occasional snicker merely steeled my resolve, but I knew I was doing the pure and efficient and technically correct thing by sticking to barebones vim. Lots of vim stuff and ex commands are beneficial to my workflow, but after a coworker convinced me to try out some more modern options with vim modes, I realized that my attachment to vim as an editor was driven by my emotional investment in how many times I struggled with vim's clunkiness. I wore it as a badge of honor. I thought it gave me cred. In reality it just showed how utterly inflexible I was. The Jetbrains editors, for example, offered more functionality out of the box than I could practically cram into my vim setup, yet was completely configurable, and the features were generally intuitive and discoverable. I didn't have to look up how to do some relatively obscure thing in ex-- there was probably a menu option for it so I just didn't have to keep it in my head. Sure, vim is and always will be my default editor for light editing, and there are obviously people whose use cases are perfectly satisfied by using it. However, assuming for years that I was more technically competent for doing intensive professional work in complex codebases using that clunky old editor was plain old self-indulgent arrogance, like most other nerd badge-of-honor things are.
I've been using command line environments daily for decades, and usually head there first to do many tasks, but many of these archaic tools only persist because of a reverse eternal-September problem. By the time someone gets technically advanced enough to start influencing how our technical environments work, the curse of expertise obfuscates their downsides and they mistake their own comfort with something for it being objectively good.
I'm not aware of anyone who is making a distro who should instead be making an application. Maybe LinuxCNC if you squint?? But that has very specific kernel requirements which are arguably best served by a custom distro.
any desktop environment is effectively just an application that's trivially to install via one or two clicks or commands. Never made sense to me why there's derivatives of derivatives that just ship a different DE.
Stop listening to people who say to stop listening to people trying to tell you what you should do or not. It is not all relative, there are good and bad choices.
Not hacking on a distro because someone thinks there are too many is one of those bad choices.
If you actually manage to get a distribution rolling with a viable community around it, it means enough people have decided that there weren't too many.
Readit News
I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management instead of doing it in the frameworks and programming languages themselves (which are what you are asking people to write apps in).
Linux does have a de facto set of standards, they're not quite as stable because they change them and deprecate old stuff, but it's better than it looks, and with Snaps you can at least partially solve the issue.
But people choose distros that don't have those standards, and then you lose half your potential users if you don't support all the niche configurations.
Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass.
Pretty wild that the same thing is not the norm in other OSs.
Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point.
If that's not stable, I don't know what is.
Another abi I see games target are ubuntu... 14.04, 16.04, 18.04, etc
Ubuntu seems to be stable enough for the corporate world.
I think things like flatpack or snap add bloat and behave in ways you don't want.
However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions.
In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and naturally those are the winning Linux distributions for regular consumers.
https://sourceware.org/glibc/wiki/Glibc%20Timeline
Of course normal game devs have not the slightest idea of those issues, and even so, they won't do it because it is a pain, that for 1% of their market. Not to mention they better statically link libgcc (and libstdc++ if they use c++) to avoid the ABI issues of those abominations (the word is fair) which have been plagging game binaries for TEN F.... YEARS ! (getting better has more and more game binaries default to -static-libgcc and -static-libstdc++, if c++, gcc/clang options).
There is light at the end of the tunnel though as godot engine is providing build containers which are very careful of all that (unity seems clean there too, dunno for UT5.x though).
But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run. And packaging properly a full google blink engine for binary distribution targetting a wide spectum of elf/linux distros? Yeah... good luck with that.
elf/linux is hostile to anything binary only, that due to manic ABI breakage all over the board, all the time (accute in the SDK and core libs).
If it is already that hard for game binaries, good luck with apps. I can hear already their devs saying: "we don't care, just use and install microsoft suze gnu/linux, every else is unsupported"... I think you get the picture where all that is going.
[1] https://github.com/ValveSoftware/steam-runtime
Video games are some of the most complex and most difficult pieces of software both to build and to get right. Modern games are coded so poorly that driver makers have to release patches for specific games.
It's the gamedev world that can't get its shit together. Valve settled on an Arch-based distro for the Deck. The specific distro doesn't matter since Steam already establishes its system requirements and comes with a runtime.
Beyond that, I really don't see the issues you're talking about. Generally, any issues you have are fixed by symlinking the correct .so files. This is a side effect of targeting a specific version of software instead of keeping to its more base features. That's on the dev, not the user or distro.
You act like Windows has never had ABI breakage or versioning problems. I'd like to see the specific issues you ran into; maybe there's an easy fix like a symlink.
Hm, not sure what you mean here.
At least with the nw.js toolkit (from which Electron was forked IIRC) I've never gotten a report of a distro where it would refuse to run because of an incompatible GTK version.
Or ... just build against the oldest glibc they want to support.
The KDE Qt ecosystem and its GNOME/GTK analogue are closest but still aren’t quite there.
I doubt it. More likely, you would be complaining that you need to spend effort rewring your code to use Linux frameworks for a tiny userbase.
That's why most cross-platform software ends up using OS frameworks only where neccessary and ships its own version for most stuff. Coincidentally, that approach matches which stable ABIs are available on Linux.
https://gnustep.github.io/
Deleted Comment
There's glibc, musl libc, etc. Also consider you may be using the functions incorrectly.
At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal.
Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money.
There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases.
What use case do you imagine for this feature?
I would not use MacOS as an example of stability, each version breaks and deprecates a massive amount of API and old apps will require changes.
Windows is the only OS with serious backward compatibility.
Motif ?
WxWidgets ?
Openstep ?
Gnome and Kde do reinvent the wheel with every release, but they shoouldn't be taken seriously.
There is a general problem on the SW world. They like to reinvent the wheel every now and then.
Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework.
So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
Things like Electron are good for devs but bad for users. We have more computation power than ever and yet programs still run slow.
Deleted Comment
[0]: https://github.com/sudhakar3697/awesome-electron-alternative...
Meh, kinda.
It's not a case that proprietary software vendors only target RHEL, Suse and Ubuntu.
RHEL is a perfect target for stable software and Ubuntu might be as well if you decide to only support LTS releases.
`libgnutls-dev` `libgtk-3-0` `libwayland-server0` `libxcb1` `libx11-6` `libffi-dev` `libncurses5-dev`
The number is a version for when they provide more than one that can be installed at once (excepting where it's part of the library name, presumably like xcb1).
I.e. at some point you could probably install libgtk-3-0 and libgtk-2-$something at the same time. They likely leave it that way when they get rid of libgtk-2 so that existing tutorials that reference libgtk-3-0 don't fail because the package is now libgtk.
The libwayland-server0 one does get me, I don't know why there's a 0 at the end. I do know that in /var/lib there is often the same library with various .$number endings, but I've never looked into what that accomplishes.
ABI versioning.
Nothing special about the trailing 1 or 0; that's just part of the package name/version.
Though -dev means stuff only needed when developing against it.
Number means major version number (so compatibility number). This way you can easily install multiple major versions as dependencies for different packages without clashing or breaking.
If I install openssl, I want everything that upstream ships, which means command line tools, headers, libraries, man pages.
The Debian/Ubuntu convention is terrible, and anachronistic. Disk space is cheap, my time is not.
During the build of a program, you record which numbered suffix (= ABI version, should be the same as the .so.N suffix but that's not how you look it up; this allows you to install multiple incompatible copies of the library and they will be used by the appropriate, though distros usually prune these after each major release) is used. This should be automatic. (if there's more than one number, all but the last are part of the library name itself. There might be exceptions for BSD-style libraries?)
When installing, you should be automatically using the dependency you recorded during the build.
And, as for the -dev packages:
1) As always, a tooling issue (aka why is there no IDE for this?) 2) A design issue: no sub-packages/"aspects"
You get less choice on macOS and Windows, but the choices available are much more polished and less fragmented.
i.e. How many different tiling window managers do we need? Can't we take the best tiling wm's and start developing better docks and applets for them? How about apps and launchers that integrate with the tiling WM paradigm? Instead we end up with 10 different varieties of tiling wms and half-baked half-assed workarounds and programs for them.
By contrast issues like Wayland wherein your plumbing and hardware suddenly matter and you have to become at least somewhat familiar with the plumbing in order to select a usable set of options DO matter because they increase the chance of crapping out when you stroll down the aisle metaphorically and pick a box and end up somewhat satisfied.
It honestly makes little sense to compare Mac or Windows to Linux. In the eyes of 95% of consumers an OS either an immutable characteristic of a computer or a feature thereof and they aren't interested in it as a separate product. They might well buy a computer with that OS if the overall package makes sense but they sure as hell wont install it on their windows or mac machine. Those who are technically literate enough to be satisfied are unlikely to be confused if people add 3 more Ubuntu derivatives and 2 more arch ones.
Being an open source developer means having agency over your goals and means to get to them, which you often don’t have when doing commercial software development.
You sure end up with roughly edges, but the. IKEA-effect kicks in and you like it anyway.
Everybody using the same software creates a monoculture which is more prone to attack than a diverse ecosystem. There's a reason Windows was targeted so much by viruses: not only was the target BIG, but it was also consistent. If you broke into one normie's Windows machine, you could probably break into the rest. You're going to have a harder time of that if you target Linux.
Also, it's libre software. Unless you pay someone to do something for you, most of it is volunteer activity. And who are we to tell someone what they should do with their volunteer time?
It's also an indictment of the dominant social structures if there are all these groups and nobody wants to join them. They could start by getting rid of Codes of Conduct that give them permission to punish you for out-of-project behavior. Try that.
You don't need to remove choice to push better UX and software. It's not a zero-sum game here; we can foster better conversations with people in the Linux community and start talking about what would make the experience better for the average user, not just technically proficient power-users.
> Everybody using the same software creates a monoculture which is more prone to attack than a diverse ecosystem.
That's wrong - you're using a sort of strawman argument. What makes Windows a monoculture? There's a much larger, thriving developer community on that platform with many more developers making free and/or open-source software.
> You're going to have a harder time of that if you target Linux.
"Achkshully..." Linux has had some serious bugs, but the damage was relatively low to end users because of it's low adoption rates. It has very little to do with "Linux is more secure because we're diverse" and everything to do with "1% of end users use Linux, so the target is less likely to be worth my time." And furthermore, that 1% - the majority will be more technically proficient and less likely to be tricked into running arbitrary software.
> one normie's Windows machine
This. Is. The. Problem. Framing an end-user as a mentally deficient 'normie'. Why? What's the point and what's to be gained from this?
> And who are we to tell someone what they should do with their volunteer time?
No one is suggesting we tell hobbyists / volunteers what to do with their time. What people are suggesting is that we spend a little time talking about tackling common problems together, rather than re-inventing the wheel every single time.
Also I don't know what would need to be better about them. Something like ulaucher or Albert is much more powerful than what is available in other platforms and I don't know how one would improve their UI.
We need better applications that have better UX.
As many as people want to create.
That other something might be led by a dickhead that you can't get along with, or a community that's not receptive to your suggestions or patches.
Social processes and blockages can lead to losing motivation to contribute. Not everyone is cut out to be this happy-go-lucky team player that has no personality.
As for myself, I'd rather start from scratch because 1) I'll control every variable, 2) I don't have to mess around with some existing social and tech infra, 3) I don't have to talk to anyone and convince them my ideas are good, 4) who wants to spend more time arguing or discussing than writing code?
The solodev experience is just better. You're not hamstrung by politics and social process. Being a team player has only led to misery for me.
Collaboration can seem daunting and hard work, but it's work that will yield results which is time better spent than that devoted to projects that end up abandoned.
I'm not convinced these efforts to put everyone's ideas in one place and one software are good. Often, design disagreements arise which are incompatible. Under this model of "everybody love everybody" lameshit, if you can't get the group to accept your idea, it doesn't happen.
You don't run into this problem when you write alone.
Deleted Comment
- Telegram uses Qt and ships a performant native app across all three OSes
- Flutter compiles down to native code across all three (and mobile)
- Kirigami is a QtQuick framework that will give you an executable app across all mobile and desktop targets
Go and build your app. There's no reason this needs to an excuse to flame on Linux.
Whereas electron has a) big major corporations betting on it shipping extremely polished, Production-ready tools and b) a gigantic community and library ecosystem, plus not any obscure programming language (such as Dart).
Telegram really goes the extra mile, though. Their client is amazing.
I'm not sure this is true. If you check the pulse of social media, most Flutter devs think Flutter is great for Android, iOS and desktop but needs help on web. Canonical at least rewrote their installer in Flutter and anything new they develop is in Flutter. Devs are hoping that the WASM support currently shipping in `master` [1] will solve for web.
[1] https://docs.flutter.dev/platform-integration/web/wasm
[0]: https://github.com/overtake/TelegramSwift
I tried to change that with Notes[1] but I find it hard to live on solely on ads. I tried to incorporate paying for some premium features (like Kanban) but the app is still fully FOSS therefore everyone can compile it from source easily.
I think I'll close-source my next app[2] before it launches. I just can't risk not being paid for my hard work. I also believe the Linux community will benefit from that, since getting paid will allow me to invest more in making UX-focused apps on Linux. I might open source some parts of it tho (or maybe all of it in the far future).
[1] https://github.com/nuttyartist/notes
[2] https://www.get-plume.com
I've tried many different options so I could make a living with it (ads, donations, premium features). There are definitely more ways to explore. But for now, I need to ensure that my financial situation is stable before anything else. Then, maybe in the future I'll be able to afford tinkering with a sustainable way of open sourcing.
I've also started to notice many VCs starting to invest in open source software (just today saw Godot featured on HN). So that can also be a potential route.
The premier pixel art editor Aseprite is free (source available, not open source) if you're willing to build it from source yourself, but most users buy the prebuilt binaries. I think this way you satisfy both the privacy conscious / cheapskates, and also the developer's economic needs. RMS doesn't approve I'm sure, but you can't please them all.
I hate serving shitty Google ads. They are also not a stable source of income and the revenue is low in my case. It's time for me to move on.
[1] https://github.com/bjorn
[2] https://github.com/mapeditor/tiled
So are you saying it’s even possible? I wish to learn at least one option to do it. Few is even better. How at all you can realistically make living this way?
Ok, not living , just partial income. Ok not partial. Some income?
I am not making fun of I honestly look some way .
I understand that if you maintain 10 years some essential part of essential software project then people eventually come to you for consulting or will pay you to shift this part toward their requirements.
But other then that? Like can you write useful free software program and really have some money from it ?
1) Notes looks a lot like Standard Notes. If you built Notes using copy-left, OSS it's hard to complain unless you pay "royalties" to all the programmers whose work was incorporated into yours.
2) I am probably atypical. I have used Linux for over 20 years, but I can't write so much as a Bash script or a Perl one-liner. Yet I have spent a whole lot more money on software than I would have (or most individuals do) on other platforms. Because I can't code and appreciate the work of others and the freedom it gives me I support the following (not exclusive):
* Kaisen (my distro) and Debian (the distro Kaisen is built on) both
* tFSF for both core utilities and Emacs
* My DE (KDE), and even if I prefer the UI of other applications I mostly try to use those provided by KDE,tFSF, Debian, or Kaisen (e.g Akregator over RSSGuard) unless I donate, like:
* Mozilla (for Firefox), but
* Betterbird for my email client
* Syncthing
* LaGrange (gopher/gemini)
* Joplin
* ClipTo
* and more, including services (e.g. SoulSeek, envs.net)
Some annually, some monthly, some one-time.
In fact, when Standard Notes first came out I paid for a seven year subscription, and then ended up using it for about 2 months before becoming dissatisfied. There are some, like Alacritty, that I use extensively but which I have found no way to donate to, but I try to keep it to a minimum.
I think it's time for me to compete on the market. I believe Plume is going to be a good addition to the pool of productivity apps today, but I'll let people judge that when it's released. I hope you will sign up to get an update[2] and let me know what you think of it when it is released.
BTW, are you suggesting I copied Standard Notes? Not really, I don't like their design. Notes is in active development since 2014 (first commit on GitHub in 2015), back then I didn't even know about Standard Notes and the core design barely changed.
[1] https://github.com/nuttyartist/notes/releases/tag/v0.8.0-bet...
[2] https://www.get-plume.com/
In fact I find macOS to have been be of the worst window managers of all the popular platforms (sure it’s pretty and easy to use, but trying to do anything beyond the basics requires magical incantations that are impossible to discover organically).
Each to their own though.
But that's alright. I'm here to change that.
I can criticise Mac OS endlessly and was even actively downvoted here when reported facts of my personal experience with bugs on newly purchased M1 (you can dig the history if you wish). I was shocked how quality degraded in my opinion.
People here were even claiming that it’s my specific faulty machine was to blame. This ‘faulty’ machine by the way works to this very day without any hardware problems except flickering of the monitor which is idiotic in my opinion design decision (to use PWM).
So as you can see I am very critical of macOS and consider using Windows after macOS like completely unbearable. And yet your comment have puzzled me.
When I was learning macOS after years with Windows I remember that certain things were like you say “impossible to discover”. Yet with all that being said I find other GUI implementations in GNU/Linux not any better.
Perhaps I’ve missed something in KDE? What did I miss? What “doing anything beyond basic” means in your usage? What kind of tasks/workflows are those ? How KDE better in those?
1. I've never heard of your app, and I follow this space closely. It's extremely competitive.
2. I clicked to check how much you're asking for premium. It's reasonable on an annual basis, but I only saw an option for a monthly subscription. That's not happening.
3. I'd be more likely to give you a donation than to pay for a premium version for an app like this. That model has worked well for Obsidian. I don't think getting early access to features is worth much, but a lot of people have paid them to support their work.
4. My observation is that a closed core product with a large open source ecosystem around it gives folks a reason to pay.
> but I only saw an option for a monthly subscription.
What do you mean? The annual subscription doesn't work? Or something else?
> I'd be more likely to give you a donation than to pay for a premium version for an app like this.
Well, for my Notes app, I can understand. Hopefully you will find my new app as a breath of fresh air in this space. Sign up to get an update please! I would love to hear what you think when the app is out.
> My observation is that a closed core product with a large open source ecosystem around it gives folks a reason to pay.
Overall, I think people will pay if an app gives them enough value.
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
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=nutt...
[2] https://www.omgubuntu.co.uk/2022/09/open-source-qt-notes-app...
After using the abomination known as Windows 11, I'd argue that the UX of Linux is well beyond par, especially when par for Windows 11 is showing Microsoft ads at you while you're using almost every application.
There are dozens of Markdown note taking apps out there. There are half a dozen Notion clones out there. I know which one will overwhelmingly win mindshare due to a special feature but I won't give away why (the feature itself is more valuable than a Notion clone or even Notion itself).
You might be able to get paid for providing something valuable to others. Sometimes hard work is involved in providing value to others, but performing hardwork doesn't necessarily mean you have provided value to others.
Very much agree. I guess only time will tell (when I launch).
Regarding Plume: just from that landing page, it looks 100% like Notes. Anyway, I'm interested to learn more about it when it launches!
Why do open source applications need that? You said yourself that users of open source software accept the subpar UX, so what problem are you trying to solve? Making open source development somehow 'riskier' for programmers without simultaneously providing more reward would only drive programmers away.
[1] https://www.get-plume.com
Linux users expect basic desktop conventions like toolbars, dropdown menus, and not mobile design concepts like cramming everything into a hamburger menu.
> cramming everything into a hamburger menu
- Import/Export
- Check for updates
- Start automatically
- Hide to tray
- Change database path
- About Notes
- Quit
Is that EVERYTHING?
No. It's not. I don't like using hamburger menus for everything myself. This is why the options are minimalistic. Look at other Gnome apps using hamburger menus, no need to go as far as "Apple UI" (which actually discourages hamburger menus for desktops apps).
Example: https://imgur.com/wajSjbn (I'll implement the Kanban feature next week (:)
Deleted Comment
And there's no technical reason it couldn't be done; years ago I once did it as a proof of concept. It just hasn't made it into any major shell yet.. besides eshell anyway. It does work on eshell.
Anyway, it's not really a big deal, not important enough for me to pursue, but I do think it counts as a counterexample to disprove the "peak UX" claim. Command line interfaces in principle are great but in practice we're doing it by emulating hardware that went obsolete decades ago and piling cludges and hacks on top of that to make it feel a bit more modern.
Another example; there are a few ways to inline images in a terminal emulator but they're all kind of shit in their own ways; graphical thumbnails have clear utility when listing some directories; every serious file manager supports it but to do this in a terminal emulator is cludgy hacks.
I was strictly a vim guy for a decade and a half... my coworkers occasional snicker merely steeled my resolve, but I knew I was doing the pure and efficient and technically correct thing by sticking to barebones vim. Lots of vim stuff and ex commands are beneficial to my workflow, but after a coworker convinced me to try out some more modern options with vim modes, I realized that my attachment to vim as an editor was driven by my emotional investment in how many times I struggled with vim's clunkiness. I wore it as a badge of honor. I thought it gave me cred. In reality it just showed how utterly inflexible I was. The Jetbrains editors, for example, offered more functionality out of the box than I could practically cram into my vim setup, yet was completely configurable, and the features were generally intuitive and discoverable. I didn't have to look up how to do some relatively obscure thing in ex-- there was probably a menu option for it so I just didn't have to keep it in my head. Sure, vim is and always will be my default editor for light editing, and there are obviously people whose use cases are perfectly satisfied by using it. However, assuming for years that I was more technically competent for doing intensive professional work in complex codebases using that clunky old editor was plain old self-indulgent arrogance, like most other nerd badge-of-honor things are.
I've been using command line environments daily for decades, and usually head there first to do many tasks, but many of these archaic tools only persist because of a reverse eternal-September problem. By the time someone gets technically advanced enough to start influencing how our technical environments work, the curse of expertise obfuscates their downsides and they mistake their own comfort with something for it being objectively good.
I'm not aware of anyone who is making a distro who should instead be making an application. Maybe LinuxCNC if you squint?? But that has very specific kernel requirements which are arguably best served by a custom distro.
Stop listening to people trying to tell you what you should do or not.
But the message and information is good though.
I'd personally word it something like "Linux users don't want more distributions. They want software". At least, this is the case for me.
Deleted Comment
If you actually manage to get a distribution rolling with a viable community around it, it means enough people have decided that there weren't too many.