What does HackerNews think of tutanota?
Tutanota is an email service with a strong focus on security and privacy that lets you encrypt emails, contacts and calendar entries on all your devices.
- MariaDB: https://mariadb.com/products/community-server/
- Percona Server for MySQL: https://www.percona.com/software/mysql-database/percona-serv...
Other additional examples of successfully commercialised xGPL products with different business models:
- Red Hat Linux: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
- QT: https://www.qt.io/licensing/
- Ghostscript: https://www.ghostscript.com/licensing/index.html
- WordPress: https://wordpress.com/ (based on https://wordpress.org/ )
- Buskill (hardware): https://www.buskill.in/
- Moodle: https://moodle.com/ (based on https://moodle.org/)
- ProtonMail: https://proton.me/mail (based on https://github.com/ProtonMail )
- Tutanota: https://tutanota.com/ (based on https://github.com/tutao/tutanota/ )
- Dada Mail: https://www.dadamailproject.com/
- Dietlibc: https://www.fefe.de/dietlibc/
The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.
Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.
The real value of an FSF license, like the AGPL, is that it is designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xGPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can thus be closed-source even from the original copyright holder.
But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.
First, encryption is not "obscurity" in the same way you think DRM is.
Second, several other email providers don't think they need to rely on some performance-killing DRM to "protect" their web app (oh no, what of all the value!).
Outlook has a part of their files minified, but doesn't use any obfuscation; apps like ProtonMail[0] and Tutanota[1] are even open source.
(I'm actually starting to migrate off of Gmail to Protonmail myself.)
[0]: https://github.com/ProtonMail/proton-mail/ (the new site, on beta.protonmail.com) [1]: https://github.com/tutao/tutanota
Oh, and there's no need to call people "communists", "attackers", or "criminal scum". Be civil.
I don't have anything but own anecdotial evidence to provide. Would be cool if there were some good, recent benchmarks between the two, but I wasn't able to find any.
Maybe I've just configured something wrong, but I keep facing this issue where autocomplete stops to think suggestions and might just freeze the whole VSCode for a second. This is in a small project that has some fairly large library definition files (namely, aws-sdk).
If you search for "TypeScript performance", you'll find a bunch of issues and posts discussing the subject, so I don't think I'm totally alone in calling it out.
Granted, Flow gets it's share of similar search results and I have also experienced similar issues where a recheck sometimes takes long and CPU usage jumps very high. This side of Flow has been consistently improving between almost every release, though. Most recently, a couple months back, their switch to this new "types-first" architecture [1] is supposedly unlocking something like 50%-90% perf improvements compared to what they vere before.
My point with this isn't to question your experience with Flow, I've sometimes faced similar issues. I'm just saying that, depending on the Flow version you were using, things may have changed a lot for the better.
Just so that I'm not talking _completely_ out of my ass here, as a quick very unscientific test I cloned the Tutanota project's repo [2]. SCC says there's 967 JS files, consisting of 205433 lines of code in there. Flow version is 0.136, which is a little behind, but they are using the new types first mode.
time node_modules/.bin/flow check
Found 0 errors
node_modules/.bin/flow check 1,00s user 0,11s system 9% cpu 11,905 total
Devs say they want to publish the app on F-Droid. https://tutanota.com/blog/posts/secure-mail-open-source
https://tutanota.com - https://github.com/tutao/tutanota - https://en.wikipedia.org/wiki/Tutanota
The company is based in Germany and benefits from BDSG.
A very promising gmail alternative I would say.
- Image loading: I'd assume that this is possible to implement, given the current implementation?
- text/plain & multipart mails: I'd expect the same, really. Doesn't sound too bad to build it.
- same for session storage
I agree with all your points, but these are things that are conceptually quite viable, imo. I'd expect these to be valid issues on Github [1] and reasonably easy fixes, no?