What about suse, rhel and other distros?
Our experience launching a paid, proprietary product on Linux
81–90 of 395 posts
Re: Our experience launching a paid, proprietary product on Linux
#82Completely unrelated to the contents: Please, publishers, I beg you: walk away from medium. It's terrible for us, your readers. Set up a static blog, with a domain, go WordPress, Grav, Typo3, anything, but without stupidly large sticky header/footer and without heavy javascript . EDIT: apparently 121KB javascript is not heavy. I still believe it's an overkill for 30KB content.
I also loved that era of blogs, but unless the distribution problem is solved, we're probably never going back. Self-hosted personal blogs end up mostly being ghost towns these days unless you get somewhat famous. Medium on the other hand gets your foot in the door and draws your niche crowd and conversations for you with much less effort.
Plumes is actually quite interesting as a medium alternative. Not production ready, but with integration in the fediverse
Re: Our experience launching a paid, proprietary product on Linux
#83Completely unrelated to the contents: Please, publishers, I beg you: walk away from medium. It's terrible for us, your readers. Set up a static blog, with a domain, go WordPress, Grav, Typo3, anything, but without stupidly large sticky header/footer and without heavy javascript . EDIT: apparently 121KB javascript is not heavy. I still believe it's an overkill for 30KB content.
I also loved that era of blogs, but unless the distribution problem is solved, we're probably never going back. Self-hosted personal blogs end up mostly being ghost towns these days unless you get somewhat famous. Medium on the other hand gets your foot in the door and draws your niche crowd and conversations for you with much less effort.
Self-hosted personal blogs were always ghost towns. Always.
In this case though, this is a branded tech blog, posted to HN (and maybe to Reddit?). It doesn't make a difference, if the endpoint is medium, or a self hosted blog, or a hand written HTML on an FTP server.
Re: Our experience launching a paid, proprietary product on Linux
#84The big thing I see missing from all this analysis is the home vs. work distinction. You have people saying "Linux users choose FLOSS because of philosophy, and proprietary software goes against this", you have users saying "I'd have tried it if it were FLOSS and I could just download it and try it", etc., but the problem is: this is a product for working with an Exchange server. How many individual users have a need…
That's a very good point. This tool is purely focused at people who use Linux at work, the dynamics are very different. The article should probably mention something about that.
Re: Our experience launching a paid, proprietary product on Linux
#85> And before you cry “support model!” — it isn’t going to work for us — our product simply doesn’t require that much support.
Indeed, a well-designed product aimed at people who would balk at putting the product’s name on their CV shouldn’t.
Re: Our experience launching a paid, proprietary product on Linux
#86Completely unrelated to the contents: Please, publishers, I beg you: walk away from medium. It's terrible for us, your readers. Set up a static blog, with a domain, go WordPress, Grav, Typo3, anything, but without stupidly large sticky header/footer and without heavy javascript . EDIT: apparently 121KB javascript is not heavy. I still believe it's an overkill for 30KB content.
I don't think 121 kb is a lot, as people nowadays demand rich media content, and even a lookup on the native Yelp app can be thus expensive.
121KB Javascript. I wasn't counting the images - the actual, rich media -, or the content itself.
Once, it's fine, but this is a singe page with 121KB. Forget the in-browser cache myth: it may have been true the jquery got included directly from a cdn, but in the era of compiled JS apps, it's long gone, meaning it's 121KB JS for every medium page you visit. It climbs quickly, especially on capped smartphone data plans.
Re: Our experience launching a paid, proprietary product on Linux
#87Quite a neat insight and somewhat confirming what I think personally; Linux users largely don't use Linux for FLOSS reasons. People who do use Linux for FLOSS reasons are however rather loud. I would probably not be wrong when saying that most Linux users will happily pay a developer for the binary of an application if the dev is "doing it right". Doing it right largely involves "don't treat the customer as a walking…
As one of the "Linux for FLOSS" users--and, yes, quite loud about it--I am inclined to agree. I would pay good money for a high quality application on Linux. But in large part, one of the less-philosophical, more-practical things that I value about FLOSS is the opportunity to fix things if something doesn't work right. While I would gladly purchase an incredible, closed source application, I would much more value the…
That would be another options, yes, though I don't think I've seen many employ source-available while also giving access to a working build chain/script.
Re: Our experience launching a paid, proprietary product on Linux
#88The big thing I see missing from all this analysis is the home vs. work distinction. You have people saying "Linux users choose FLOSS because of philosophy, and proprietary software goes against this", you have users saying "I'd have tried it if it were FLOSS and I could just download it and try it", etc., but the problem is: this is a product for working with an Exchange server. How many individual users have a need…
Yep, totally agree with you there.
After reading the article that was my first thought when he mentioned adding support for Google IMAP.
Full stop. Don't do it. You have a product that is doing well as the solution for something with a clear business case that's not well addressed elsewhere. Own that market and focus your development attention on that Exchange ecosystem.
As soon as you branch to IMAP/Gmail/General purpose you're going to be in the sea of tons of other email clients, most of which are free. It's going to dilute the value proposition for Hiri because Hiri is going to become "another email client" that also supports exchange. The taste for email clients that add exchange support is not generally a good experience. It also means that you have to ensure all of your UI elements work equally with both, bringing you to more of a lowest-common-denominator experience.
When I see Linux Exchange Email Client and that's all you do, I see specialty software that I can rely on to solve that problem correctly. When I worked at a company that used Exchange, I would have bought it IMMEDIATELY and convinced my boss to reimburse me later.
As soon as you become a general purpose email client, everything about what you offer to solve that problem starts getting lost in the shuffle.
Re: Our experience launching a paid, proprietary product on Linux
#89Earlier quoted context omitted.
I don't think 121 kb is a lot, as people nowadays demand rich media content, and even a lookup on the native Yelp app can be thus expensive.
121KB Javascript. I wasn't counting the images - the actual, rich media -, or the content itself. Once, it's fine, but this is a singe page with 121KB. Forget the in-browser cache myth: it may have been true the jquery got included directly from a cdn, but in the era of compiled JS apps, it's long gone, meaning it's 121KB JS for every medium page you visit. It climbs quickly, especially on capped smartphone data plan…
[deleted]
Re: Our experience launching a paid, proprietary product on Linux
#90Quite a neat insight and somewhat confirming what I think personally; Linux users largely don't use Linux for FLOSS reasons. People who do use Linux for FLOSS reasons are however rather loud. I would probably not be wrong when saying that most Linux users will happily pay a developer for the binary of an application if the dev is "doing it right". Doing it right largely involves "don't treat the customer as a walking…
> I would probably not be wrong when saying that most Linux users will happily pay a developer for the binary of an application if the dev is "doing it right".
Hm, this reminds me of the Caddy, the HTTP server with Let's Encrypt integration. It's still open source, but a while ago they made the binaries paid (if you want it for free you need to compile it yourself). They got a lot hate for that; people were even accusing them of having become closed source.