07 Jan 2026
Fedora People
Ben Cotton: GitHub Discussions versus Discourse
Some projects get by just fine with only communicating in the issue tracker and commits (or pull requests). Most projects need to talk more. They need to discuss governance issues, get community feedback on feature ideas, address user questions, plan events, and more. There's no end to the number of venues to have these conversations, but for many projects, it comes down to one choice: GitHub Discussions versus Discourse.
Both of these platforms have their advantages and disadvantages. As I wrote in the appendix to Program Management for Open Source Projects, there's no right tool, just the right tool for your community. I have used both of these tools, and can recommend both for different needs.
GitHub Discussions
GitHub Discussions is a relatively simple forum add-on available to GitHub repositories. Project administrators can add it with a simple checkbox. As a result, it requires no additional infrastructure and participants can use their existing GitHub account. You can easily convert issues to discussion threads or discussion threads into issues - some projects even require a discussion thread as a prerequisite for issue creation.
GitHub Discussions is tightly integrated into the rest of GitHub, as you might expect. This means it's easy to tag users, cross-reference issues/commits, watch for new activity, and so on. On the other hand, this tight integration isn't helpful if your project isn't tightly integrated into GitHub. Depending on the nature of your project, users who come to ask questions may not even have a GitHub account.
Discourse
Discourse (not to be confused with the chat platform Discord) is an open source discussion platform. You can self-host it or pay for hosting from Discourse or their partners. Because it's designed to be a community communication tool, it offers a lot more flexibility. This includes both themes as well as plugins and other configuration options.
Discourse includes a concept of "trust levels" that can automatically move users up through greater privileges based on a history of prosocial behavior. Moderators and access control can be adjusted on a per-category basis, which is particularly helpful for the largest of communities.
Discourse has a mailing list mode so that users who prefer can treat it like a mailing list. It also supports private conversations so that moderators and administrators can discuss concerns candidly.
GitHub Discussions versus Discourse: pick your winner
How you decide which tool to use will depend on several factors:
- Other tooling. If your project's infrastructure is entirely contained on GitHub, then GitHub Discussions is probably the best choice for you. If you don't use GitHub at all, then Discourse makes more sense. In general, the more non-GitHub tooling you have (CI systems, for example), the more Discourse makes sense on this axis.
- Infrastructure resources and budget. GitHub Discussions has zero (financial) cost to your community, so that's a good fit for the vast majority of open source projects. Discourse requires you to have a budget to pay for hosting or the resources and skills to self-host. In my experience, self-hosting is fairly easy - if you have people in the community who can do it.
- Project purpose. Communities that primarily build software - and mostly have development-oriented contributors - benefit from the tight integration that GitHub Discussions offers. If the community is not software-focused (e.g. if it's an affinity group, advocacy organization, etc), then Discourse may be a better choice.
- Target audience. If the people who will be participating in the conversation are primarily contributors or developer-like people, then GitHub Discussions can be a good fit. If you're expecting general computer users - who may or may not even know what GitHub is - then Discourse is probably more approachable.
- Community size. Discourse has a lot of flexibility and power to handle thousands of users. When you have ones or dozens of users, the simplicity of GitHub Discussions can be more appealing.
Ultimately, there's no simple answer. You have to compare the tools across the axes above (plus any other technical or philosophical requirements you have).
This post's featured photo by Volodymyr Hryshchenko on Unsplash.
The post GitHub Discussions versus Discourse appeared first on Duck Alignment Academy.
07 Jan 2026 12:00pm GMT
06 Jan 2026
Fedora People
Tomasz Torcz: I Voted, F43 edition
06 Jan 2026 4:44pm GMT
Kushal Das: 2025 blog review
06 Jan 2026 8:34am GMT
Fedora Badges: New badge: Fedora 47 Change Accepted !
06 Jan 2026 6:19am GMT
Fedora Badges: New badge: Fedora 46 Change Accepted !
06 Jan 2026 6:15am GMT
Fedora Badges: New badge: Fedora 45 Change Accepted !
06 Jan 2026 6:14am GMT
Fedora Badges: New badge: Fedora 44 Change Accepted !
06 Jan 2026 6:13am GMT
Fedora Badges: New badge: Fedora 43 Change Accepted !
06 Jan 2026 6:12am GMT
05 Jan 2026
Fedora People
Fedora Community Blog: DEADLINE 2026-01-07: Fedora Linux 43 FESCo Elections

Voting is currently open for the Fedora Engineering Steering Committee (FESCo). You have approximately 2 days and 9 hours remaining to participate.
DEADLINE: 2026-01-07 at 23:59:59 UTC
VOTE HERE: https://elections.fedoraproject.org/about/f43-fesco
Please ensure your ballot for the Fedora Linux 43 FESCo Elections is cast before the cutoff.
The post DEADLINE 2026-01-07: Fedora Linux 43 FESCo Elections appeared first on Fedora Community Blog.
05 Jan 2026 2:39pm GMT
Jonathan McDowell: Free Software Activities for 2025
05 Jan 2026 7:57am GMT
04 Jan 2026
Fedora People
Matthew Garrett: What is a PC compatible?
04 Jan 2026 3:11am GMT
02 Jan 2026
Fedora People
Felipe Borges: Looking for Mentors for Google Summer of Code 2026
It is once again that pre-GSoC time of year where I go around asking GNOME developers for project ideas they are willing to mentor during Google Summer of Code. GSoC is approaching fast, and we should aim to get a preliminary list of project ideas by the end of January.
Internships offer an opportunity for new contributors to join our community and help us build the software we love.
@Mentors, please submit new proposals in our Project Ideas GitLab repository.
Proposals will be reviewed by the GNOME Internship Committee and posted at https://gsoc.gnome.org/2026. If you have any questions, please don't hesitate to contact us.
02 Jan 2026 12:39pm GMT
Remi Collet: 🎲 PHP version 8.3.30RC1, 8.4.17RC1 and 8.5.2RC1
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.2RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.4.17RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.3.30RC1 are available
- as base packages in the remi-modular-test for Fedora 41-43 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
ℹ️ Installation: follow the wizard instructions.
ℹ️ Announcements:
- PHP 8.5.2RC1 available for testing
- PHP 8.4.17RC1 available for testing
- PHP 8.3.30RC1 available for testing
Parallel installation of version 8.5 as Software Collection:
yum --enablerepo=remi-test install php85
Parallel installation of version 8.4 as Software Collection:
yum --enablerepo=remi-test install php84
Update of system version 8.5:
dnf module switch-to php:remi-8.5 dnf --enablerepo=remi-modular-test update php\*
Update of system version 8.4:
dnf module switch-to php:remi-8.4 dnf --enablerepo=remi-modular-test update php\*
ℹ️ Notice:
- EL-10 packages are built using RHEL-10.1 and EPEL-10.1
- EL-9 packages are built using RHEL-9.7 and EPEL-9
- EL-8 packages are built using RHEL-8.10 and EPEL-8
- oci8 extension uses the RPM of the Oracle Instant Client version 23.9 on x86_64 and aarch64
- intl extension uses libicu 74.2
- RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
- versions 8.3.30, 8.4.17 and 8.5.2 are planed for January 15th, in 2 weeks.
Software Collections (php84, php85)
Base packages (php)
02 Jan 2026 7:05am GMT
01 Jan 2026
Fedora People
Ben Cotton: Open source trends for 2026
A new year is here and that means it's time to clean up the confetti from last night's party. It's also time for my third annual trend prediction post. After a solid 2024, I did okay-ish in 2025. I am not feeling particularly confident about this year's predictions in large part because so much depends on the direction of broader economic and political trends, which are far outside my expertise. But this makes a good segue into the first trend on my radar.
Geopolitics fracturing global cooperation
The US government proved to be an unreliable partner in a lot of ways in 2025 and I see little reason that will change in 2026. With capricious policy driven by retribution and self-serving, Europe has become more wary of American tech firms. This has led to efforts to develop a Europe-based tech stack and a greater focus on where data is stored (and what laws govern access to that data). Open source projects are somewhat insulated from this, but there are two areas that we'll see effects.
First, is that US-based conferences will have an increasingly domestic attendee list. With anecdotes of foreign visitors held in detention for weeks and visa issuance contingent on not saying mean things about the president, it's little wonder that fewer people are willing to risk travel to the United States. Global projects, like the Python Software Foundation, that have their flagship conference in the US may face financial challenges from a drop in attendance. The Europe versions of Linux Foundation events will be the main version (arguably that's already true). FOSDEM will strain the limits of its venue, even more than it already does.
The other effect we may see is a sudden prohibition against individuals or nations participating in projects. Projects with US-based backers - whether company or foundation - already have to comply with US sanctions, the Entity List, and other restrictions. It's conceivable that a nation, company, or individual who upsets the White House will find themselves subject to some kind of ban which could force projects to restrict participation. Whether these restrictions apply to open source is unclear, but I would expect organizations with something to lose to take a cautious approach. Projects with no legal entity will likely take a "how will you stop me?" approach.
A thaw in the job market
This section feels the most precarious, since it depends almost entirely on the macroeconomic conditions and what happens with generative AI. With the latter, I think my prediction of a leveling off in 2025 was just too soon. In 2026, we'll see more recognition of where generative AI is actually useful and where it isn't. Companies won't fire thousands of workers to replace them with AI agents only to discover that the AI is…suboptimal. That's not to say that AI will disappear, but the approach will be more measured.
With interest rates dropping, companies may feel more confident in trying to grow instead of cutting costs. Supply chain issues and Cyber Resilience Act (CRA) requirements (more on those in a moment) will drive a need for open source expertise specifically. Anecdotally, I've seen what seems to be an upward trend in hiring for open source roles in the last part of 2025 and I think that continues in 2026. It won't be the huge growth we saw in the early part of the decade, but it will be better than the terrible job market we've seen in the last year or two.
Supply chain and compliance
Oh look: "software supply chain" is on my trends list. That's never happened before, except for every time. It won't stop being an issue in 2026, though. Volunteer maintainers will continue to say "I am not a supplier" as companies make ever increasing demands for information and support. September 11 marks the first significant deadline; companies must have a mechanism for reporting active vulnerabilities. This means they'll be pushing on their upstream projects for that information.
Although open source projects don't have obligations under the CRA, they'll have an increased request burden to deal with. Unfortunately, I think this means that developing a process for dealing with the request deluge may distract from efforts to improve the project's security. It may also drive more maintainers to give up.
This post's featured photo by Jason Coudriet on Unsplash.
The post Open source trends for 2026 appeared first on Duck Alignment Academy.
01 Jan 2026 12:00pm GMT
Simon de Vlieger: pinnwand and bpa.st in 2025
01 Jan 2026 6:00am GMT
31 Dec 2025
Fedora People
Kushal Das: johnnycanencrypt 0.18.0 released
31 Dec 2025 2:15pm GMT