# JReleaser 2.0 Strategy and Open Source Governance

**Podcast:** The InfoQ Podcast
**Published:** 2026-03-16

## Transcript

If your team has AI running and a proof of concept, but you're still figuring out how to run it reliably in production, you're not alone.
That's the gap most engineering teams are navigating right now.
QCon AI Boston this June 1st and 2nd brings together senior engineers, software architects, and technical leaders who've already made that shift.
They'll share the patterns that scaled, the mistakes that didn't make the blog post, and what they'd actually do differently.
No hidden product pictures, just senior practitioners helping senior practitioners.
Learn more at boston.ai.
Hello everybody, I'm Olympio Pope, an info queue editor.
And I have in front of me probably one of the I don't know, veterans in the open source space, especially in the Java space, Andres Almire.
Anders, thank you for taking the time for uh talking to us.
And if you can please introduce yourself.
You have so many accolades, I don't know which ones to pick, so I'll let you choose the ones that you like.
Thank you for having me on the show, Olympia.
It's a great honor for me.
So as you said, my name is Sandra Salmirai, and I'm a Java champion.
This year marks 20 years as I've been actively contributed to open source.
It's going quite a ride.
As you mentioned, I have been working in Java for a long time.
Also known for helping the grouping language.
There's been a series of projects that have been related to or been working for for those past 20 years.
They range from build tools, application frameworks, build tool plugins, and some other things.
Every one of those has a little story to it.
And I really like the fact that I was able to meet so many different people across time and across different countries, such as yourself, thanks to working to with open source.
And about those stories, I think I know at least two of them.
One of them was related to the security in the supply chain space because that's getting higher and higher for everybody, especially with the cyber resilience acts here in Europe.
People are just discussing how much time they spent for reproducible builds.
Erv Boutemi was discussing about some time that you spent together while trying to put together all the tools that you needed to have it in J Releaser.
A more common one was from Max Anderson.
He was pointing out J Releaser, being one of the better CLI tools in Java.
Because he has a call of arms to everybody in the Java space to do more about CLI tools, especially now with the genetic AI and all the other generated stuff.
So what's the recipe of success?
Because I know that you're working for 2G for with J Releaser for a couple of years now, if I think so.
Yes, this year will mark in April 10th, the fourth anniversary of release 100.
Oh wow.
Do you still keep the cadence?
I know that you are very disciplined with the cadence of J Releaser.
Do you still keep it?
Yes, we have a two-month release cadence so that people know what's coming up.
And we release at the end of the month on the even number months.
We're recording today on February 18th.
So at the end of February, there will be a release.
And the next one will come out by the end of April.
We also very close to starting the roadmap for 2.0, where we expect to make some breaking changes and a few other features that require us to break compatibility.
We may start putting out alphas soon, but there will be perhaps a different release cadence for going up to 2.0, and we may keep the current release cadence for 1x until we do the final switch.
Okay.
I'm happy to hear that the 2.0 is still on the agenda.
I know that one of the things that you had planned there was something special.
I know if you you want to make it public or not, but at that point I know that you said that it's about to just cut the J out of it because it's not only for the Java ecosystem.
Yeah, one of the things that we mentioned was possibly a re-randing on the tool.
I am still undecided if that re-randing should take place or not.
From someone that knows the tool and has been exposed to the tool, they were of course know the name.
And they also may be aware that you can use it with any kind of source language.
We have ready-made examples for popular languages.
Obviously, you're gonna find Rust, Go, Python, Perse, C, C Sharp, Ruby, and so many other strange languages, such as Odin, Nim, and some, I'm not necessarily might call it uh strange, but it'll be SIG, Swift, and the list goes on and on and on.
There is no restriction to use a tool with just Java just because it has a J in the name.
But if someone is new to the Java ecosystem or doesn't know what this tool exists, and they may try to find a releasing tool that is native to your ecosystem, they may not necessarily find it and think, why should I use something that is channel-based to release my Rust project?
It doesn't make sense, right?
Because I want it to be Rust because it's part of my ecosystem, that the tool chains that I know, right?
So that's where rebranding may necessarily come in and show people that there is an alternative, even though it's not native to their source ecosystem.
That makes sense.
I'll look eagerly to see what would be the outcome of this debate and whether we'll have a new tool or we'll have an old tool that still has a 2.0 after it.
But as we discussed before, hitting the record button, you mentioned that to hit the plateau in terms of features, and so that points towards uh a product maturity more or less.
It looks like we have rich plateau of stability.
There are still a few features being added on every release, but not as many as it happened before.
So the features that we have in the pipeline do require these breaking changes and breaking on compatibility, which we keep track in the roadmap for 2.0.
It may be the case that we are reaching a critical mass of features that say yes, we have to go to 2.0.
We added in recent times additional announces.
So when you post a release, you can create an announce to many different distribution channels, such as sending an email or sending a message to a Slack channel.
We added the capabilities to announce to LinkedIn and Reddit.
And soon in the next release, we will support also another announcing channel called Twist.
We also added the capability to have multiple digital signature algorithms at the same time.
So in the past you could only have PGP or cosign.
Now you can have both depending on the title artifacts that you want to release.
And we also added a third one called MiniSign.
And in the early stages of the first release of the tool, some developers have asked for supporting signing with the Windows signing tool, which only runs on Windows platforms.
And that we would like the tool to be independent of the platform.
And some others have also had similar things for when running on OSX.
So there is a tool out there called JSIN, another open source project written in Java that you could run on any platform to generate Windows compatible signatures.
This is probably something that we will add before 2.0.
Hopefully, in the release in April, we can add these features so that we will have the possibility to just provide any kind of digital signatures for all the platforms.
Good luck with all the features.
All sound quite interesting and definitely will be useful.
One of the things that I know that you worked some time ago is having the distribution channels to different platforms.
Can you figure out a couple of of them that people tend to use or what would be a couple of patterns or lessons learned from what you saw users using?
Well, one of the first reasons to build a tool like this one was because I wanted to deploy a JavaFX application in such a way that anyone will be able to consume it very easily.
So if you use Homebrew, then you will install these JavaFX applications using Homebrew.
But that required me to learn a little bit of Ruby and understand the format for creating the manifest for this.
And then you find people that homebrew doesn't work on Windows.
You need a package manager that is native to that platform.
There are a few options.
There's a scoop very similar to Homebrew, and there, of course, there's Winget that and chocolate.
And the same thing happened.
You need to understand how to write the different sections for each one of these different manifest files, whether it's XML, JSON, whatnot, and so many other things that you need to keep track of, that it became so complicated to do these things by hand.
And that's why the tool came to be.
So based on this, we've seen that most people that consume the tool to publish to different package managers, they first choose Homebrew, and they secondly go for Winget.
Thirdly, they are those that go whether it's not Winged, they will go without a chocolate or scoop for targeting Windows.
And then those that would like to create Docker images, containing images, whether with using Docker or PubMed or Google's G, which we support all of them as well.
It seems that people are still using natively installed applications, and definitely the Docker has the traction that we expect now, given that that became something normal for most of the people.
But there is still a question.
You definitely mentioned that the product is mature.
How about the architecture, the underlying architecture?
I know that you put a lot of interest into having it getting started nicely.
And in one of our first discussions, you were quite happy with what you got started.
But definitely when you're looking at uh two point something, it's about breaking changes.
Are you intending to change something?
I'm just thinking now that looking at other ecosystems, well, a different perspective.
There is a lot of modules that you can add depending on what you need.
How are you creating that kind of puzzle-like approach?
As a matter of fact, as we were growing in different versions, we added support for a different set of announcers and packagers that turn out to be more common.
So let's say there is Google Chat, GitHub, and I think the Teams announcer also, they will natively send use the REST APIs to the target services to send the information as needed.
But as it turns out, all of them can be implemented with a simple web hooks.
And we do have a generic webhooks announcer.
So it turns out that some of these explicit custom-made announcers under the hook now use the generic webhooks.
So that we have marked the explicit announces to be deprecated and be removed in version 2.0.
This is one of the things that we want to do.
That we already have identified features in the tool that are more common.
And we have refactored them such a way that we can remove what is explicit.
So these things are shade a little bit of the weight that we accumulated as we're putting releases to make things a little bit slimmer.
That's the case of the things that we would like to break.
Correct some of the design choices that we made early on for naming things in the DSL so that it's more intuitive, so that it conforms to other rules that we discovered as we add more elements to DSL.
All of these things are already being marked as deprecation.
So whenever you run the tool with the different interfaces, whether it's Maven, Gradle and or command line tool, if you happen to use a DSL element that has been marked for deprecation, you will get a warning in the log.
So you will know that this is going away.
It tells you when it was deprecated and which release, and it will tell you that also that it will be eventually removed in version 2.0.
So if anyone consumes the tool and see any special warnings like this, deprecation warnings, is it would be a good idea to have a look at the documentation telling you what would be the other way going forward to do things with the DSL.
Okay.
So to just sum it up, on one side, you have the feedback that you gathered from the existing users, the feedback that you have from you and other developers that helped develop JReleaser until now, and you're incorporating all those to just make the product more robust and leaner.
But as you mentioned previously when talking about renaming the product or not, you're looking at two personas, if you like.
One of them are already existing customers or users, and then you're talking about new people that would like to adopt it.
What are the questions that people should answer when they get started on using J Releaser for their release?
Well, it depends on what that particular person is making use of when creating a release.
So the first question is you're working on a tool on an application on any project.
It doesn't have to be CLI or desktop, it could be just any project that you want to tag and create release notes and maybe make an announcement when this happens.
So the first question is how are you doing this?
Do you have some set level of automation already?
Are you doing it with a set of bash scripts or is some other scripting language?
Are you targeting just GitHub?
Do you know GitHub Actions?
Or do you want to use GitLab?
So you do you know GitLab CI and how does it work?
If all these things sound like, wait, hold on a second, that is way too much information.
I didn't know I have to be an expert, or I have to learn so many things in order to do something that just by saying this sounds trivial, and but it turns turns the case it isn't, then JReleaser may be the tool for you because it simplifies all these things.
It follows a convention over configuration mechanism so that you can configure as little things as possible and apply as much behavior as needed.
The tool doesn't push you to choose a given path.
It's the other way around.
You tell the tool exactly the things that you want.
So the next thing is you already have some sort of release process, some level of automation.
But there may be some things that may be failing, are not reproducible, or it's difficult for automated for one reason or another.
And this is again when the tool can help you, and you just pick which items, which part of the behavior that the tool provides can help you in your release process.
And because we do live in the age of LLMs and everybody using it for everything, and you did mention the DSL, how easy it would be to just I don't know, go to one of those LLMs and ask it to help me write something with the DSL or the DSL is internal.
And I'm asking that wrong question.
Actually, the DSL is external and you can have different formats depending on how you want to consume it.
If it's on the CLI, then the most typical format will be journal.
But given that there's also a section of the population that does not like JAML, but they like some of the formats, we support Tomo as well.
If you are using Maven, there is a Maven plumbing, and you can use the Maven XML DSL to configure the plugin.
If you're using Gretel, then we have a Gretel plugin, and it's up to you to decide which DSL or Gradle you want to use, whether it's Groby, is Kotlin or the declarative Gradle thing that is coming up lately.
So you have three choices in GREL at the very least.
And the last one that we have is also JSON, if you want to do it.
So there was a time when I considered perhaps it would be necessary to add explicit metadata to the tool so that different L elements were able to discover the features and provide information for you.
But it looks like at the very least, cloud is the one that will easily integrate with so many other different tools out there, such that way that we don't have to provide an NCP server nor additional metadata for it to work.
Cloud appears to be smart enough to just be able to parse the information that is coming from the help menu of all the different commands that you can invoke in the CLI and suggest you exactly what you can do with it.
Yeah, that's my observation as well.
On the benefit of having these tools, is the ability of playing with things that normally would take weeks of documentation stuff like that.
For instance, I never was a fan of front end.
And now it's a lot easier to just do this stuff.
But what I observed is that especially with the quick cadence of the JavaScript ecosystem, there is a gap between what information the tool has in comparison with what you currently have after the release, because maybe it's not trained on that, but pointing it towards the documentation helps a lot, and that's quite useful.
When you're starting to play with LLMs, you will like to try out some things, and you might be nervous to make a commit and see if things work out.
The tool, Jarreleaser, allows you to test out features in a drive run mode.
So you can run it in a local environment as much as you can.
When you're running in drive mode, it means that it will be able to consume information from the outside world in case that it needs to download files or process templates, but it will not push to the remote server.
So it will not create a git release or alter some remote files by accident.
It will tell you what it's trying to do, but it won't do it.
So you're in control.
We recently added another mode, and then I recalled that you mentioned Max name.
This is a feature that Max requested.
And this is the yellow flag.
What happens when you have a configuration file for a project where you may not necessarily have all the requirements configured?
Say, for example, you want to deploy to Maven Central your certain artifacts, but also want to publish uh container image and publish a Ruby formula for HomeRoop, right?
If you don't have the secrets for deploying to Maven Central, attempting a release will make things fail because information is missing.
But if you add the JOL flag, then you can run anything you want to, and if something were to be missing or is misconfigured, then that whole section will be skipped.
You will see a warning in the log file telling you, well, we're missing some stuff.
It will not tell you the values of the secrets, obviously, but it will tell you we were not able to deploy to Maven Central because we have missing credentials.
But instead of failing, it will continue to the next step.
In this case, it will create the package manager files that you want.
But you could do it the way around.
So again, you can play with these things.
You don't have to configure everything up front to test out how the release process will work out.
So it seems that it's a tool that you can use to your needs.
It's very flexible, yes.
Thank you.
And another project that I think is quite important and you were involved with is the Common House Foundation.
Yes, the Common House Foundation is an endeavor that I really enjoyed working with.
JRLESER is one of the founding projects alongside JBank from Max.
I think that we have grown to close to 15 projects now.
So we have Quarkus and some projects, other projects from Red Hat.
There is Ralph Live and Infinispan.
We also have the first non-Java project, SlateDB.
It's written in Rust.
Although the foundation was originally thought of, oh, let's make this work for Java projects because most of all the people that are associated with the Comm Foundation, we come from the Java ecosystem.
We are more than happy to welcome projects that use the different languages.
It doesn't have to be all Java and Slate DB proves that.
The foundation is also close to its second anniversary, which happens to be April 9th.
If you like April for great projects, right?
Yes, it is definitely these two projects were not released as April Falls.
But yeah, it's a good time.
Yeah, I knew about Quarkus because whenever I was talking to Red Hatters that moved from red to blue in the shift that moved from Red Hat to IBM, everybody was underlining this.
Yeah, but you know that Quarkus is now part of the Common House Foundation, and everybody was quite proud of that work.
Congratulations to that.
What's on your agenda as a foundation, especially now that we are both based in Europe, Max, as you mentioned, the creator and the kickstarter of J Bank and also involved with Quarkus, is also European.
How do you see the future of open source through the lens of the Common Source Foundation?
Especially now that the Cyber Resilience Act is getting into force.
So there are three driving tenets of the foundation.
This is how we started.
The first one is low governance model, which means when a project joins, there is no common house way to build and to do things.
The projects that join the foundation are already established.
They have a good community around it, and we can certainly help them foster the growth.
We have a group called the Executive Committee, which is comprised of at least two members of each one of the member projects, well, the main contributors.
This group will not impose a way to build or continue working with that particular project.
That's the first step, low governance.
The second one is financial transparency.
So if a sponsor joins and decides to sponsor either foundation or a given set of projects, they will know where and how the money is moving.
So the foundation does not become a black hole where money just suddenly disappears and maybe goes into a particular project or not.
So everybody will know how things are going on.
And the third one is the continued succession, which means that if the current set of maintainers for a project decide to go somewhere else and work in a different project or just stop working all together, well, the project will eventually solve.
So what we want the foundation is and make sure to provide the minimum structure and the right structure so that existing contributors and maintainers could move into the primary set of maintainers and have this continuing succession of the project and track.
With these things said, the foundation keeps looking for sponsors, whether it's enterprises, companies, or individuals that would like to provide their time, their efforts, and their money to keep all these projects and the foundation growing.
And we're also looking for creating guidelines and looking into common aspects that may affect all different projects.
What's going to happen with security?
What happens when a CDA is reported?
Do we know that a particular project, the members, the maintenance of that project, that they know how to handle CDs or things?
There will be continuous communication between members and the executive committee to get this thing done.
Maybe the case that the foundation comes up with not just guidelines, but maybe it's a set of tools, whether CLI, what have you, that could help an specific project.
And this is where we were able to continue the communication with the other projects and say, hey, we have this thing going on.
It helped project X.
Do you have similar needs?
Well, let's talk and see if this particular set of tools could be added to the way that you think.
Or if you are not aware of what's going on with a particular space of security concerns, then we can certainly pass additional documentation or links, but without giving you the idea of this is how you must do things.
Rather than here is a set of options.
You are free to choose what we have already done for others, or based on what we have, you can keep looking into some other alternatives.
So, as you mentioned, there are two types of sponsors, those that are providing the time, people that are getting involved, or companies.
Let's say I have an open source project.
When should I go to the Common House Foundation for support?
So, right now, because we are looking for projects that are well established and known in the respective communities, if your project has a steady set of uh this issue tickets and you have a good standing with your community, then your project will be a very good candidate to join.
If this happens to be a pet project or you're just getting started, then your project may show promise to join eventually, but it very likely won't be the time right now.
But we also have to think about the projects that will be in different stages of the development.
So if you're just getting started, the Common Files Foundation will likely not be a good place to begin with.
If your project is already established and is growing, this will be the ideal time.
But if your project is already mature and the community is still somehow engaged, but maintainers don't longer have much time.
So your project is now going into maintenance mode and almost going perhaps into zombie mode, then the foundation they would definitely will do a review on a case-by-case basis.
But it's one of the discussions that we had early on in the definition of the foundation.
What's gonna happen with projects that happen to be in this particular stage where they're perhaps already close to their sunset?
One of the things that we would like to have is an idea kind of like an animal shelter, where the maintainers could donate the project to the foundation, and there will be a set of people, whether it's a staff or not, that will keep the project alive such that we can find the next set of maintainers that will be willing to take on the project.
And if that were not to be the case, then we just have to declare that the project has to go completely out.
So we will find a way to make it happen graciously.
So, in recap, if your product is fairly new, maybe right now is not the time to join, but we can keep an eye on when will be the best plus moment.
If you are in your teenage years or close to the mature years, then that's the right time to do it.
And if you're in your toilet years, you still come to us, let's have a conversation and let's see what can happen.
So definitely useful.
And I have a couple of ideas about who can be in that space.
So I'll reach out to them and maybe it's a match.
And you'll have another non-Java project joining the Common House Foundation.
But let's see how can people that want to contribute contribute?
One of the things that we do with our issue tracker is that we apply different levels, and there's always a little that says help wanted or good first issue.
So these are the ones that you can have a look at.
And hopefully, this is something that you can do in just a couple of hours or maybe it's just a couple of days.
Those are the issues that can help you get started to know the code base and to fix an issue that doesn't require you to learn a lot of things upfront just to get it done.
The other thing that we encourage, at least here in Switzerland where I'm streaming from, we have a series of events called Hacker Garten in different cities.
It's just a set of people that like to come together and hack for a few hours on any open source project that we think will be fun, and we push the contribution to that particular open source project at the end of the session.
So someone that would like to get started with the first open source contribution, events like Hacker Garten are ideal.
Someone that already knows how to do open source but stumbles with your leaser as a tool that may help them, but they don't know yet how to get started.
When again, this is one particular event that can help.
For those that don't have access to a hacker garden event in person, we have them in Switzerland and in Germany.
The other option would be always reach out to our discussion page, frequently hosted on GitHub and start a conversation in case that you think, well, what about this particular feature?
I think about this other tool that I use and my work, but it's not integrated with Jarrele Easer.
Wouldn't it be cool if we could do this or that?
We can get into a discussion on if you would like to provide a patch for it, or if someone else can help you, or is someone else could provide a patch for it?
So nothing special here.
You are welcome to get contributions, but first get the issues that are labeled for people that have a first starting with contribution.
Yep.
And if not, start a discussion, then people will find a way to contribute in the end.
I think that based on the discussion that we had last time, I think I mentioned that we were close to providing support for salsa.
Yeah.
I haven't written a blog post.
I've been very bad at this, but it had to be make some sort of announcement that we do provide a native builder for salsa, at least for the GitHub implementation of Salsa.
So if you happen to run your builds, whether it's on GitHub public on GitHub private enterprise, then you can use this GitHub Salsa generator, which requires you to add more Jamal to your GitHub actions.
But if you happen to use LISA, then just using a very specific reusable workflow for Salsa and a Jamal file or whether it's Maven is the same, it will make it work.
So there's less configuration that you have to do.
And the first thing that we prove is that you can do this with Maven projects or GREL projects, where we expanded additional demos for languages that provide cross-platform compilations.
So Go, Rust, Sig, C sharp, JavaScript or TypeScript, whether you use Dano or Bun.
I think we also have a demo for Ocamel.
The point is that you can quickly see that if SASA is something that you need and something that interests you and you don't know how to get started.
Using this native builder for SASA with your research is very, very easy to do.
You definitely make it sound like that.
So I'm sure that it's actually thank you for sharing these insights, Anders.
And thank you for your time.
And if anyone is interested in open source, it's very easy to get started.
Just open a ticket on the open source project that we're working with.
Let the people on the other side of the wire know that you're working on it.
Maybe you find something that is not working properly or unsuspected, or maybe there's a missing feature.
Just open a ticket.
You don't have to send a patch, you don't have to send code or test cases to begin with.
Don't feel like pressure to do so upfront.
Just start a conversation and see where things go.
Okay.
So guys just do it.
Yes.