[x4e]

I self-hosted a writefreely instance for a while but I found many features were proprietary and only available in the paid managed hosting (write.as). All features that I didn’t need that much and could workaround however it just made me feel quite dissatisfied with the project.

People self hosting are not likely to be the same people who would pay for managed hosting so it makes no sense to lock features off for them.

I forked the codebase and added stuff myself for a while because even after funnelling users to their commercial option they still do hardly any development, see how long this one line PR I made took to be merged: https://github.com/writefreely/writefreely/pull/429.

Now I just have a simple python script that makes everything I need in a blog [0] (markdown, resources, mathjax, atom feed and all completely static with no JS). There is no need to have complicated blog services, just compile static html.

[0]: https://github.com/x4e/Blog/blob/master/make.py

[thebaer]

Just curious, which features did you want that were proprietary at the time?

The primary reasons for including certain features in Write.as but not in WriteFreely are when they're very early (it's easier to deploy and fix on a single hosted service), or when they involve a ton of external dependencies. My thinking on the latter is that I'd rather leave a feature out than leave admins with a poor experience, vendor lock-in, lacking documentation, etc. But maybe that's the wrong way to think about it.

Either way, "locking features off" isn't a business strategy here, but just a matter of practicality as a very small open source project. As I mentioned elsewhere, we plan to bring things into parity for v1.0. And we very much welcome contributors -- even if it's just reviewing pull requests!

[x4e]

It was a while ago but the ones I remember were email subscriptions, custom javascript, and custom instance support in the iOS app.

Thank You for clarifying the reasoning. That does make more sense and makes it more justified. I still think it would be better to at least have the write.as fork be open source even if you can’t ensure stability/any sort of support.

[eitland]

As you see below somewhere I say nice about you but I must also say there are some things I'd really want to see fixed soon:

- make inclusion of photos, including from snap.as kind of usable (yes, I'm a paying customer)

- fix statistics

On the bright side I can now see who follows me, instead of just a number like it was for a long time.

[donmcronald]

I really dislike how open source has evolved over the last decade. A lot of open source isn't much more than a feature anemic demo and IMO is only there so companies can generate sales leads. Getting good quality bug reports or contributions from the "community" members (aka suckers) are a bonus.

I don't contribute to projects that have stripped down, almost unusable versions for their open source variant and that's most of them. Years ago I saw someone on HN say something like "charge for features or scale, not both." Personally I think that should be "charge for scale, not features."

I like the way Drone.io has done their licensing so far, even after being bought by Harness. Before, it was something like "do what you want if you have less than $1 million in revenue." Now, with Harness.io it appears they've settled on charging for scale. When I looked at their pricing a couple days ago it says the "free" (open source) version is limited to 1 server. I'm not sure how that works (or how they enforce it), but the main thing IMO is they don't appear to limit features. I can actually use it without reading their feature tiers like it's an API that changes every time the marketing department waffles on the pricing.

I think the current models for pricing SaaS suck and Harness is closer to a model that makes sense. For me, the reality is that I only want 2 tiers; free where I self host and SaaS where I pay someone to do it. The problem is they always want to charge enterprises more per user which makes sense since it's harder to scale and support to the level needed.

IMO, just have 2 tiers; free, self-hosted with full features and community support and paid, but with a different pricing model that's based on user count and support. For example, give the first user for free with community support. You always keep the price for lower tier users. Give the next 4 users for a low cost with email support. Give the next 20 ish users for a mid-tier cost with phone support. Make the remaining users the price you actually want with priority support.

That brings the cost average down for small users and makes it much more attractive to adopt a product. The pricing curve looks more like a camels hump (assuming you negotiate if you're huge) instead of a staircase (like GitLab) where you hit pricing cliffs that are tough to swallow.

[indigodaddy]

As far as a OSS citizen, I think Caddy is a good example.