RIP Jekyll (The Genesis of the Jamstack)(bridgetownrb.com)
bridgetownrb.com
RIP Jekyll (The Genesis of the Jamstack)
https://www.bridgetownrb.com/future/rip-jekyll/
180 comments
In my view, your best course of action now would be to apologize, retract your article, and start mending fences.
What do people use besides Jekyll?
Ive been using Hugo
I've been using Hugo as well. I used Pelican (Python port of Jekyll) for a long time, but Hugo is so much more performant and has a larger ecosystem at this point.
The main downside is that the Hugo documentation is sometimes terse and snarky.
The main downside is that the Hugo documentation is sometimes terse and snarky.
With regards to performance, I used Hugo like 3 or 4 years ago now, and it was insanely fast!
Compared to really sluggish build times with Jekyll/Ruby it was incredible!
Some sites went from 10s of seconds to what felt like instant build!
However, with new versions of Ruby and M1 Macs, I dont notice build lag in Jekyll anymore!
And overall, I much preferred Jekyll and the way it structured sites, template and includes! :-)
Compared to really sluggish build times with Jekyll/Ruby it was incredible!
Some sites went from 10s of seconds to what felt like instant build!
However, with new versions of Ruby and M1 Macs, I dont notice build lag in Jekyll anymore!
And overall, I much preferred Jekyll and the way it structured sites, template and includes! :-)
I switched my blog from Jekyll to Pelican recently after getting sick of constant ruby package versioning issues. It’s pretty nice, though maybe not as good for getting your site to appear on google search
https://www.11ty.dev/
I'm doing a non trivial project with eleventy in my free time -- works well.
I'm doing a non trivial project with eleventy in my free time -- works well.
My work has moved largely from Ruby to JS, so I've been enjoying Gatsby! It's probably overkill for simple sites, but I like how customizable it is.
For React-based projects, I would advocate for Next.js…but yeah, unless you know you need React for very specific reasons, it's definitely overkill. =)
Next.js is cool, but afaik takes a server, right? Gatsby is nice because you get React for component re-use + styling, but it builds into regular HTML+JS files and can live on (abundant, free) static site hosts.
It's primarily used with a server, correct. However, you can use `next export` which will generate only static assets (like HTML, JS, and CSS). Certain features aren't available that require a server (like i18n routing) but you can still do a lot!
I use Pandoc and a few lines of nodeJS code.
Hugo. I did find creating my own theme to be a bit of PITA due to the lack of documentation but once I got over that hump it's smooth sailing.
I use hexo. It’s node and not super popular, but it does what I need and I’ve built my workflows around it so alost everything is done by cli (bash, imagemagick and hexo).
It can be seen here:
https://chrisbergeron.com
It can be seen here:
https://chrisbergeron.com
Jekyll. It ain't broke, so why fix it?
Publii CMS for simple static blogs and sites in which clients will manage the content themselves.
Instead of a traditional static site generator, put some content at /colophon that lists the transformations that need to be applied to produce the desired output, and then have a machine perform those steps.
This "machine [that] perform[s] those steps" sounds exactly like it is a static site generator.
Yes, that is the intended meaning. This static site generator is non-traditional; it should live as first-class content on one of the pages of the site it outputs. This is not the way traditional static site generators work, although they should.
Sounds like a fucking weird place to keep it, so I don't think they should.
Not weird to suggest that an organization's website should serve as that organization's knowledge repository. Weird is the tradition of building out websites that are little more than Potemkin villages for the entity they represent. A Engelbart-style DKR <https://www.dougengelbart.org/content/view/190/> is certainly not bizarre as willingly participating in the inconvenience of relying on out-of-band documentation like a README that exists only in the source repository that lives on, say, GitHub, and a set of scripts/binaries that you have to download/install/configure separately and whose esoteric conventions you will have forgotten by the next time you try to update the site a year and a half later <https://corytheboyd.com/posts/2020-03-09>—or worse, you find those tools no longer work, even though you do remember how to use them.
Template::Toolkit (Perl) and Middleman (Ruby).
I was just researching static site generators and the ones that piqued my interest were:
* Hugo
* Eleventy
* Zola
Note that I excluded ones that output SPAs since I just want plain old hand-written HTML.
Jekyll’s biggest hurdle for me was installing a Ruby environment.
* Hugo
* Eleventy
* Zola
Note that I excluded ones that output SPAs since I just want plain old hand-written HTML.
Jekyll’s biggest hurdle for me was installing a Ruby environment.
I should have added that static site generators are ranked by popularity (i.e. stars) here:
https://jamstack.org/generators/
https://jamstack.org/generators/
I wrote my own static generator in Python using Jinja2. It's very minimal but it works well enough for me. It may not scale well when there are hundreds/thousands of files but it will take a long time for me to hit that.
I built a blog with metalsmith years ago. I decided to resurrect it recently and, though I tried, I could not find anything to beat its simplicity. A JSON file provides the flow, plugins do the work. Only thing against is that the plugins encourage developers to create multiple and largely undesirable node dependencies.
I switched from jekyll to elder.js.
I loved Jekyll, and still do. This is a sad state, and I hope both that it improves and Jekyll survives.
I switched to Zola for most of my stuff a while back, and while there are still gaps, it does everything I need and is production ready.
https://www.getzola.org/
I switched to Zola for most of my stuff a while back, and while there are still gaps, it does everything I need and is production ready.
https://www.getzola.org/
Oh interesting, that's a Rust-based SSG. Definitely something nice about a single binary and not needing a full language runtime installed.
Absolutely. I started using Zola after writing my own solution, Zola seemed like the next best step up. It has a lot of good, but it also requires a lot of setup to get going. If you don't care about making your own theme, it's easy to get going and start up a new site, but past that, it's very fast to compile files and comes with image transforms for additional resizing needs.
> a single binary
Well, one program to generate the site, and then an implicit assumption that you'll use another program (your Web browser) at some point to verify the output.
If you're into cutting out prereqs when you can, why not cut out one more?
Well, one program to generate the site, and then an implicit assumption that you'll use another program (your Web browser) at some point to verify the output.
If you're into cutting out prereqs when you can, why not cut out one more?
...what's offensive about this?
I wasn’t offended (and I didn’t downvote you) but I failed to see the point you made. Feel free to elaborate. I don’t understand why you mentioned the web browser. Don’t we all take for granted that the user will utilize a web browser to access a website? Be it Chrome or Lynx.
> Don’t we all take for granted that the user will utilize a web browser to access a website?
That is my point.
If it is a given that Runtime A is going to be involved, and your angle is to tout the benefit of binary B being to let you to eliminate Runtime C, why even settle for now needing to rely on B? Why wouldn't you try to avoid it as well? Just use A.
That is my point.
If it is a given that Runtime A is going to be involved, and your angle is to tout the benefit of binary B being to let you to eliminate Runtime C, why even settle for now needing to rely on B? Why wouldn't you try to avoid it as well? Just use A.
Presumably because generating your site with B was faster than writing HTML directly.
...where does "writing HTML directly" come from? We're still talking about using a static site generator, whether Runtime A and Runtime C are being used, or Runtime A together with binary B, or just Runtime A.
From the same place as your:
> If you're into cutting out prereqs when you can, why not cut out one more?
You can't cut out the browser, so the only thing left was that single binary you first replied to.
> If you're into cutting out prereqs when you can, why not cut out one more?
You can't cut out the browser, so the only thing left was that single binary you first replied to.
> cut out [...] the single binary
That's a correct reading of my comment. To take that to mean, though, that you should start "writing HTML directly" is a logical leap—and one that happens to turn out to be wrong; it's not something I wrote, and it's not even something I implied. It's an incorrect reading of my comment.
That's a correct reading of my comment. To take that to mean, though, that you should start "writing HTML directly" is a logical leap—and one that happens to turn out to be wrong; it's not something I wrote, and it's not even something I implied. It's an incorrect reading of my comment.
Correct or not, I would assume it's the reading everyone made. We all read in good faith and write in good faith, but if everyone misreads something you write, either everyone else has to try harder to decipher it or you can perhaps try to phrase it in a way that's less ambiguous.
You missed the "logical leap" part. It was a big logical leap—bordering on nonsensical which you pretty much acknowledged in your first response. If, when reading someone's comment, your first instinct is to say to yourself, "How could someone think that's a good idea?" then your second thought should be, "Yeah, how could someone think that? I'll bet they don't." This isn't Twitter; replying to a comment as if, out of the range of possible interpretations, what the author intended was the dumbest one—just because you can plausibly argue that's what their words really meant—is pretty much against the rules.
> I would assume it's the reading everyone made
Even after what just happened, you're still making assumptions?
> We all read in good faith
That's disputable. Actual observed behavior on HN lately seems to trend towards the easiest/shortest path to dismissal, or: How can I reaffirm that someone I want to disagree with is dumber than I am?, again à la Twitter.
> phrase it in a way that's less ambiguous
Okay, I'll bite. How should it have been phrased? By the time you had written the comment prior to your most recent one, I had already posted two other comments that were pretty damn specific, one of them excruciatingly so:
<https://news.ycombinator.com/item?id=28524423>
<https://news.ycombinator.com/item?id=28518839>
What you're demanding is to spend an inordinate amount of effort seemingly to optimize for folks who are some combination of (a) subject to guardrails on their thoughts but silent about it, (b) themselves unwilling to put two seconds' consideration into an idea posted on a site explicitly meant for curious discussion, and/or (c) possibly deliberately uncharitable/hostile. <https://pchiusano.github.io/2014-10-11/defensive-writing.htm...>
> I would assume it's the reading everyone made
Even after what just happened, you're still making assumptions?
> We all read in good faith
That's disputable. Actual observed behavior on HN lately seems to trend towards the easiest/shortest path to dismissal, or: How can I reaffirm that someone I want to disagree with is dumber than I am?, again à la Twitter.
> phrase it in a way that's less ambiguous
Okay, I'll bite. How should it have been phrased? By the time you had written the comment prior to your most recent one, I had already posted two other comments that were pretty damn specific, one of them excruciatingly so:
<https://news.ycombinator.com/item?id=28524423>
<https://news.ycombinator.com/item?id=28518839>
What you're demanding is to spend an inordinate amount of effort seemingly to optimize for folks who are some combination of (a) subject to guardrails on their thoughts but silent about it, (b) themselves unwilling to put two seconds' consideration into an idea posted on a site explicitly meant for curious discussion, and/or (c) possibly deliberately uncharitable/hostile. <https://pchiusano.github.io/2014-10-11/defensive-writing.htm...>
I’m afraid I don’t follow. If I have Firefox + dependencies installed, how would that help me to generate a static website that’s written in Markdown?
The same way that a "JAMstack" static site generator like Hexo, Jekyll, etc that requires some additional Runtime Cₙ, Cᵣ (or binary B or so on) helps you generate a static website from Markdown—except you're using a static site generator that instead targets the Runtime A (i.e. Firefox or Chrome or whatever browser you want) that we have quietly assumed is already available and is going to be used at some point, anyway.
From <https://news.ycombinator.com/item?id=24495646>:
> [There is] a "packager" for putting together add-ons. It uses "node.js". All it really does is apply "zip" to some files. I tried to install the "packager" on Ubuntu 18.04 LTS. It had several hundred dependencies, and wouldn't run because of some version dependency in node.js for something totally irrelevant to the task at hand
From <https://news.ycombinator.com/item?id=28518839>:
> If folks were really committed to improving the developer experience, [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html
See also: <https://news.ycombinator.com/item?id=28407936>
From <https://news.ycombinator.com/item?id=24495646>:
> [There is] a "packager" for putting together add-ons. It uses "node.js". All it really does is apply "zip" to some files. I tried to install the "packager" on Ubuntu 18.04 LTS. It had several hundred dependencies, and wouldn't run because of some version dependency in node.js for something totally irrelevant to the task at hand
From <https://news.ycombinator.com/item?id=28518839>:
> If folks were really committed to improving the developer experience, [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html
See also: <https://news.ycombinator.com/item?id=28407936>
I use Zola for my project website. As someone who had never built a website before, I tried several static site builders but only really succeeded in getting a tweakable theme working with Zola.
Will Bridgetown support current Jekyll themes?
This is a pretty important question. The themes are the main reason I continue to use Jekyll
> While Bridgetown has diverged somewhat from Jekyll in terms of architecture and is not source compatible (for example plugins and themes)
Based only on what I've heard, but my understanding is it's not a huge undertaking to port over
Based only on what I've heard, but my understanding is it's not a huge undertaking to port over
Only with a few modifications …we're nearly through a stint of addressing tech debt, and then we plan to publish a guide for porting over Jekyll themes out for to make this process much more clear.
Personally I don't find static site generators worth the effort to learn or keep up-to-date as versions inevitably come. I end up just writing my own for each site in 1-200 lines of Python. It's normally just a markdown library and a template engine wrapped with a file system walker.
Here's an example: https://github.com/eatonphil/notes.eatonphil.com/blob/master.... It's longer than usual since it embeds parts of the home page html inside it.
These scripts last for years and only change slightly over time. Very low maintenance.
Here's an example: https://github.com/eatonphil/notes.eatonphil.com/blob/master.... It's longer than usual since it embeds parts of the home page html inside it.
These scripts last for years and only change slightly over time. Very low maintenance.
You don't find them worth the effort, but you wrote your own?
The popular static site generators all accommodate very large sites. Which is great, but it can them very time consuming to learn if all you want to do is throw up some blog posts.
Writing a small static site generator for a personal site can be done in an afternoon, and it's fun.
Writing a small static site generator for a personal site can be done in an afternoon, and it's fun.
Nanoc fills this niche quite well. It's more of a SSG toolkit than an SSG.
You build a Rules file with steps for each of your file types and it loops through and builds your site. It comes with Markdown out of the box but you can make it do just about anything.
https://nanoc.app/
You build a Rules file with steps for each of your file types and it loops through and builds your site. It comes with Markdown out of the box but you can make it do just about anything.
https://nanoc.app/
Pandoc + Makefile is enough.
https://github.com/ivanstojic/pandoc-ssg/blob/master/Makefil...
https://github.com/ivanstojic/pandoc-ssg/blob/master/Makefil...
Updated to clarify that it is the time it takes to learn and the upkeep over time that I find not worthwhile.
At that point why wouldnt you just write HTML? That would last basically forever and it's I think less hassle than hacking together a blog renderer.
I'm not the GP but if HTML supported client side includes then that would be enough for most of my sites.
How often has markdown changed over the years?
The markdown library I use has not changed its API in over 3 years at least.
The only reason this script is more than two lines of markdown-related code is because I wanted to store headers for other things.
This script is the most complex of my SSGs because I write on this blog the most. But even then it's only 200 LoC which is still (to me) surprisingly small.
Other of my SSGs are even simpler and have no markdown renderer: just jinja and file walking code.
So I'm not really sure which part of <200 LoC and no upstream changes you consider a hassle.
The markdown library I use has not changed its API in over 3 years at least.
The only reason this script is more than two lines of markdown-related code is because I wanted to store headers for other things.
This script is the most complex of my SSGs because I write on this blog the most. But even then it's only 200 LoC which is still (to me) surprisingly small.
Other of my SSGs are even simpler and have no markdown renderer: just jinja and file walking code.
So I'm not really sure which part of <200 LoC and no upstream changes you consider a hassle.
> Open source in 2021 looks like:
> Engagement on Twitter
> Official Discord chat room
Cherry picked from a list with 4 others elements that I agree with, but the first two are terrible. Twitter is getting more and more closed (you can't see some stuff without being logged in now) and for Discord you have to create an account to see the content. Both are not free software. Reading stuff around free software shouldn't require an account on a proprietary platform.
> Engagement on Twitter
> Official Discord chat room
Cherry picked from a list with 4 others elements that I agree with, but the first two are terrible. Twitter is getting more and more closed (you can't see some stuff without being logged in now) and for Discord you have to create an account to see the content. Both are not free software. Reading stuff around free software shouldn't require an account on a proprietary platform.
Well if you want to reach lots of developers, you have to be where they are, and they're on Twitter and Discord—for better or worse. :shrug:
They're just the noisy developers who haven't found their hyperproductive niche. Once you've found your perfect tech stack, you just keep using it and stop making noise about it, and then your voice no longer gets counted. But that doesn't matter, because the work gets done, the code goes out, and the money comes in.
Mastodon and Matrix instead?
No one is on Mastodon or Matrix.
Im on both. Mastodon has a busy busy community making the future of RSS and podcast feeds that I'm a big fan of, super welcoming people. Golang matrix has saved my bacon too many times to count, also great folks there.
The best part about these, is that though we step off topic sometimes, generally everyone is really helpful and focused on the general subject matter. It's not endless gossip, in jokes and memes, these people actively find new faces, and then find places for them to fit in the community and things to take ownership of.
These smaller networks are a rare type of community, and I love it.
The best part about these, is that though we step off topic sometimes, generally everyone is really helpful and focused on the general subject matter. It's not endless gossip, in jokes and memes, these people actively find new faces, and then find places for them to fit in the community and things to take ownership of.
These smaller networks are a rare type of community, and I love it.
Can you tell me which are these communities on Mastodon working on RSS and podcast feeds? I happen to be doing work related to both, currently, and would like to check them out.
You can help change that situation by joining the million or so Fediverse users or improving the platform instead of publicly dismissing it because it doesn't have a billion dollars in funding. It's quite easy to put together a feed with an update a minute if you really want that much activity.
Why would I do that?
Ladies and Gentlemen, the network lock-in effect in action.
Humour aside, you would do it if you wanted to encourage movement of the closed silos. It's not likely that your irl friends and family will make the jump anytime soon, but getting dev communities to make the switch is a much more tractable problem.
Humour aside, you would do it if you wanted to encourage movement of the closed silos. It's not likely that your irl friends and family will make the jump anytime soon, but getting dev communities to make the switch is a much more tractable problem.
I certainly wish people were on Mastodon (haven't tried Matrix yet). I ran a Mastodon instance for some time. The experience was decent but discovery was terrible, and discovery is what makes Twitter (for example) so compelling.
Not for mainstream projects - plus those places tend to become political mudwaters, because freedom in tech has become political the past few years.
Agreed about Mastodon, unfortunately.
But that has not been my experience with Matrix.
But that has not been my experience with Matrix.
Elixir and OCaml mostly use a forum and it works well. Everyone can read it, it's easy to post on it, it's easy to moderate it, and it's great when you want to search for things. I don't think microblogging and instant messaging are what an open source community needs.
Sure, but hiding public discussions about your open source project behind a Discord server is a really bad idea. The goal of these things is to also act as a public repository for knowledge, and by using Discord you fail at that part.
Mailing lists are not bad, as well as the issue tracker on GitHub.
Giving into the status quo is not going to change it. Free software projects aren't really free they make people sign up for nonfree platforms to collaborate.
The biggest projects are typically on IRC, mailing lists, and online forums. Linux, ffmpeg, practically every Linux or BSD distro, Git, nginx, postgresql, systemd, neovim, Freedesktop, etc.
Practically none of the software I use on a daily basis has a significant Discord presence.
The biggest projects are typically on IRC, mailing lists, and online forums. Linux, ffmpeg, practically every Linux or BSD distro, Git, nginx, postgresql, systemd, neovim, Freedesktop, etc.
Practically none of the software I use on a daily basis has a significant Discord presence.
The biggest projects have enough momentum that they can be on whatever communication channels they want - if Linux decided to switch to avian carriers tomorrow, they'd still have thousands of people talking over that.
>neovim
Neovim is on twitter, and doesn't have a mailing list. They also offer matrix and IRC (presumably bridged). See https://neovim.io/community/
>neovim
Neovim is on twitter, and doesn't have a mailing list. They also offer matrix and IRC (presumably bridged). See https://neovim.io/community/
You're right, but many of the newish projects are on Discord: Rust, Julia, Deno... I've seen many others that I can't remember now.
The Discord chat room is very little different from the (RIP) freenode channel. Sure, you need to create an account, but that's where communities are built nowadays - in closed groups that can be controlled, moderated properly, and automated, while still being a fun and friendly environment to chat in. It does that well.
Github is not open. All the things listed there are costly, in one way or another. There's nothing free about anything that makes up open source today. Open source became corporate some time in the late 00s. And while I don't agree with the author (including the fact that he calls the new product Ruby-powered, not Impaired by Ruby), I do agree with that strange assessment that open source communities work that way.
Github is not open. All the things listed there are costly, in one way or another. There's nothing free about anything that makes up open source today. Open source became corporate some time in the late 00s. And while I don't agree with the author (including the fact that he calls the new product Ruby-powered, not Impaired by Ruby), I do agree with that strange assessment that open source communities work that way.
You can read Github without creating an account. You can't do that with Discord and it's becoming harder with Twitter. Discourse forums can be read without an account too. I agree that we should be careful of Github too.
> Engagement on Twitter
> Official Discord chat room
No. Not at all. Many very popular OSS projects don't use Twitter or Discord. Any time you say "all OSS projects use technology X", be it GitHub or Twitter or whatever, the only thing you can be sure of is that the statement is wrong. Some projects may, sure, but that's different.
Probably the only "technology" you can say they generally use is a web page.
It is reasonable to say "they have 1 or more ways to interact, and that's clearly identified on their web page". But assuming that everyone uses the same communication mechanism is demonstrably false.
> Official Discord chat room
No. Not at all. Many very popular OSS projects don't use Twitter or Discord. Any time you say "all OSS projects use technology X", be it GitHub or Twitter or whatever, the only thing you can be sure of is that the statement is wrong. Some projects may, sure, but that's different.
Probably the only "technology" you can say they generally use is a web page.
It is reasonable to say "they have 1 or more ways to interact, and that's clearly identified on their web page". But assuming that everyone uses the same communication mechanism is demonstrably false.
Don't disagree but tbf he also said:
> Lack of any one of these points isn’t the end of the world, but at the present moment, Jekyll lacks ALL of them. That’s a real problem.
I think the point is that most projects will engage with the public in at least some of these ways.
> Lack of any one of these points isn’t the end of the world, but at the present moment, Jekyll lacks ALL of them. That’s a real problem.
I think the point is that most projects will engage with the public in at least some of these ways.
That's true, but I don't see how Jekyll would be improved with a Twitter and a Discord.
Yeah, I almost choked on my lunch when I read that. In addition to your well-said reasons, it just seems icky. In my not-so-humble opinion, Twitter (among others) has become a harmful echo chamber of dangerous ideas and hypocrisy. Requiring the use of Twitter is not a good signal to send.
I'm not sure why you're getting downvoted here, twitter is a pretty user-hostile platform for anyone who doesn't have an account, or you're a mobile user who doesn't want to install their app on your phone. Read access can/is restricted based on your platform, unless you're logged in. It's also difficult to search for specific issues/read threads, etc. There's better forum-style models to use for support.
Expressing disagreement with someone's opinion with a single click is sooo easy though ...
I used to use Jekyll. I still do, but I used to, too.
Hi, original Jekyll "core team" (if it could be called that) member here - just wanted to say thanks for writing this up, and I had no idea about the current status of the project or that one of the maintainers recently passed away.
That all being said: I think it's ok for OSS projects to "pass on" - and hopefully be replaced by better ones! I wish we had a better way of recognizing this for projects or talking about this industry-wide.
That all being said: I think it's ok for OSS projects to "pass on" - and hopefully be replaced by better ones! I wish we had a better way of recognizing this for projects or talking about this industry-wide.
Closely related, I wish we had a better way of saying a library or product is now feature-complete. We use recent commit activity as a proxy of viability, but all of that churn could just as easily be an indication of immaturity. It's okay for tools to achieve their objectives and just live on as stable code with maintenance releases as needed.
To my mind, Jekyll is feature-complete. The only changes I've needed to make to my Jekyll site are dealing with breakages from backwards-incompatible updates. I've been hosting with GitHub Pages for the past 12 years and I largely don't even have to think about it. It's nice.
To my mind, Jekyll is feature-complete. The only changes I've needed to make to my Jekyll site are dealing with breakages from backwards-incompatible updates. I've been hosting with GitHub Pages for the past 12 years and I largely don't even have to think about it. It's nice.
Even if the core project is feature complete and excellent, "death" can come from a lack of continued creation and maintenance of 3rd party integrations or plugins.
Personally I found Jekyll plugins lacking and those that were good seemed pretty old/unmaintained.
However I only moved to Hugo from Jekyll just because I didn't want to deal with Ruby gem installation and dependency management. I am not a Ruby dev by any means, I have enough dependency management misery from being a Python dev.
Hugo installation is just a brew-installed or Go-installed CLI tool I never have to think about dependencies of, thanks to how great the Golang packaging/distribution situation is.
Personally I found Jekyll plugins lacking and those that were good seemed pretty old/unmaintained.
However I only moved to Hugo from Jekyll just because I didn't want to deal with Ruby gem installation and dependency management. I am not a Ruby dev by any means, I have enough dependency management misery from being a Python dev.
Hugo installation is just a brew-installed or Go-installed CLI tool I never have to think about dependencies of, thanks to how great the Golang packaging/distribution situation is.
I recently went the other way - from hugo to jekyll - on a few sites. I find jekyll to be easier to install, modify, and maintain.
And I recently rebuilt one of my Hugo sites the other day and got a notice about some function that is now deprecated and will break something soon. That’ll make the third time something like this has occurred with hugo in the last few years. Dun like it.
And I recently rebuilt one of my Hugo sites the other day and got a notice about some function that is now deprecated and will break something soon. That’ll make the third time something like this has occurred with hugo in the last few years. Dun like it.
I'm using Jekyll (Ruby) in a docker container to manage the documentation of a Django project (Python). No need to deal with gems. Only docker pull and docker run. Most of the other developers don't know anything about Ruby.
https://hub.docker.com/r/jekyll/jekyll/
https://hub.docker.com/r/jekyll/jekyll/
That's fair. Having to set up a Ruby installation to run a utility just isn't fun. Especially when the expectation is that you don't use the system-provided Ruby. You're supposed to go use a Ruby version manager and set all of that up. And that rough experience can contribute to its death, for sure. I just don't think "has few commits in the last month" is a great reason to declare a project as dead, especially one providing the backbone of GitHub Pages.
Yes, it's not far off!
I do use some simple plugins for things like Redirects and Sitemaps.
But for many sites we build, what Jekyll does right now is just fine.
It also works with CloudCannon. Who are expanding their supported SSGs.
So if we shift our business, we'll likely just follow what ever SSG is blessed by them! :-)
I do use some simple plugins for things like Redirects and Sitemaps.
But for many sites we build, what Jekyll does right now is just fine.
It also works with CloudCannon. Who are expanding their supported SSGs.
So if we shift our business, we'll likely just follow what ever SSG is blessed by them! :-)
Couldn’t agree more.
Have been using Jekyll for years for all manner of sites and the most beautiful feature is that I’ve barely changed anything.
Even when I did recently update a few sites to new versions (mainly just because I was making some changes and figured why not) nothing broke.
Have been using Jekyll for years for all manner of sites and the most beautiful feature is that I’ve barely changed anything.
Even when I did recently update a few sites to new versions (mainly just because I was making some changes and figured why not) nothing broke.
I get what you're saying, and for single-purposes libraries or other simple infrastructure, that totally makes sense. But Jekyll lives in a wider world of vital tools from Gatsby to Eleventy to Hugo to (fill in the blank of your favorite SSG), and if it can no longer serve its main audience relative to compelling alternatives, it's not feature-complete, it's obsolete.
I'd imagine Jekyll's main audience is GitHub Pages and it seems to be used quite widely there. I get what you're saying, but I don't think Jekyll needs to compete with every single site generator on every feature. Gatsby is a case where the whole concept is taken in a wildly different direction and that's fine. I can't use Gatsby the way I use Jekyll and so Gatsby isn't the tool for me. But, Jekyll takes Markdown and turns it into HTML really well and has done so for over a decade. It's really not that complicated a tool.
I think there's probably two levels of discussion going on here. In very broad terms and with a generous scope of "we", we largely treat anything written in the last 15 years differently than anything that came before it. I don't know if it's because GitHub makes it so easy to see source or because recent languages have public repositories or something entirely different. But, no one looks at `bzip2` or `dig` and dismisses them as being obsolete because they don't have a hockey stick shape on the commit graph or because they don't serve multiple possible functions. To qrush's point, there has been a recent push to create "modern" implementations of system utilities and so we now have `ripgrep` and `bat` and maybe those new tools will reign supreme. But, I don't think that means `grep` or `cat` are dead and it's fantastic that they've worked reliably and consistently for so long (minus GNU vs BSD differences).
So my lament, if you will, is software being declared dead just because activity on it has slowed down (or essentially ceased). I think another way to interpret that data is it's mature and stable. I think it's great that Jekyll is a reasonably stable utility that I can rely upon. I can even install it via `apt` now and not have to deal with the mess of maintaining a Ruby environment. I can push a commit to GitHub and have a high degree of certainty that my site will generate the way I expect and that can match what I see on my own local system.
That level of maturity is something I'd like to see more software approach. In my experience, constantly chasing use cases often transforms a tool or library that was great at one thing into a tool that is okay at best at several things. Breaking compatibility is a good way to start annoying your supporters.
Maybe Jekyll won't be adopted for greenfield projects and that'll lead to its obsolescence. I just think that's a premature proclamation. It has a massive installation base via GitHub Pages, so stability is likely the better lever to pull.
I think there's probably two levels of discussion going on here. In very broad terms and with a generous scope of "we", we largely treat anything written in the last 15 years differently than anything that came before it. I don't know if it's because GitHub makes it so easy to see source or because recent languages have public repositories or something entirely different. But, no one looks at `bzip2` or `dig` and dismisses them as being obsolete because they don't have a hockey stick shape on the commit graph or because they don't serve multiple possible functions. To qrush's point, there has been a recent push to create "modern" implementations of system utilities and so we now have `ripgrep` and `bat` and maybe those new tools will reign supreme. But, I don't think that means `grep` or `cat` are dead and it's fantastic that they've worked reliably and consistently for so long (minus GNU vs BSD differences).
So my lament, if you will, is software being declared dead just because activity on it has slowed down (or essentially ceased). I think another way to interpret that data is it's mature and stable. I think it's great that Jekyll is a reasonably stable utility that I can rely upon. I can even install it via `apt` now and not have to deal with the mess of maintaining a Ruby environment. I can push a commit to GitHub and have a high degree of certainty that my site will generate the way I expect and that can match what I see on my own local system.
That level of maturity is something I'd like to see more software approach. In my experience, constantly chasing use cases often transforms a tool or library that was great at one thing into a tool that is okay at best at several things. Breaking compatibility is a good way to start annoying your supporters.
Maybe Jekyll won't be adopted for greenfield projects and that'll lead to its obsolescence. I just think that's a premature proclamation. It has a massive installation base via GitHub Pages, so stability is likely the better lever to pull.
I use Jekyll for a static site and I guess I just don't really understand why it needs further development. I haven't upgraded my version of Jekyll since I think 2017 because it does what it says on the tin.
Sometimes it's ok for software to be "done".
Sometimes it's ok for software to be "done".
The stability is precisely what I like about Jekyll. I can come back to a website I haven't touched in years and update it and it works. It's so rare for software to work like that.
The latest version of GNU sed is almost two years old. Does that mean it's time to ditch it for the latest rewritten-in-Rust tool du jour? Of course not.
Infrastructural software such as Jekyll should be finishable.
The latest version of GNU sed is almost two years old. Does that mean it's time to ditch it for the latest rewritten-in-Rust tool du jour? Of course not.
Infrastructural software such as Jekyll should be finishable.
My thoughts are the same. Jekyll “just works” for me, why does it need further development?
Yet Jekyll just doesn't work for lots of other people. That's why vital software dependencies always need further development…because over time they properly service a smaller and smaller subset of users—unless we're talking about an extremely specific single-use library of some fashion. That's not what Jekyll is!
People should use something else if Jekyll doesn’t fulfill their use case. Jekyll does what it is supposed to do very well. It is refreshing in the software world to have tools which are not always changing from under you.
Frank didn't look like he was at the age where people pass in their sleep.
This reminds me to be thankful for every day I get.
This reminds me to be thankful for every day I get.
I wonder if GitHub will step in and maintain. Isn't it still a built-in part of their pages stack? Even if there isn't new feature development, if it's part of their stack they should step in and maintain it.
You don't want bitrot to introduce vulnerabilities through unmaintained publicly exposed things in your stack.
You don't want bitrot to introduce vulnerabilities through unmaintained publicly exposed things in your stack.
Right. They (gh) should creative a relief team that handles repositories with very high stars, and no active maintenance.
I'm not suggesting they do that.
GH pages is includes jekyll. It's a feature of their product. I would expect them to maintain that as long as jekyll is part of their feature suite.
I'm only bringing them up because it impacts their product directly.
https://docs.github.com/en/pages/setting-up-a-github-pages-s...
GH pages is includes jekyll. It's a feature of their product. I would expect them to maintain that as long as jekyll is part of their feature suite.
I'm only bringing them up because it impacts their product directly.
https://docs.github.com/en/pages/setting-up-a-github-pages-s...
AKAIK, they apply (or backport) security fixes to the Jekyll 3.x branch. No word on if they ever plan to migrate to Jekyll 4 or beyond.
I can't say if the article was ninja edited, but it specifically addresses this.
Pretty sure that open source in 2021 means releasing the code somewhere public under an Open Source license, just like it did in 2011 and 2001. Not sure where all these other requirements come from. I'm already giving you free software, I don't also need to build a community.
> Not sure where all these other requirements come from.
They come from people who want to make money more than they want to build a nice thing and share it. Gotta spread that Fear, Uncertainty, and Doubt to usurp Jekyll's userbase.
They come from people who want to make money more than they want to build a nice thing and share it. Gotta spread that Fear, Uncertainty, and Doubt to usurp Jekyll's userbase.
The thing I love about Jekyll and other SSGs is being able to build my site into a bunch of static files and put every single one of those files on my own server, on IPFS, or even just for offline viewing, so there's no need to leak requests to the Cloudflares/Amazons/Googles of the world.
Meanwhile "the Jamstack" seems to be the exact opposite of that, a privacy nightmare all about gluing together micro-APIs that I have to keep paying for forever. I could wake up one day and find that my """static""" site is suddenly missing all its images because Cloudinary is having an outage or whatever. Why would I want to subject my readers to this, much less myself?
Meanwhile "the Jamstack" seems to be the exact opposite of that, a privacy nightmare all about gluing together micro-APIs that I have to keep paying for forever. I could wake up one day and find that my """static""" site is suddenly missing all its images because Cloudinary is having an outage or whatever. Why would I want to subject my readers to this, much less myself?
Because we live in an age in which DIY/solo development isn't respected anymore. Devs today think nothing of filling-up 500Mb with node modules just to generate a static site. I've even seen SSG's in Docker images.
Oh I remember when in my town we used middlemanapp to build our ruby community http://oaxacarb.org/ jamstack still growing up
I dont often say this on the internet but WFT?
I am autistic. I love coding.
A single person can create wonderful software that is a gift to everyone as open source.
I hate trying to be an extrovert and engage with a lot of people. I hate twitter and discord
Does that mean that I and people like me cannot do open source in 2021?
Most of these seem like detriments more than anything.
* Engagement on Twitter * Official Discord chat room * Public roadmap * Predictable release cycles * Welcoming community involvement in shaping new features and tackling technical debt * Cultivating working relationships with wider ecosystems (in this case Ruby, Jamstack, etc.)
I am autistic. I love coding.
A single person can create wonderful software that is a gift to everyone as open source.
I hate trying to be an extrovert and engage with a lot of people. I hate twitter and discord
Does that mean that I and people like me cannot do open source in 2021?
Most of these seem like detriments more than anything.
* Engagement on Twitter * Official Discord chat room * Public roadmap * Predictable release cycles * Welcoming community involvement in shaping new features and tackling technical debt * Cultivating working relationships with wider ecosystems (in this case Ruby, Jamstack, etc.)
The very next sentence in the article:
> Lack of any one of these points isn’t the end of the world, but at the present moment, Jekyll lacks ALL of them. That’s a real problem.
Nobody cares if there's no Discord if you're releasing and responsive to Github issues / roadmap questions.
> Lack of any one of these points isn’t the end of the world, but at the present moment, Jekyll lacks ALL of them. That’s a real problem.
Nobody cares if there's no Discord if you're releasing and responsive to Github issues / roadmap questions.
The list with Discord is an example of what "open source in 2021" as opposed to being responsive to github. So yes, some care.
Just don't do any of that stuff if you don't want to. If you're writing software because it's useful to yourself and others and making it open to others to use you do not owe them a place to chat, engagement, a roadmap, a release cycle (or any given release).
You can weigh whether you want to do those things
Those things are often set up when people want to run software projects with certain goals and if those goals are not yours then that is fine, just know that there is a tradeoff.
One nice example is litestream[0]. It's open source, not open contribution -- similarly you can have open source without built in community/discord/project-management/etc.
[0]: https://github.com/benbjohnson/litestream#open-source-not-op...
You can weigh whether you want to do those things
Those things are often set up when people want to run software projects with certain goals and if those goals are not yours then that is fine, just know that there is a tradeoff.
One nice example is litestream[0]. It's open source, not open contribution -- similarly you can have open source without built in community/discord/project-management/etc.
[0]: https://github.com/benbjohnson/litestream#open-source-not-op...
> Just don't do any of that stuff if you don't want to.
That's a privilege not everyone can afford. I cannot do real-time communication, So I cannot tolerate discord but GitHub issues are fine but I guess the parent is not fine with that too and that's alright but the answer is 'yes' open-source projects are subject to digital social conformity like so many things.
'like so many things': Just like how a Twitter account with at least 5 digit follower count has become a mandatory for a solopreneur's SaaS product to survive especially more so if the said solopreneur doesn't have other prior networks.
That's a privilege not everyone can afford. I cannot do real-time communication, So I cannot tolerate discord but GitHub issues are fine but I guess the parent is not fine with that too and that's alright but the answer is 'yes' open-source projects are subject to digital social conformity like so many things.
'like so many things': Just like how a Twitter account with at least 5 digit follower count has become a mandatory for a solopreneur's SaaS product to survive especially more so if the said solopreneur doesn't have other prior networks.
I think you might have misread my comment? I'm saying DO NOT do those things (discord or GH issues, etc)
> 'yes' open-source projects are subject to digital social conformity like so many things.
I whole-heartedly disagree. Maybe what's missing from the internet these days is the backbone to be clear about your own boundaries, but you absolutely do not owe anyone (who is not paying you) support or a place to file issues against your codebase that they don't also maintain.
You are not required to conform to anything you see on the internet (thankfully). This has more to do with your own motivations and goals. If you're making a F/OSS codebase to further your own ambition, then do whatever you think makes sense to get there and good luck.
If I stumble across some brilliant F/OSS work done by someone else for completely free and then released to me for completely free, I have already gained. They owe me nothing past that, and they never owed me anything to begin with.
> 'like so many things': Just like how a Twitter account with at least 5 digit follower count has become a mandatory for a solopreneur's SaaS product to survive especially more so if the said solopreneur doesn't have other prior networks.
Life for entrepreneurs is difficult and risk-laden, and that's why a lot of people don't become entrepreneurs. That fact does not mean the rest of the F/OSS world has to live like solopreneurs.
If you are making a product then it's your perogative to do what makes you successful (if that currently means trying build a "community" then so be it) -- that's your problem. If some person wants to just write software and make it open source so others can see it but doesn't want to maintain a community then that's their own perogative.
> 'yes' open-source projects are subject to digital social conformity like so many things.
I whole-heartedly disagree. Maybe what's missing from the internet these days is the backbone to be clear about your own boundaries, but you absolutely do not owe anyone (who is not paying you) support or a place to file issues against your codebase that they don't also maintain.
You are not required to conform to anything you see on the internet (thankfully). This has more to do with your own motivations and goals. If you're making a F/OSS codebase to further your own ambition, then do whatever you think makes sense to get there and good luck.
If I stumble across some brilliant F/OSS work done by someone else for completely free and then released to me for completely free, I have already gained. They owe me nothing past that, and they never owed me anything to begin with.
> 'like so many things': Just like how a Twitter account with at least 5 digit follower count has become a mandatory for a solopreneur's SaaS product to survive especially more so if the said solopreneur doesn't have other prior networks.
Life for entrepreneurs is difficult and risk-laden, and that's why a lot of people don't become entrepreneurs. That fact does not mean the rest of the F/OSS world has to live like solopreneurs.
If you are making a product then it's your perogative to do what makes you successful (if that currently means trying build a "community" then so be it) -- that's your problem. If some person wants to just write software and make it open source so others can see it but doesn't want to maintain a community then that's their own perogative.
> Just like how a Twitter account with at least 5 digit follower count has become a mandatory for a solopreneur's SaaS product to survive especially more so if the said solopreneur doesn't have other prior networks.
Every solo entrepreneur has to be their own marketing department. In the 2020s, marketing has to include social media.
The #1 job of an entrepreneur is not "build project", it is "persuade people with money to give you money". Forget that and you'll definitely fail.
Twitter may or may not be the right place for that (personally I think not, but it works for some people).
Every solo entrepreneur has to be their own marketing department. In the 2020s, marketing has to include social media.
The #1 job of an entrepreneur is not "build project", it is "persuade people with money to give you money". Forget that and you'll definitely fail.
Twitter may or may not be the right place for that (personally I think not, but it works for some people).
> Does that mean that I and people like me cannot do open source in 2021?
Absolutely not, but it does mean that you are likely to have difficulty if your aim is to build and support a project that is used by many, or otherwise be widely recognised.
If your goal is to play with cool stuff, put the results out there so others might see it and maybe use it or further build upon it, and won't be bothered if people don't, then you can definitely do that successfully without any of the community building & engagement noise listed.[‡]
If your goal is to contribute fixes and other help to other projects, then that too can be done without any of that noise. Unless one of those noisy channels is the only way to effectively communicate with the project you are contributing to, at that point some compromise may be needed on your part unless you prefer to move on and do something else instead. Moving on and doing something else instead, or branching and doing your own thing that way as long as you are OK with any licensing implications, is always an option.
---
[‡] I'm not autistic, nor as completely introverted as I used to be, but my thoughts on this feel like they stem from a similar place to yours and this is how I will manage that if I ever get around to releasing some of the stuff I have bubbling under: I'll put it out there, if people want to use it then great, if they don't then fine too, if they want to mail me fine (I might even respond!), but I won't be putting it out there to build community or to serve one. It'll be my playground, and while I'd be happy for others to find it useful if I move on and stop maintaining it or don't have time to respond to correspondence I will feel no guilt. If people expect more of me than I am comfortable providing, then they can just go on expecting!
Absolutely not, but it does mean that you are likely to have difficulty if your aim is to build and support a project that is used by many, or otherwise be widely recognised.
If your goal is to play with cool stuff, put the results out there so others might see it and maybe use it or further build upon it, and won't be bothered if people don't, then you can definitely do that successfully without any of the community building & engagement noise listed.[‡]
If your goal is to contribute fixes and other help to other projects, then that too can be done without any of that noise. Unless one of those noisy channels is the only way to effectively communicate with the project you are contributing to, at that point some compromise may be needed on your part unless you prefer to move on and do something else instead. Moving on and doing something else instead, or branching and doing your own thing that way as long as you are OK with any licensing implications, is always an option.
---
[‡] I'm not autistic, nor as completely introverted as I used to be, but my thoughts on this feel like they stem from a similar place to yours and this is how I will manage that if I ever get around to releasing some of the stuff I have bubbling under: I'll put it out there, if people want to use it then great, if they don't then fine too, if they want to mail me fine (I might even respond!), but I won't be putting it out there to build community or to serve one. It'll be my playground, and while I'd be happy for others to find it useful if I move on and stop maintaining it or don't have time to respond to correspondence I will feel no guilt. If people expect more of me than I am comfortable providing, then they can just go on expecting!
> it does mean that you are likely to have difficulty if your aim is to build and support a project that is used by many, or otherwise be widely recognised.
Didn’t jekyll prove the opposite?
Didn’t jekyll prove the opposite?
> Didn’t jekyll prove the opposite?
It doesn't seem to right now, apparently.
It may have done previously but either that didn't last long-term or, more likely I suspect but haven't checked, things were different and there was much more community interaction until the current quiet period.
It doesn't seem to right now, apparently.
It may have done previously but either that didn't last long-term or, more likely I suspect but haven't checked, things were different and there was much more community interaction until the current quiet period.
Good technology alone isn't enough to lead to adoption. Tiddlywiki, imo, is the best personal blogging tools. It is a static site, it got an embedded editor, it got cool concepts realised like transclusion, among many others. Go ask around, I bet hardly anyone talks about it. If a tree falls in a forest and no one is around to hear it, does it make a sound?
https://tiddlywiki.com/
https://tiddlywiki.com/
>Go ask around, I bet hardly anyone talks about it
Well, I, for one, have built this ADHD resource with it: https://romankogan.net/adhd
Depends on where you ask around, I guess =]
Well, I, for one, have built this ADHD resource with it: https://romankogan.net/adhd
Depends on where you ask around, I guess =]
Having looked quite a bit for personal docs stores: tiddlywiki is definitely very interesting and fits its niche pretty well, and I too will highly recommend people take a look at it, but it's just not viable in many cases.
E.g. mobile requires a browser plugin (... which is a broken link, and there seem to be both few alternatives and they have reviews that imply there may be problems) or separate app to allow saving[1]. iOS requires a separate app[2]. Sync occurs in one giant html file, so if you edit one word, the whole thing has to be re-synced (so using it for any moderate amount of media is a no-go) (this is both a great feature for hosting-free purposes, and a great curse). Much of this has been due to browsers clamping down on permissions.
To work around those, your main option is to... use a web server to host it. If you do that, then tiddlywiki is basically just another self-hostable web server with an interesting UI - there are quite a few also-good competitors in that space.
[1]: https://tiddlywiki.com/static/GettingStarted%2520-%2520Andro... [2]: https://tiddlywiki.com/static/GettingStarted%2520-%2520iOS.h...
E.g. mobile requires a browser plugin (... which is a broken link, and there seem to be both few alternatives and they have reviews that imply there may be problems) or separate app to allow saving[1]. iOS requires a separate app[2]. Sync occurs in one giant html file, so if you edit one word, the whole thing has to be re-synced (so using it for any moderate amount of media is a no-go) (this is both a great feature for hosting-free purposes, and a great curse). Much of this has been due to browsers clamping down on permissions.
To work around those, your main option is to... use a web server to host it. If you do that, then tiddlywiki is basically just another self-hostable web server with an interesting UI - there are quite a few also-good competitors in that space.
[1]: https://tiddlywiki.com/static/GettingStarted%2520-%2520Andro... [2]: https://tiddlywiki.com/static/GettingStarted%2520-%2520iOS.h...
I agree. There is a lot of great software out there that never really tried to update themselves to the mobile world, and thus fell behind. Tiddly being made in 2004 is a great example of that.
Tiddlywiki got particularly heavily smacked down by browser and mobile-OS changes/decisions, to be fair. For a fair amount of time, you could open a static file on your disk and it'd have access to any other file on disk, and eventually could even write back to disk... then that was locked down because it became a security issue (which really isn't surprising, but it is unfortunate for legitimate uses). For a couple (few?) years, extensions could easily work around this... now it's a huge hassle. And through it all, mobile has either not had sufficient features for that at all, or has had much stricter permissions that effectively mean no disk access at all.
The whole concept of tiddlywiki (as a single mutable html file) has become extremely difficult to maintain, where it used to be extremely simple.
The rest of the stuff tiddlywiki does is still great - transclusion is a great idea, and it works well. Server hosting is extremely cheap and simple. The UI has some very one-or-few-users-friendly patterns, and it really does do non-linear quite well. There's a lot to like about it. But once you go to web hosting, you're competing with every other website - the ecosystem is quite literally like a million times larger than cross-OS-and-serverless, it's not surprising that it's not all that well known.
The whole concept of tiddlywiki (as a single mutable html file) has become extremely difficult to maintain, where it used to be extremely simple.
The rest of the stuff tiddlywiki does is still great - transclusion is a great idea, and it works well. Server hosting is extremely cheap and simple. The UI has some very one-or-few-users-friendly patterns, and it really does do non-linear quite well. There's a lot to like about it. But once you go to web hosting, you're competing with every other website - the ecosystem is quite literally like a million times larger than cross-OS-and-serverless, it's not surprising that it's not all that well known.
Like a business, the success of open source is generally not solely dependent on the quality of the engineering alone. That is, where success is defined by popularity, # of public contributors/users, etc.
Also like a business, you don’t try to do everything — you delegate against your weaknesses. You just need to convince one social person to contribute, and cover whatever social media nonsense is required.
Note that any project that scales in count eventually becomes primarily a human management and communication problem, irrespective of what’s being produced, or how. Either drop the goal of scaling up, or set your expectations accordingly (and delegate as needed).
Of course, sometimes doing nothing at all is all you need (a few users uses it successfully, and it spreads by word of mouth), but really this is just delegation by accident. Your users are taking the responsibility of communication onto themselves (and it will eventually fragment as different gossip ping groups get split-brained), and the project will eventually centralize communication or die under its own weight.
Also like a business, you don’t try to do everything — you delegate against your weaknesses. You just need to convince one social person to contribute, and cover whatever social media nonsense is required.
Note that any project that scales in count eventually becomes primarily a human management and communication problem, irrespective of what’s being produced, or how. Either drop the goal of scaling up, or set your expectations accordingly (and delegate as needed).
Of course, sometimes doing nothing at all is all you need (a few users uses it successfully, and it spreads by word of mouth), but really this is just delegation by accident. Your users are taking the responsibility of communication onto themselves (and it will eventually fragment as different gossip ping groups get split-brained), and the project will eventually centralize communication or die under its own weight.
I think there’s a terminology gap that the article doesn’t do a great job with. Open source in 2021 does not require anything on the list. But to be a widely deployed open source project does generally require those kinds of things. As the parallel commenter noted, it doesn’t need to specifically be Discord or GitHub or Twitter or whatever, but to have mass adoption, the project needs to have directionality and momentum. Even if that’s “we feel we’re feature complete, if you find bugs, report them here”.
Without that, plenty of things are still “open source”, but users can’t really pick them up for their projects because they can’t rely on them. That’s fine: there’s plenty of really fascinating and meaningful projects out there that can’t be relied on for the long term. But for something like Jekyll, if I’m looking for a platform for my blog, I’d be remiss to pick something that’s stuck in the state it’s in.
That’s the issue that the author seems to be pushing at: he forked Jekyll because Jekyll is a widely adopted codebase that’s no longer able to support its niche, and he’s hoping that Bridgetown can fill that niche for users.
Without that, plenty of things are still “open source”, but users can’t really pick them up for their projects because they can’t rely on them. That’s fine: there’s plenty of really fascinating and meaningful projects out there that can’t be relied on for the long term. But for something like Jekyll, if I’m looking for a platform for my blog, I’d be remiss to pick something that’s stuck in the state it’s in.
That’s the issue that the author seems to be pushing at: he forked Jekyll because Jekyll is a widely adopted codebase that’s no longer able to support its niche, and he’s hoping that Bridgetown can fill that niche for users.
Thanks for explaining that better than I could apparently. Yes, obviously any software with a F/L/OSS license is "open source" but to build and sustain a community around a project of significance in 2021, there are some additional measures required.
Directionality and momentum? How about out-of-the-box functionality? What is the fascination with releasing unfinished products these days?
Does that mean that I and people like me cannot do open source in 2021?
It means few people will hear about or discuss your projects, and that means you won't get the critical mass of people necessary for your project to become popular. If you also conflate popularity with usefulness or importance then that's a problem.
Pretty much all big open source projects have benefited from "marketing" of some sort or another. If you're unwilling to do that then you're limiting the scope and size of what you can accomplish to what you can do on your own.
However, devs who are happy to contribute to an existing project where others do the social stuff are always welcome on pretty much every open source effort. So of course you can do it.
It means few people will hear about or discuss your projects, and that means you won't get the critical mass of people necessary for your project to become popular. If you also conflate popularity with usefulness or importance then that's a problem.
Pretty much all big open source projects have benefited from "marketing" of some sort or another. If you're unwilling to do that then you're limiting the scope and size of what you can accomplish to what you can do on your own.
However, devs who are happy to contribute to an existing project where others do the social stuff are always welcome on pretty much every open source effort. So of course you can do it.
Fabrice Bellard doesn’t have Twitter. For all I know he might have never logged in to a Discord chat. He has still managed to create incredibly useful software (both open source and proprietary). Just sayin’.
Nothing is a rule here, it's more a reflection on some of the common traits of open source projects. I'm sure we all use open source software where we have zero engagement with its community in any way and we are super appreciative of the tool or library that is provided ( or often with libraries, we don't even know what we have buried in our stacks). You do you. If you have the problem of needing greater engagement for your projects, then look around at other projects and find something you are comfortable with, or invent your own way of engaging.
Don't think Jekyll is in the state it is in today due to lack of engagement, though it may not check all the boxes - no i think better alternatives propped up and jekyll failed at keeping up with the joneses. Still use it on my personal site without any major hitches though.
Open Source is Not About you - https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
It's not clear from the comment whether you're rebutting the gp or supporting them: when I first read it I assumed you were disagreeing/criticising @ThinkBeat, so just to expand a little on my own interpretation from the article:
- the linked articles is about open source maintainers defining the relevancy and scope of their own projects, and telling critics / commentators (like Jared White in the OP) that their expectations of project maintainers (like Jekyll's) don't apply.
So I think that @gregors here is supporting @ThingBeat by basically saying "Open Source is Not About [Jared]" (i.e. that @ThinkBeat has the freedom to define the scope of their own open source work).
Correct?
- the linked articles is about open source maintainers defining the relevancy and scope of their own projects, and telling critics / commentators (like Jared White in the OP) that their expectations of project maintainers (like Jekyll's) don't apply.
So I think that @gregors here is supporting @ThingBeat by basically saying "Open Source is Not About [Jared]" (i.e. that @ThinkBeat has the freedom to define the scope of their own open source work).
Correct?
Correct. People might have the expectations of successful open source projects requiring marketing and community outreach pushes. Maybe those things aren't remotely interesting to the author?
Maintaining a public road map for example, that seems like boring busy work to me. If a project is truly dead anyone is free to fork or create a new project and spend their free time putting in the never-ending work.
"If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them."
Maintaining a public road map for example, that seems like boring busy work to me. If a project is truly dead anyone is free to fork or create a new project and spend their free time putting in the never-ending work.
"If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them."
You definitely have a place in open source. Good teams have a variety of skills so if public-facing communication isn’t your thing, partner with at least one person that likes doing that.
Absolutely not. You can do whatever you like. Do not let the noise scare you. Most of these things (twitter, discord) are just noise.
[deleted]
Am I missing something, or is Jekyll still receiving fairly active contributions[1]?
Even by that (misleading) metric, it doesn't seem to be dead. Expecting maintainers to tilt at the newest windmill instead of actually maintain is a critical part of why so many in the open source community burn out.
[1]: https://github.com/jekyll/jekyll/commits/master
Even by that (misleading) metric, it doesn't seem to be dead. Expecting maintainers to tilt at the newest windmill instead of actually maintain is a critical part of why so many in the open source community burn out.
[1]: https://github.com/jekyll/jekyll/commits/master
Maybe this is just clickbait? Jekyll is in a fine state for an extremely mature project.
It would be extremely souring to me if Jekyll decided to add webpack and other javascript dependencies with a newer version. One of the things I like about Jekyll is that it's a STATIC site generator that doesn't try to do everything.
Some sites I want to be dead simple, and that's what you get with Jekyll. If I want more complexity I'd go with a more complex generator like Hugo or Gatsby.
It would be extremely souring to me if Jekyll decided to add webpack and other javascript dependencies with a newer version. One of the things I like about Jekyll is that it's a STATIC site generator that doesn't try to do everything.
Some sites I want to be dead simple, and that's what you get with Jekyll. If I want more complexity I'd go with a more complex generator like Hugo or Gatsby.
> Jekyll is in a fine state for an extremely mature project.
That's my impression as well, as an outsider.
A recurring nightmare of mine as a maintainer is that I'll wake up one day and read someone's blog proclaiming the death of one of my projects, when all I've done is stopped adding new features to it. Especially so when it's someone who's made a living for themselves as a downstream user.
And I'm in the same boat as you: I've had a Jekyll-based blog, without incident, for a little bit under a decade now. It's only gotten faster and easier to use over time, which is more than I even asked for.
That's my impression as well, as an outsider.
A recurring nightmare of mine as a maintainer is that I'll wake up one day and read someone's blog proclaiming the death of one of my projects, when all I've done is stopped adding new features to it. Especially so when it's someone who's made a living for themselves as a downstream user.
And I'm in the same boat as you: I've had a Jekyll-based blog, without incident, for a little bit under a decade now. It's only gotten faster and easier to use over time, which is more than I even asked for.
Agreed! I personally maintain a couple projects I consider feature complete.
Changes are very rare other than occasional bug fixes or breaking ecosystem changes, but that doesn't mean the code is bad.
The code is a hammer, you don't need the newest shiniest hammer. You just need the hammer that hits nails.
Changes are very rare other than occasional bug fixes or breaking ecosystem changes, but that doesn't mean the code is bad.
The code is a hammer, you don't need the newest shiniest hammer. You just need the hammer that hits nails.
I never declared the death of the project. Frank, the remaining release maintainer of Jekyll after Parker Moore left, declared it. Read the article. :)
Right, you're just taking private words from someone who "refrain[ed] from making any public statement", publicizing them, and trying to capitalize on it four entire days after his obituary was published now that he's not around to speak for himself. Toootally different.
Is Hugo built with Ruby? Is Gatsby? Why are we saying that someone can only use the biggest Ruby-based SSG if they want something incredibly simple that will never change, otherwise they need to look somewhere else. Rails has never had that limited value prop for example.
Isn't that asking the wrong question?
If I want an SSG, I want an engine that takes a relatively simplistic text markup format, like Markdown or Org, and create a series of HTML documents from it. Why would the technology that does the gruntwork matter to me as an user?
Also, with Jekyll's plugin structure, what is an example of a functionality that cannot be achieved in Jekyll, but can in another non-Ruby SSG?
If I want an SSG, I want an engine that takes a relatively simplistic text markup format, like Markdown or Org, and create a series of HTML documents from it. Why would the technology that does the gruntwork matter to me as an user?
Also, with Jekyll's plugin structure, what is an example of a functionality that cannot be achieved in Jekyll, but can in another non-Ruby SSG?
Yeah, I'd like some corroboration for this blog post's rather alarmist rhetoric about Jekyll's project health. I get that the blog author is maintaining a fork so it's possible he has some other motive to make things sound this bad.
It's kind of interesting to me that the author opted not to use the Github "fork" feature to start Bridgetown, and there's no reference to Jekyll in the README (and hardly any in the git history either). This strikes me as an odd way to respond if the concerns are for the health of the upstream project; it would make sense to reach out and try to work with upstream if they aren't doing what needs to be done, then explain why a fork is needed in the README.
Jekyll itself is a project that still receives active commits and continues to do everything I ask of it (and indeed, it seemed essentially feature complete for my uses years ago).
It's kind of interesting to me that the author opted not to use the Github "fork" feature to start Bridgetown, and there's no reference to Jekyll in the README (and hardly any in the git history either). This strikes me as an odd way to respond if the concerns are for the health of the upstream project; it would make sense to reach out and try to work with upstream if they aren't doing what needs to be done, then explain why a fork is needed in the README.
Jekyll itself is a project that still receives active commits and continues to do everything I ask of it (and indeed, it seemed essentially feature complete for my uses years ago).
> I'd like some corroboration for this blog post's rather alarmist rhetoric about Jekyll's project health.
It's literally at the top of the article.
It's literally at the top of the article.
I dunno, if you look at the releases instead (https://github.com/jekyll/jekyll/releases), they were doing monthly releases for a long time, and now it's been 6 months without a release. The last was April 2021, and OP quotes the "release maintainer" of Jekyll as declaring Jekyll dead in "May 2021"...
Sounds like a "Hotel California" repo now, if you follow me. Which is unacceptable for a lot of distributors/users (are they just going to package random git HEAD snapshots whenever they feel like it, now that releases are apparently de facto banned?).
Sounds like a "Hotel California" repo now, if you follow me. Which is unacceptable for a lot of distributors/users (are they just going to package random git HEAD snapshots whenever they feel like it, now that releases are apparently de facto banned?).
This is where my outsider's perspective falls short: assuming that the old release maintainer isn't actively preventing the project from appointing a new release maintainer, what stops them from just keeping on?
Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature.
And then there's the Theseus-type questions: if Jekyll changes its name because the current maintainers have lost access to the RubyGems credentials, is it really not Jekyll anymore? It occurs to me that OSS is replete with `${project}-ng` namings, the `ng` suffix typically indicating that the project serves the same purpose as its original form but has been moved to a different namespace for whatever reason. If Jekyll's current maintainers were to publish `jekyll-ng` on RubyGems, I'd be inclined to call that a continuation of the original Jekyll for all extents and purposes.
Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature.
And then there's the Theseus-type questions: if Jekyll changes its name because the current maintainers have lost access to the RubyGems credentials, is it really not Jekyll anymore? It occurs to me that OSS is replete with `${project}-ng` namings, the `ng` suffix typically indicating that the project serves the same purpose as its original form but has been moved to a different namespace for whatever reason. If Jekyll's current maintainers were to publish `jekyll-ng` on RubyGems, I'd be inclined to call that a continuation of the original Jekyll for all extents and purposes.
I'm not familiar with Github release permissions because it's not a process I've ever used, but I assume it's a different capability from being able to push patches. A "release maintainer" & repo owner who won't release or isn't adding release capabilities isn't "actively preventing" anything; they are simply not doing anything.
At this rate, if the release maintainer continues to ghost the project (including by refusing to make any clear public announcement), Jekyll users are going to have to fork. You can't wait forever.
> but release schedules also naturally length as projects mature.
That's why I pointed out they had been maintaining a very steady monthly release schedule for years beforehand (and just look at the total release count!). Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!"...
At this rate, if the release maintainer continues to ghost the project (including by refusing to make any clear public announcement), Jekyll users are going to have to fork. You can't wait forever.
> but release schedules also naturally length as projects mature.
That's why I pointed out they had been maintaining a very steady monthly release schedule for years beforehand (and just look at the total release count!). Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!"...
> I'm not familiar with Github release permissions because it's not a process I've ever used, but I assume it's a different capability from being able to push patches. A "release maintainer" & repo owner who won't release or isn't adding release capabilities isn't "actively preventing" anything; they are simply not doing anything.
This is a point of confusion, since GitHub now has a few different things that could be called "releases": tags (a Git thing), tags that are labeled as "releases" (a GitHub thing), and released packages via one of GitHub's package indexes (including one that behaves like RubyGems).
Anybody who has push access to a repository should also have access to the first two, and probably has access to the third. The first is a Git-level consequence of access, and the second is just sugar on top of tags ("releases" don't behave any meaningfully different, and many projects do releases without using the release labeling). IOW, they should have sufficient permissions, as-is, to continue cutting releases. They might not have sufficient permissions to publish those releases to RubyGems, but that just means renaming the package to `jekyll-ng` or using GitHub's index instead.
> Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!
Yeah, these facts are in tension. Then again, looking further, a lot of the recent activity has been documentation and dependency tweaks, along with some light backporting activity (since they're also continuing to support Jekyll 3). So I think the needle I'd thread here is: "the project is receiving active attention, but is sufficiently stable to not warrant regular releases."
This is a point of confusion, since GitHub now has a few different things that could be called "releases": tags (a Git thing), tags that are labeled as "releases" (a GitHub thing), and released packages via one of GitHub's package indexes (including one that behaves like RubyGems).
Anybody who has push access to a repository should also have access to the first two, and probably has access to the third. The first is a Git-level consequence of access, and the second is just sugar on top of tags ("releases" don't behave any meaningfully different, and many projects do releases without using the release labeling). IOW, they should have sufficient permissions, as-is, to continue cutting releases. They might not have sufficient permissions to publish those releases to RubyGems, but that just means renaming the package to `jekyll-ng` or using GitHub's index instead.
> Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!
Yeah, these facts are in tension. Then again, looking further, a lot of the recent activity has been documentation and dependency tweaks, along with some light backporting activity (since they're also continuing to support Jekyll 3). So I think the needle I'd thread here is: "the project is receiving active attention, but is sufficiently stable to not warrant regular releases."
The messages being inaccessible due to Slack archiving should be a much bigger deal IMO.
Jekyll's commit history suggests the "RIP" title is, shall we say, exaggerated.
https://github.com/jekyll/jekyll/commits/master
https://github.com/jekyll/jekyll/commits/master
Thank you!
I don't doubt Jekyll is mature, but there's a difference between mature and abandoned. It looks like at least two different folks are committing, which gives me hope that this project (which we use quite heavily at $DAYJOB) is mature.
I don't doubt Jekyll is mature, but there's a difference between mature and abandoned. It looks like at least two different folks are committing, which gives me hope that this project (which we use quite heavily at $DAYJOB) is mature.
I love Jekyll. I haven't upgraded it in years because I simply haven't had to. It does the job and that's the highest praise I can give a piece of software.
One of the things that I like most about Jekyll is that when I return to my blog's repo that I haven't visited in 7 months, it is very easy for me to figure out how to "revive" it and add more content.
I spent a few months making the "ultimate" Gatsby site for my blog. I loved it. A year went by and I had no desire to relearn everything in order to update the thing (and fix the myriad of security vulns GitHub was now warning me about).
I spent a few months making the "ultimate" Gatsby site for my blog. I loved it. A year went by and I had no desire to relearn everything in order to update the thing (and fix the myriad of security vulns GitHub was now warning me about).
Can you share a link? Would like to see.
I was using Middleman for a while, but then grew tired of all the dependencies I had to always keep up-to-date. I did the completely illogical thing and built my own static site generator, https://sitepress.cc/
A few years later and I ended up deleting most of it and replacing the internals with Rails. Now Sitepress is just a tiny rails application sitting on top of a bunch of files. Most of the maintenance and dependencies are handled by major Rails lib maintainers. If you’ve grown use to Rails helpers, they’re all there.
When you deploy it, you can compile it into static files and deploy as you’d expect, but you can also deploy it as a rails or rack app … or even embed it into an existing rails app.
When Rails 7.0 gets released I’ll drop JS importmaps into the default install for free and have my dream static site generator that doesn’t have a huge asset compilation step.
A few years later and I ended up deleting most of it and replacing the internals with Rails. Now Sitepress is just a tiny rails application sitting on top of a bunch of files. Most of the maintenance and dependencies are handled by major Rails lib maintainers. If you’ve grown use to Rails helpers, they’re all there.
When you deploy it, you can compile it into static files and deploy as you’d expect, but you can also deploy it as a rails or rack app … or even embed it into an existing rails app.
When Rails 7.0 gets released I’ll drop JS importmaps into the default install for free and have my dream static site generator that doesn’t have a huge asset compilation step.
Really sad to hear this. I hope GitHub Pages supports an alternative JS-based SSG framework.
Nextjs and Gatsby are good candidates here and most likely will plug into Github's existing asset framework.
Nextjs and Gatsby are good candidates here and most likely will plug into Github's existing asset framework.
Sounds like Frank grew tired of the project a bit and was happy to just let it be since it's mostly feature complete. Should have probably looked for a new maintainer, I'm pretty sure lots of people would have been happy to take it. And now Frank has passed away; the remaining core members (are there any?) should look for new heirs.
Less than 2 weeks after Frank passed away.
Not very classy.
Not very classy.
An important aspect: most of the "new stuff" that Jekyll might need down the road will either be done the plugin level by the community (integration for some new social network), or by libraries that Jekyll uses (new image formats).
I don't see why Jekyll Core would need an urgent release.
I don't see why Jekyll Core would need an urgent release.
Seems like the author just wants Jekyll to be dead to promote whatever he is promoting.
I use Hugo now instead of Jekyll because the out of the box install directions on stock Ubuntu don't seem to work anymore for Jekyll. Maybe that's a Ruby problem, but either way, it required fiddling and I didn't want to do it anymore.
What a ridiculous tone and attitude by the author. Who's this bridgetown loser?
I don't know, did you read the article? :)
> Those concerns led me to fork Jekyll and create Bridgetown.
Please, Jared, contribute to Jekyll instead. There are many contributors, and you will probably get better code reviews. Bridgetown is your one-person show where you contribute the most commits (https://github.com/bridgetownrb/bridgetown/graphs/contributo...). Who is reviewing your changes? :)
YOU can revive Jekyll :)! I would like that. No offence, but Bridgetown is probably on "hiatus" sooner or later as well. I, as a user, have no trust in these forks.
Please, Jared, contribute to Jekyll instead. There are many contributors, and you will probably get better code reviews. Bridgetown is your one-person show where you contribute the most commits (https://github.com/bridgetownrb/bridgetown/graphs/contributo...). Who is reviewing your changes? :)
YOU can revive Jekyll :)! I would like that. No offence, but Bridgetown is probably on "hiatus" sooner or later as well. I, as a user, have no trust in these forks.
Been there. Done that!
https://github.com/jekyll/jekyll/issues/8085
This was before I had the slightest inkling of ever attempting anything like a fork. :)
And I'm truly thankful for all the people who are placing their trust in the long-term health of Bridgetown as warranted by the extremely active and robust 16-month commit and release history so far.
https://github.com/jekyll/jekyll/issues/8085
This was before I had the slightest inkling of ever attempting anything like a fork. :)
And I'm truly thankful for all the people who are placing their trust in the long-term health of Bridgetown as warranted by the extremely active and robust 16-month commit and release history so far.
Hi Jared, that issue was an exciting read. Thanks for the link. I get why you started a fork. The thumbs-up in your last comment tells a story (https://github.com/jekyll/jekyll/issues/8085#issuecomment-60...) :) (spoiler: the thumbs-up is from DirtyF).
Jekyll is already feature complete. I haven't updated my jekyll build container in years. (I update the site it builds often.)
What is this "dead" nonsense? It isn't a story, it's a tool, and it's complete. By that logic my framing hammer is "dead" now, too.
"No more updates" isn't always a bad thing.
What is this "dead" nonsense? It isn't a story, it's a tool, and it's complete. By that logic my framing hammer is "dead" now, too.
"No more updates" isn't always a bad thing.
Plenty of people are not asking for Jekyll to be feature complete. It's fallen woefully behind relative to its competition.
As for the "dead" nonsense and where that's actually coming from, did you read the article? :)
As for the "dead" nonsense and where that's actually coming from, did you read the article? :)
As I understand it, Bridgetown is a Jekyll fork or clone. The author tried and failed to sell his bag of tricks to the Jekyll core team so he decided to go his own way. That's fine, but this article is a blatant attempt to slander Jekyll, sow FUD among its users, and attract attention to his own product. I find this disgusting and reprehensible.
The argument made here is like “RIP C” now come over to my new project: “C++”.
Nope. Nope, nope, nope. Neither C nor Jekyll are dead.
Nope. Nope, nope, nope. Neither C nor Jekyll are dead.
There’s been a fair amount of internet consternation since I published this article. While I do stand by everything in the post factually-speaking, I apologize for the insensitive timing of this article—coming so soon after Frank’s passing. I’m genuinely sorry this came across as a “Jared vs. Frank” debacle. Should I have waited a few more weeks or months? Probably. Perhaps it was originally a mistake for me to refrain from publicly commenting on the statements regarding Jekyll’s “permanent hiatus” back in May. It’s hard to say. At the very least, I hope we can all agree that Jekyll’s legacy as the “first among many” of modern static site generators is meaningful to a lot of people, even if we sometimes disagree on the best way to honor that legacy and push Ruby on the Jamstack forward. If the one thing that comes out of all this is that more people step forward to share their positive experiences with Jekyll, Ruby, and building websites, that’s a good thing.