I was looking to port over our homegrown django blog app into a proper blogging engine and I immediately though of Medium because of HN conditioning, and had so many problems with it, all of them boiling down to lack of control: No way to embed stuff we wanted (we wanted to embed interactive graphs and tooltips), no way to disable some bullshit features (highlight popups), no way to get our own domain name, etc.
Ghost solved all this. And on top of that, it's markdown, which makes it just fantastic. And open source. And self-hostable. And you guys run a wonderful, exemplary foundation behind it. I have nothing but admiration for what you do, and I'm proud to be a paying client for it and recommend it to anyone for company blogs (it is unfortunately expensive for personal stuff however).
My #1 wishlist for it is better image embedding/resizing/thumbnailing support (native image gallery & captions, native thumbnailing, automatic thumbnailing of hero headers for the article list view).
My #2 wishlist is Postgres support. I'm very sad you dropped support for it :(
I use Postgres for other things, really don't like having to have a separate MySQL setup just for ghost...
> Developers regularly show up on Github, rage at us for something like not supporting Postgres - and then we say "ok so are you going to write and maintain Postgres support for Ghost?" and they say "of course not, I don't have time for that!" - and then occasionally they'll go on Twitter and tell all their followers to give us hell. As if organising a mob and shouting louder is the best way to get a bunch of people writing free code to do what you want.
So, I guess I agree that his intent could be more clearly stated.
A question: Do you think your choice of technology stack (JavaScript, node.js) played a part in your success?
I've read many times from product creators that developers wildly overestimate the importance of choosing a language or technology stack when in fact it has little bearing on whether a product will succeed.
Do you have any thoughts on this topic?
When it came to selecting Node, the biggest benefit was that it was notable. If we had said "HEY we're making another blogging platform in, wait for it, PHP!" -- it would likely have been significantly more difficult that the project would've been seen as noteworthy / attracted any users.
Conversely, Node is not without its drawbacks. The ecosystem is young today. It was positively infantile when we started. I don't even think there was a fully formed RSS library. In fact, from a technical point of view, most of what we've built would have been easier to achieve with other tools and frameworks.
Nowadays when we select technology, we tend to go for the oldest most reliable stuff we can find. The sort of stuff that when you have a problem and you google it, there are 5,000 people who have done it before. Because there are only SO many innovation battles you can fight simultaneously.
At one point we tried to rewrite our infrastructure using Docker/Swarm - it was a 9 month project which ultimately got completely cancelled at the last minute. Why? Turns out Docker Swarm doesn't scale above 500 instances and we needed to run about 10,000 for Ghost(Pro). We asked Docker Inc and their response was pretty much "idk lol". So now, especially with our infrastructure, we almost always select the most tried and tested technology. Boring stuff. Stuff that is very, very well understood.
The problem is, it's not cool to talk about how our infrastructure is built on very straightforward LXC containers, managed by HAProxy, connected to a cluster of MySQL servers. The tech isn't bleeding edge enough to hear about on HN, so you end up not hearing about it. But most of our best tech decisions end up being when we choose older technology.
Sorry, this got really long. Did Node.js influence our success? Yes! It made Ghost more popular and also more difficult to build. Would I change it? Definitely not.
Which is fine. "can execute binaries in isolation" and "can schedule rollouts and efficient disk/networking structures across many thousands of instances" are vastly different problems. Even "can deploy to 100s" and "can deploy to 1000s" are quite different, without something targeting 1k+ I wouldn't expect it to handle beyond a couple hundred without compounding issues.
And those are exactly the ones I want to hear about.
Like you I find the old, established tech choices to be good. New tech is fun to play with, but when I need to get work done and keep it running (for years) I take old every time.
Please write more on this!
Also, I like the interplay between new/risky tech in one area of your story and established in others. Pushing a manageable number of boundaries.
Beyond that point, we can spend money on anything which reasonably furthers the mission of the organisation - which has many aspects but the main ones in our case revolve around creation and education for journalism and open source software.
Some pipedream ideas we throw around from time to time:
- M&A (boring/obvious answer, but valuable)
- Create either grant-funding, or sensible investment funding (like indie.vc) for other open source projects and publishers.
- Create an independent media company, reporting on issues and stories we care about (running on Ghost)
- Buy some land and build a collaborative space for us and for others to work on open source, journalism and social good projects
1. Build more tools that solve people's problems created by others vendors. As in, move sideways a bit diversifying your operation. Even better if the tools/apps complement each other where you can increase benefit per customer while cross-selling. Although not endorsing them (not a customer), Zoho seems like a good example of this where they keep developing additional products that might benefit their customers on top of their original ones. Enough FOSS-oriented non-profits doing that in enough sectors can stop a lot of lock-in and abusive practices over time via the alternatives they provide.
2. Invest in maintenance or security improvements of dependencies, esp libraries or infrastructure. These are often treated as externalities leading to a lot of problems we see like in report below [1]. Ghost could deliver its good products/services on top of taking some responsibility for infrastructure it depends on. People buying Ghost get the immediate value plus knowledge they're supporting those things as well.
Just some ideas for you. Keep up the great work over there and good luck to you all! :)
[1] https://medium.com/@nayafia/how-i-stumbled-upon-the-internet...
So, a ghost town?
Some things which come to mind:
- lower prices
- hire more staff to provide new features
- make everything faster and more reliable
- provide more free services
- give everyone raises
- donate to charities which are reasonably related to the aims of the non-profit
- make investments to improve the long-term financial health of the non-profit.
Besides actually just reducing prices for services to not get profit, Ghost could create a foundation and give grants to any deserving work that serves the Ghost mission, such as supporting the FSF or EFF or funding other upstream or aligned stuff such as working to get more of their tools to be 100% free/libre/open…
Upgrades are painless, typically requiring around an hour at most. If there are bigger framework changes we can usually upgrade immediately then clean up deprecations later as necessary but even then the work is normally minimal. When there are more stylistic changes that touch many files it's usually very quick work thanks to the codemods that are released alongside. All of this despite huge and continuous under-the-hood improvements in Ember since we've been using it.
Compared to what I've seen in other frameworks I think we've benefitted a lot in being able to spend pretty much zero time bike shedding which libraries will make up our core framework. We also save a lot of time not needing to upgrade disparate parts of a custom framework built of 3rd party libraries that aren't necessarily in sync with each other. The Ember addon ecosystem has also been stellar, with common solutions rallied around by the community such that they are usually as stable as core and kept up-to-date with the latest idioms without breaking backwards compatibility.
In conclusion Ember has allowed us to focus almost entirely on product rather than framework. It stays out of the way and provides very clear happy paths for typical workflows whilst allowing us to break out of those where needed without sacrificing any tooling or upgradability.
As for the downsides I think the biggest has been the limited pool of contributors. A lot of react bandwagon jumping has happened since we started with Ember and it's interesting when talking to other developers outside of the Ember ecosystem because there's a lot of historical and outdated views about what Ember is and isn't. The Ember core team and community is working hard to improve Ember's marketing message to counter that but it's tough to break through when the framework's core selling point is consistency through hype cycles.
Another question: are there any aspects of your product that are open core? Does the SaaS have any "special sauce?" Thanks.
For one, it's not an American company, is it?
In the early days there's no structure, you just get on with it. As the company grows, generally a board of directors (or non-profit: board of trustees) act as an independent governance level for the org above the exec team and (amongst other things) determine executive pay.
[1] https://twitter.com/JohnONolan/status/941572225890533376 [2] https://ghost.org/features/ [3] https://i.imgur.com/b5OO3Q6.png
And then, to back up your argument, you link to a page which is not running on Ghost - and actually does have optimised+responsive images.
All so you can spam your own image compression app.
Without a trace of irony.
Are you serious.
The HN Guidelines, which specifically prohibit this kind of content, can be found at https://news.ycombinator.com/newsguidelines.html
This whole sentence is false. I did not "bully" you anywhere (!), requested a feature from you, or pressured you to do anything. Quite the opposite, I showed an easy way to improve. Again, I could have been wrong on the effect. That's why the question. The "spotlight" reference was just a small joke. Sorry.
> And then, to back up your argument, you link to a page which is not running on Ghost - and actually does have optimised+responsive images.
I meant only the Ghost homepage in the link, and better optimization (proves [1]).
> All so you can spam your own image compression app.
I gave you the facts. Yet, you smeared me with false accusations. Is this even fair?
[1] https://github.com/vmdanilov/optimage/files/2011804/ghost.zi...
HN seems to cut the link text.