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.)
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.
> 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.
> 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!
> 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.
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?
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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).
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?).
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.
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.
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?
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.
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.
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.
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!
Readit News
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.)
> 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.
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...
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.
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!
Didn’t jekyll prove the opposite?
https://tiddlywiki.com/
Well, I, for one, have built this ADHD resource with it: https://romankogan.net/adhd
Depends on where you ask around, I guess =]
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...
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.
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.
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.
- 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?
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.
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.
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 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! :-)
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.
> 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.
> 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.
> 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.
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.
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.
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.
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
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.
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.
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 literally at the top of the article.
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?).
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.
https://github.com/jekyll/jekyll/commits/master
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.
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?
Sometimes it's ok for software to be "done".
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.