Wicked Good Development is dedicated to the future of open source. This space is to learn about the latest in the developer community and talk shop with open source software innovators and experts in the industry.
In this episode, Joel Orlina joins Kadi Grigg to provide insights and knowledge on “The Secret Life of Maven Central”, his talk given at Devoxx UK and OpenSFF Day. Joel sheds light on the previously unknown history of Maven Central and how it works under the covers. He also discusses how the Central team addresses critical security risks like dependency confusion, how it responded to security events such as Log4Shell, and most importantly, how you can get involved.
Listen to the episode
Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm
- Kadi Grigg - Host - (Twitter: @kadigrigg)
Joel Orlina- Engineering Manager at Sonatype - (Twitter: @sonatype_ops)
- Blind Men and an Elephant
- Sonatype Nexus Repository
- AWS S3 Bucket
- AWS Elastic Beanstalk
- Bintray Sunset Announcement
- Maven Central Support Services
- Beta Test Sign-Up
Hi, my name is Kadi Grigg and welcome to another episode of Wicked Good Development where we talk shop with OSS innovators, experts in the industry and dig into what's really happening in the developer community.
For today's episode, we're joined by Joel Orlina, who's coming to us today from Sonatype to talk about a presentation that he previously gave on “The Secret Life of Maven Central”.
Joel, welcome back. How are you?
Fine, thank you. Nice to be here again.
Good. So today's all about your presentation at Devoxx UK that kind of went viral all about the secret life of Maven. So I've got to ask, how did you come up with this talk?
Yeah, you know, I wish I could take more credit for it, but I can't.
So the truth is that Steve Poole, who’s also at Sonatype, in our Developer Relations organization, Dev Rel, actually submitted the talk, and I actually didn't know about it until we got closer to the May timeframe, when Steve was asking for supporting data and maybe some anecdotes he could share. And, you know, I essentially was informed that yeah, it might be a good idea, not just to help Steve out with the narrative and the story, but maybe even provide you an opportunity to co-speak with him at the show.
And, as luck would have it, a bit unfortunately, Steve came down with COVID, right before he was supposed to actually attend in London. I mean, Steve’s from London, so it was really, really, you know, quite fortuitous that I had sort of got roped into, at least, helping put together content, put together backing data, and ultimately put together the slides that I ended up delivering on the Devoxx floor.
So it, was really, really several, several batches of, you know, good and not so good luck working together to produce the talk. I actually want to share that one of the things that I use, or I refer to, in the talk is the abstract. It's actually exceedingly engagin, what Steve wrote, right? He, I think, if I'm remembering correctly, Maven Central, I mean, it's just there, you never think about it, it's ever present. It's like the stars, it's like electricity. Right.
And I found that that's a really great way to engage people who may already know about Maven Central, but have no idea what it takes to run it. And I think that, you know, that's been the the tack I've taken in terms of spinning out slides from the content was that that real kernel of inspiration from Steve sort of calling, reminding me, that when Maven Central is up and running, it's it's meant to be invisible. It's meant to be real, so reliable. And yeah, I think that that's actually turned into, you know, not just the content that I shared at Devoxx. But also, now at one subsequent show, you know, the Linux Foundation's Open Source Summit was in Austin last month, and I was there giving a brief abbreviated version of the same talk. And once again, I have to thank Steve for the the genesis of the idea for the inspiration.
But yeah, I feel like I came in sort of late to the game. And did you know, now, it's my face that's associated with this doc?
Hey, at least, you know, you get the good end of the deal on that one. Right?
Let's hope so. Yeah.
So I don't want to spoil the fun for anyone at home, because we are going to be playing the audio from the talk. But what are the three–and there was a lot of good kernels in there–key takeaways for anyone who's listening to this talk track?
Yeah, I feel like keeping in mind, the abstract is a good thing, right? Understanding that when you type “mvn clean install,” something magically happens at the end of it, you have, you know, reproducible build. And the fact that, that build happens, and with luck doesn't stall for mysterious reasons, and that it can happen automatically and continuously, if you're building multiple times a day is is the product of years of effort. And that the central team has put in to not just building out the services, but maintaining them. Right?
And I think that it's something that dawned on me when I was finally giving the talk, and I've been in Sonatype since 2010. And Central predates me by probably four to five years. And having worked on it for so long, it's been interesting for me to sort of ask myself, “Well, has this talk been given before?” and I think that Devoxx is a developer focused conference and a very Java heavy conference as well. And I think that, you know, I can't think of a time that someone who has worked on the Central team, and primarily the Central team, has actually shared this kind of information to a developer audience that uses Maven every day.
So that's the other thing, is that this is information that Sonatype has always had, always known. And I feel like it makes it out into other talks. But this is kind of a big deal for me personally, I think, for the company, for us finally realizing, yeah, it has been a pent up demand for this kind of information. So that's kind of point two, right? That this is kind of like the first exposure of this.
And the third point is that, yeah, again, not to spoil anything. It's not easy. It takes people, it takes effort, it takes money. And I think that my hope is that, you know, once people start listening to the audio, and start to get an idea of the scale of what people consume from Maven Central, it sort of lines up that the effort to make all that possible is also commensurate in scale. So….C. Rob 6:02
Our next speaker is Joel Orlina who is sharing Maven security journey. Joel is an Engineering Manager at Sonatype, where he helps with the care and feeding of the Maven Central, while also contributing to product development. Please join me in welcoming Joel. Take it away, sir.
So thanks for the intro C. Rob. My name is Joel Orlina. I'm an engineering manager at Sonatype. I've been with Sonatype since 2010. And as an engineer, manager, I support multiple teams, one of them dedicated to not just the continued operations of legacy services around Maven Central, but also to some of the future plans, some of the new services that we're building to modernize and improve people's interactions with what is the single largest repository of open source components for languages that target the JVM.
I used to say that Maven Central was primarily for Java developers. But I think the truth is that view developed for us in Scala, or in Kotlin. And all these things target the JVM. Clojure, you know, there are components in Maven Central for all of those languages.
So I'm going to start with some definitions, maybe a little bit of storytelling around what I think of when I hear Maven Central. When I first gave this talk, it was for a Developer Focus conference primarily for Java developers. I doubt that we have a majority of Java developers here, so I hope that some of the story resonates and gives you a little bit larger background into what a software package repository, like Maven is, what it consists of, and what it takes to run it. And to help tell that story, after the definitions, I have some high level architecture, I won't get into the nuts and bolts, I'm here at the coffee break, I'll be here for the next few days, feel free to come find me if you're actually interested in seeing more of the nuts and bolts.
When I first gave this talk I actually had more time. So I'm actually going to skip central by the numbers, a little bit of statistics around growth around its contents. And I'm more than happy to share that as well. Maybe if we have time available, I might come back to them. What I really want to get to, though, is a little bit of operational description. You know, I think I've seen many presentations today where people go back into ancient history. I'm gonna go back to 2021, which was a particularly eventful year for, I think, not just everybody here, certainly for the team at Sonatype, maintaining Maven Central, we'll go take a look at certain events that punctuated that year, and actually had security ramifications for the way we operate central for our users and for us as maintainers.
And the last few slides are going to focus on the future. I actually have a slide with a prototype of sort of the next generation of the publisher portal that we're actively building. There's a slide talking about our involvement with OpenSSF, which has been incredibly fruitful today. But I'll get to that at the end. And with luck, time allowing, I'll take a few questions before letting everyone go off to get coffee. I feel like I'm in the unenviable position, not just blocking people from caffeine but following Mr. David Wheeler, thank you. That was fabulous presentation. And I hope to keep the energy going.
All right, what is Maven Central? So when I give this talk in front of Java developers, I have to ask them to indulge me a little bit. They already know what it is. So this illustration, it's actually one of many in a Wikipedia article. If you go on Wikipedia and search for blind men and an elephant, you'll turn up this great article about a parable from the Indian subcontinent. It's very old. The first I think written evidence of it is from 500 BC, but reportedly it's much older than that. And it tells the story about five, six, blind men who, for whatever reason, are asked to describe an elephant.
So one of them comes up, manages to wrap his arms around the leg and says, “Oh, it's a mighty tree trunk.” The other one grabs the tail and says, “Oh, it's long like a snake.” The other one, I think grabs the tusks, “Oh, it's pointy, it must be a spear.” Another one, the ear, “Oh, it’s giant fan.” Someone on the back says “it's a great wall.”
And Java developers actually don't think about Maven Central at all, the original abstract of this talk was Maven Central. It's like the stars, it's like electricity. You don't think about it, because it's there. If it's dark, and you look up, you see the stars. Yeah, that's what Maven Central is, something that operates all the time without our knowing. But I like the support all I have as part of my job supporting the community that uses Maven Central. And I get support requests that actually remind me that, depending on how people use Maven Central, they have a very different experience of it. Much like six blind men and an elephant.
For the most part, developers, those of you here who are Java developers, will happily type “mvn clean install.” And after Maven is done installing and downloading the internet, you have a jar file that you can actually send downstream. That is the bulk of the experience of Maven Central.
But there's a large community of publishers, the people who actually are responsible for putting those great open source bits out there. And they have a very different experience as well. And part of the team responsibilities in central at Sonatype are for that publisher community.
We also offer a service and you'll see this on the architecture slide, where we focus on how people can do a little bit of research on those components, component metadata, age and data that's in the POM (the Project Object Model). And that's also a service that we support, that's very different from the other experiences of people using Maven Central. And that's where most of the overlap between this illustration and Maven Central actually lies.
If you read the article, you'll actually see that the parable kind of falls apart in terms of applicability to Maven Central. The blind men, actually, in many cases get into an argument. They feel like their tiny appreciation of the elephant is the only truth and they come to blows in many of the retellings. I don't think that's actually happened in the Java community, but I really enjoy the parable of the blind man and elephant. And it’s because I'm not a blind man, I'm actually someone who has known this elephant for the past 12 years and has been tasked with taking care of it. This illustration is, I think, the most chaotic one in the article. And it's my favorite. I mean, look, there's all this stuff going on. And I think this accurately captures many points of the past 12 years for me, and what have I learned from taking care of an elephant?
It's very, very large. It is very, very expensive to house, to feed, to clean. When it becomes unruly, it is very difficult to calm it down and make sure it doesn't hurt itself and the people around it. When we get into the 2021 year in review, I hope that some of these analogies become a bit more clear, but this is absolutely my favorite picture of blind men and an elephant because it really captures some of some of my days, I think there's one person in there who's about to die. And I'm like, “That's me,” actually. Not today. But some days.
All right, very high level architecture. And I apologize if this becomes a little bit too Java heavy, I promise, I'll try and keep it high level for the audience here. And if you want details, come find me.
I mentioned how we have different people with different experiences. I've categorized them on the left hand side, publishers, repo users, these are the people who actually access repo1.maven.org. That is the host name for Maven Central. And then there are users of search. These are people who are doing more of the research style in more component metadata type lookups.
But publishers actually interact with a Sonatype product - several instances of them. I'll actually get to how we got to several instances in the year in review. But we use Sonatype Nexus Repository; it is there as a caching proxy. But there's actually functionality in the professional version that we use that ensures a certain level of quality for the components before you can actually publish them. Are your components well formed? Do you have a complete set of metadata around them? Are you providing sources and Javadocs? Do you have PGP signatures? That is all guaranteed by the publication software.
This is actually the area of the Maven ecosystem, that actually, where I receive, and my team, receive the most interaction with customers because we raise a non-trivial bar for people to vault over before they can even publish. We're not letting you in unless you can actually meet these requirements, and you'll see in the year in review that this has become a source of extra effort for us. But it's effort worth paying, because it ensures some baseline quality inside the Java ecosystem.
Let's see traveling counterclockwise, you'll see, we have our ubiquitous Jenkins icon we use posted instance of Jenkins actually, for a lot of orchestration, we probably misuse it. But at the end of a publishing activity, the bits end up in an AWS S3 bucket. And S3 can be easily hooked up as the origin server to any one of a number of CDNs, the CDN that Maven Central relies on is Fastly. Fastly should be a name that's known to practically every person who works on a package repository, it is top tier global CDN. CDN, we've actually been with them, I guess, since very close to the original founding, they've been an exceptional partner to Sonatype, and they've grown quite rapidly, but also quite stably.
The point I wanted to make about this particular section of the graph is that Maven Central is relied on by millions of Java developers, and depending on how their build practices are set up, if you cannot download a dependency for your build, your software does not go out, that software does not get published, other things start to fail. And so the choice we've made to actually go with Fastly, and then back Fastly with something like AWS S3 is about going with something that is internet scale. You know, people who are running a package repository have in the back of their minds, what do we do? What do we do if the repo goes down? What do we do if there's some sort of event that takes one piece of the infrastructure down. We rely on both AWS and Fastly means that we don't have to worry about that.
If S3 goes down, if Fastly goes down, the rest of the internet is down with us, you've got bigger problems than your build from Maven not completing. So the repo users here are the immediate benefits you interact with Fastly. This is where “mvn clean install” sort of hits to actually get your build to go. From the same S3 bucket, we have a little bit more orchestration, I believe this is the AWS architecture icon for Elastic Beanstalk search.maven.org, which I'm not sure how many people are familiar with, uses an index built from the same bits inside the repo origin server, and Elastic Beanstalk serves up the front end.
And I'm not sure I'm gonna go into too much more detail on search. We might talk a little bit about the functionality when we get to the forward looking slides.
Alright, central by the numbers, I usually spend a lot of time on these. It's an elephant, it's big. If we have time, we'll come back to it.
2021, some ancient history. 2021 was interesting for all of us. I think everyone, you know, if you read ahead or go read to the right side, you will actually see I'm going to spend some time talking about the Log4Shell response. But we had great plans for Maven Central. And starting with the team.
I feel like when I started at stenotype, Maven Central was something that our CTO and Co-Founder, Brian Fox said, “In between the things I need you to do normally, you should take a look at this repo1 thing.” I've got a few things that I can't tend to now and here we are today, rand Maven Central is now larger than ever and more important than ever.
Well, it's 2021. I think that Sonatype got to the realization that one, maybe one and a half, people who were asked to keep the lights on in between their day job certainly wasn't sufficient. So we actually brought on two DevOps engineers to improve stability across some of the services I showed you in the high level architecture. At the same time, Sonatype was undergoing company wide adoption of Scrum as an agile methodology. And we actually did a whole mess of backlog grooming and planning. And on February 2, we kicked off sprint one for central team. Well, on February 3, was the announcement that Bintray was shutting down.
And this is something that is definitely more in the top of mind for Java developers. But just so, for the people who aren't Java developers, Bintray is essentially a competing, open source package repo with a superset of components. So you have more components from other repositories than just Maven Central. So they actually mirrored Maven Central and then provided an alternate means for people to publish to Maven Central. Well, on February 3, they decided they were getting out of running their repo and that they were going to shut down. Their initial press releases weren't extremely crisp about what the migration plan was for people.
So in the first few days after February 3, there were a lot of questions around the community. But like, “What do you mean, you're shutting down? Where are people going to get my components now? Where can we go?” We at Sonatype said, “We have an open source Java package repository, you should feel free to publish to us here are instructions here is the public JIRA project where you can sign up and publish.”
And that started a giant chain of events, I have the link here, the announcement is still up on the internet and the updates as the actual repo is still live and running there. It's read-only, but they continue to serve their artifacts, which is great, I'm actually quite relieved that that's the position they ended up in. But that's as of right now, back in February of 2021 there was a lot less clarity. And I'm going to highlight these two charts.
The one on the left, I want to call out the February to March giant stair steps. So that represented, I think, 20 to 23% increase in the bandwidth that users of Maven Central started consuming. We had always known that there was a significant amount of people who were consuming exclusively from Bintray versus us, but we never could quantify it. But with the announcement Bintray is shutting down, people migrating over to Maven Central as the place where they could officially consume their artifacts, we saw this increase. And the good news is that thanks to fastly being this capable partner and being mindful of how important they're continuing we serve artifacts where - we had no issues shouldering this load, right.
So this is sort from the perspective of the machinery of the internet, right, between fastly and people running “mvn clean install,” as long as they were able to find their artifacts on Maven Central, there was really no blip in terms of the quality of service with the Bintray shutdown.
This other chart, I hope, captures the human toll of it all.
So support for services related to Maven Central come through a JIRA that Sonatype runs issues.Sonatype.org. And we normally expect January to be a bit depressed as people are still out on holiday. But what we did not expect was this giant leap, you know, in February, March, and then a leap up upward again in April. And this was all related to activity around the bintray shutdown.
First off, publishers who knew that the shutdown was coming and very quickly realized what it meant to them, started signing up in droves on our services. So this leap in the blue chart is a specific issue type called “new project”, and we saw the new project numbers jump up entirely, you know, really looks like it doubled right in January. February is sustained, through March and then up again in April.
This other color represents publishing support. These are things that aren't just “I'm signing up for a new project.” And I'll explain this a little bit by going back to something that we thought about when we saw the the announcement that might actually be very germane to some OpenSSF topics that the folks here may have already heard about.
So in the Maven ecosystem, we uniquely identify components with three coordinates. You know, we don't just have a name or Maven speak and artifact ID and version, we actually have a namespace that is an umbrella for all them, which allows you to sort of represent your organization, a group ID.
If you've ever published in Maven, one of the more annoying things, probably one of the more necessary ones, is to claim your namespace with some sort of proof that you are actually serious about publishing. And these days, we ask people want to one: make sure that their group ID reflects a domain they own or at least control the content for. So com.jorlina, I would have to say, well, I own jorlina.com. And I would have to submit to our automated process DNS TXT record with some sort of record ID to prove that I own that domain.
Bintray, publishing to Bintray did not have any such mechanism. I’m still fuzzy as to what they accepted as proof of organization to claim a namespace. But one of the first things and Brian still there, I think it was Brian Fox who came and said to me, he's like, “Well, Bintray has been around for a few years, they don't have the same validation process we do. Wouldn't it be possible for someone who knows that something only exists on Bintray to buy a domain that is not owned by someone on Bintray and then sign up on Maven Central?”
If they were to have done that, our automation would have granted them access to a namespace they did not own and more importantly to a namespace that already had provenance somewhere else and was mature and in use by somewhere else. So this jump in human activity represents what we did at Sonatype to turn off that automation, we actually broke our own process for several days to think about what is the right way to honor this ownership from Bintray to ensure a safe migration to a safe landing spot that is Maven Central.
Ultimately, it involved a few tweaks to the automation, whereby we would check whether the project namespace existed on Maven Central already. And then we would check if it existed already on Bintray. And if it did exist on Bintray, we essentially threw it into another manual workflow, where we said, “It looks like you're trying to publish on Bintray. Well, if that's the case, we'd like for you to acknowledge that and then to follow this process to get yourself signed up.”
Won't linger too much more on this slide. But I think we measured over the next three months, how many projects we migrated from Bintray, either from people successfully signing up on their own or for us asking them to migrate. And we counted about 700 projects in those three months. And a lot of that was handled by sort of human effort, because we wanted to be sure that we were doing the right thing. And purposely, you know, turned off the automation to make sure that we understood the scope of the problem. And to make sure we had a viable and sort of equitable approach to a solution.
Before I go all the way to into the middle of the year, I guess one last thing about the Bintray shut down the light, that I like to call out is that when everybody decided that they needed to publish the artifacts anew on Maven Central, they had to publish them to one of our Sonatype Nexus Repository servers. We actually kind of got DOS’d a little bit, we did not realize the popularity of Bintray would turn into all these new requests. So between February 3 and February 25, we built up documentation, stood up new resources, and essentially built a new server with zero tenants on it. And on February 25, we switched our process where by default, we would provision people on the new and unloaded host.
Leading up to February 25th, we had continuous complaints of people saying my builds are failing or they’re timing out. And we had to unfortunately explain to them, “Yes, it's because you and everybody on Bintray needs a new home, and we did not realize that we're going to need to scale this quickly.” And so keep this in the back of your heads,we're going to revisit this at the end of 2021.
All right. So I’m actually really glad that I, you know, in retrospect now followed the David Wheeler talk because of the question about SBOM.
This is something that we turned on in mid-May of last year, where when you publish to Maven Central, when you sign up, you are automatically opted in to a workflow that will calculate an SBOM. Not a perfectly complete one, but one of the other open source components in your build that are sourced from Maven Central. We will then send you an email after the successful release of your build on our servers with a summary of what's vulnerable and other weaknesses, inconsistencies, potential license threats inside that minimal SBOM. And if you click the link, you get a detailed report. So when David said, “SBOM, not the silver bullet, right?” You know, just because it says what's in there doesn't mean you know what to do with it. We're trying to introduce a little bit of silver here, where we don't know where the fixes are yet, but we know that you are consuming this version that's vulnerable, this version that has a license, it's maybe a little bit copy leftish, you might want to take a look at it. And this is free for anyone who publishes to Maven Central through our site and will continue to be free for as long as we run a publishing stack for Maven Central.
Alright, think I'm still on time here. Here we go, the end of 2021–people are getting ready for holiday. And guess what? No one's gonna take a holiday. Because the internet's about to break in a horrible way.
So, I feel like it takes me some effort now to remember what happened at the end of last year. So bear with me while I try to tease everything apart. First off, we had to upgrade all of our software. As soon as the Apache Software Foundation cleared up which versions were not vulnerable, we made sure that any of the running services of Maven Central were in fact upgraded to use patched versions of Log4J. That didn't take too much time. What ended up consuming all the time was realizing that even though we had, what, 10 months to have people move to our new and unloaded server, it is amazing that all the people who are on the old server decided, “We have to upgrade all of our dependencies as well, we all have to publish new versions of our software.”
So the same timeouts, the same failures publishers all had to deal with in February, we dealt with all over again in December. And this time, it felt much worse. I feel like OSS.Sonatype.org, which is the main host that we published to, was underwater for three straight days. And we actually had to get volunteers from other development, DevOps, and SRE teams at Sonatype to essentially man our JIRA and say, “Hey, we saw that you were having trouble publishing the OSS that somebody typed out, right? Would you like to migrate to the new host?”
And yeah, I remember five people showing up to a zoom call on Saturday morning. And my having to tell them, “This is just in case we have more people to migrate.” But we did it, we got people moved to the new host. And thankfully, we had learned the lessons from February on how to quickly scale and what process to follow to move them.
The slides themselves don't illustrate any of that. These are actually from our Log4J vulnerability Resource Center, where we actually continue to calculate stats. There were still vulnerable versions of Lof4Shell/Log4J being downloaded. Not the fault of Log4J project, it's just people still haven't gotten the message and upgraded.
All right, I think I have five minutes left to quickly go through the future direction.
I mentioned that central team is actually actively building for the future. We've got, I believe, two front end, two back end developers, and a tech lead all trying to build the new central portal that is going to be what we hope is a centralized place not just for consuming metadata about the artifacts, but also publishing. To that end, we'll need to build a better sign up and identity management process. This is a thing that we care so strongly about, especially in light of all the issues that we've seen recently, like, “Do you really belong to this project? Should you have access to this group ID?” So organizational identity and management is definitely top of mind.
We are also trying to launch new bits of data products, including component popularity and categorization. We're still toying with how popularity is defined, is it raw downloads? Is it the “liveness” of the project? We have a research and analytics team at Sonatype that has categorized many of the most popular open source products. And the screenshot should illustrate that.
But before I go to the screen, I do want to just shout out to OpenSSF and the securing software repositories working group. I've had the pleasure of attending a couple of those meetings now. I believe they're every two weeks. They alternate between the EMEA friendly and the APAC friendly, but I stay up late to hang out on the APAC call. And they've all been terribly welcoming. And it's been wonderful to sort of build empathy with them, you know, these problems that we saw in 2021 aren't unique to us. There are certain things that we were better prepared for, but we are all learning from each other. And we are all building for a future where we all share the same responsibilities and with luck, leverage the same solutions–SBOMs and all the tooling that's available. So, last thing I have here is an actual screenshot from our staging server.
And it has a section for most popular packages in the last 90 days, most popular namespaces, popular categories. And yeah, so far, it looks a lot like search.maven.org, look up things by group ID, artifact ID and version, see some details on recent releases. But this will eventually be that one stop shop where you can consume information about the artifacts and also publish new information; publish your new artifacts and actually see that transaction log of all your artifacts. I'm supposed to mention sigstore is going to play a huge, huge deal in this publishing process. Right now we require PGP signatures. But you know, it's all decentralized. And sort of the tooling around that verification is something that we've never been great at. And it's super great to be working with everyone at sigstore to actually have something centralized that we can all leverage across ecosystems.
Slide In case people are interested in helping, I think all the presentations have the “how you can help?” if you would like to contribute to the future face and requirements for Central, we actually have a Google form for you to sign up central-beta.Sonatype.org, the quickest path to publishing the Maven Central sign up for IO.GitHub.jorlina and we will actually ask you create an empty repo with your own OSSRH ID and you will get automatically provisioned. We also support this for BitBucket,GitLab, Gitee for the Chinese repository, and I think one more that escapes me right now.
So yeah, you don't have to own a domain to publish Maven Central. Just have, you know, GitHub account.
Ladies and gentlemen, Joel Orlina.
All right, last question. If people feel so inspired from your talk about Maven Central, how do you recommend that they get involved?
Yeah, so if you listen to the end of the talk I hope that I actually mentioned there, we're looking to be building the next generation of that experience, right? Both from a consumer’s and producer’s perspective, we're trying to sort of modernize Maven Central. The Central team is focused on that really for over the next 12 to 18 months, we sort of staffed up the team to be able to finally do this.
If you're only listening to the audio, you may not actually get to see the link, but we are actually collecting beta feedback. And I believe that that link is actually active and easy to remember, I believe it's central- beta.Sonatype.org, central-”dash”-beta.sonatype.org.
And we've, we actually shared that link at the end of the presentation for people who might be interested in the direction that we're going. So that's, I think, the the primary way I'd recommend is one, keep using Maven Central, keep engaging with those of us who support it, but if you're looking to have an impact on where we're going, we actually are starting to collect that information. And we actually are probably by the time this podcast makes it makes it out, going to have something wider to announce in terms of the availability, of least at least our first pass on, you know, the new portal for consumers. And that engagement doesn't stop there. Our hope is to get something out for consumers of Central to start getting their ideas in. But our goal actually is to modernize the publishing process as well. So it's really the developers who not just rely on central to getting their stuff to build but also the people who put stuff out there for other people to consume. And that's where I think, you know, getting people's involvement is going to be supercritical, being able to shape that that publisher experience for the next generation of what this team builds.
Well, you heard it from Joel. Go out and explore, keep using Maven update. But we'll thank you so much for stopping by. We look forward to having you back for updates on where Maven is now.
Thanks for listening to another episode of Wicked Good Development brought to you by Sonatype. The show was co-produced by Kadi Grigg and Omar Torres and made possible in partnership with our collaborators. Let us know what you think and leave us a review on Apple podcasts or Spotify. If you have any questions or comments, please feel free to leave us a message. If you think this was valuable content. share this episode with your friends. Till next time.