 So good morning everyone. Welcome to day two of ApacheCon North America and the wonderful heat of Miami. I'm from Jersey. I don't like the heat. So yeah, I'll get over it. So I want to talk to you guys a little bit about how to actually get out of the incubator. A lot of these talks tend to focus on how to get projects into the incubator. We'll talk a little bit about that. But my main thing is once you're in there, how do we get you out into a successful top level project? So who am I? I'm on GitHub. I'm on Twitter. I got started originally in a pottling called Apache Delta Spike, which came from Red Hat and some external contributors into Apache MyFacesCody and became its own top level project. I learned the Apache way through the incubator. I was not an existing member. I am fairly new to Apache from a organization standpoint. I started in 2011 and I would say for the first year and a half, I really didn't do anything with Apache outside of work within my project. I've been able to grow though, work with ActiveMQ, work with UserGrid, Juno, Tamiya, Areotosca, Ponymail, a bunch of other things, as well as some stuff outside of the ASF. And if you want to get these slides, I know that they are attached to the presentation, at least last I checked they were. And when I look, they are. I hope that they are for everyone else. Otherwise, I do have a URL shortener if you want to get to it that way. So what is the incubator? The incubator is really where communities come to learn the Apache way. We take a community who might be focused from a single company, a single group of individuals who have common goals, research projects, and everyone who's really focused on just their thing to get them acclimated to how to operate as an Apache organization. Apache organizations are very merit-based. You basically gain following by showing that you know what you're doing. And we give you more trust as we are more comfortable with the idea of you giving that back. It is the main entry point for any new projects coming to Apache. So you will see some projects go straight to top level. Those are typically very member driven. So a high concentration of existing Apache members will likely form the initial PMC of that project. And those do go straight to the board. There are some nuances with them. They will typically be very member driven. So they already know how to operate an Apache project and already pretty diverse from a community standpoint. But it is more common that we're seeing single company really vendor driven projects who want to diversify coming into the incubator first. And that is really where we see a lot of growth as a project. So why would you want to come to Apache? There are some reasons you want to build a diverse community. You are a single vendor who wants to publish a standard or publish some common goals. And you want to get out there to get more people interested in your project. Maybe you've done it on GitHub for a little while and have seen some growth. But you want to get some bigger infrastructure behind it to come to Apache. We typically don't want to see projects who simply want to be labeled as Apache Foo. So if your goal is to come in because you want that Apache prefix on your project, you might not be a good fit for us. Because we're really more focused on you becoming a stronger community and less focused on you wanting that Apache brand. In fact, if you look at some of the questionnaires that you go through in the initial proposal, one of the things is to look at, are you doing this because of a branding issue? You also may want to extend or strengthen your existing community. It could be that you are a single committer type of project, a couple of people who get together every now and then working on something and you want to be able to diversify outside of your own goals. So by having a foundation behind you, you are trying to move away from benevolent dictatorship and want to instead grow to outside contributors feeling that they can give as much as the initial contributors did. So why would you incubate? There are a whole bunch of reasons why you would incubate over going straight to a top level project. You might be focused on learning the Apache way, the Apache fundamentals, all the policies that go into becoming an Apache project. And because of that, the incubator is typically the right way for you to come in. You want to understand how to cut a release. You may not know all the mechanics behind it. Justin will actually be giving a presentation in this room right after this to talk about the intricacies of building that first release and really what we're looking for. Another reason is you might be looking to learn the Apache way. That's how I learned it. I've learned it through the incubator and I think it's a great thing to learn. You start to understand not only how to build an internal community within your project, but you also start to see how to build in corporate type of community. There will be a talk a little bit this afternoon, I think around 2.30. It's more of a panel discussion around the incubator. It's sort of a new topic, so we'll be getting a few people together to talk through that. You also want to be able to prove out that you can grow a community. If you're starting from five people, 10 people, and you've been that way for two years, you might be getting to a point where you have to show that you can gain more people, gain more traction into your project. Coming in through the incubator might be a way to do that. We generally have more relaxed policies around voting and committers and PPMC members than you would see in a top-level project. The other reason is you're not sure of the licensing status of your project. This is a very awkward one, but let's say you have built some code, you have some existing projects, some existing source code already baked in to your application, you're not sure of all the licensing state, and you actually need legal assistance to get that cleared up. You are effectively becoming an Apache project, but one of the things we do help you with is the overall IP clearance and SGAs that would be required to make your project work as a top-level, so it helps you clear a lot of that stuff up. It is typically where we find the most hardship in pod links. How do you incubate? If you are getting started in the incubator, is there, this is a small crowd, how many of you are not actually in a pod link today, or do you all represent existing pod links? You're not? Okay. You might be looking to bring in a new project to Apache. One of the reasons you might be doing that is to form a you have some existing code base, you want to get more people interested in it. The first thing you have to do is find a champion. The champion is the person who's going to act as your mentor, your guide through the proposal process. Champions aren't necessarily your mentors for once you're accepted, although we really like to see champions stay on for the duration of your project, but a champion is really to help you get acclimated to the beginnings of Apache before you're even a part of Apache. Helping you navigate some of our mailing lists, some of our wikis, and getting your actual proposal through the incubator, except it as a pod link. They are very focused on dealing with you on a personal basis, so a lot of the communication that you're dealing with with your champion will be private, it will be off list, although we're hoping that it stays as limited as possible to just forming the proposal. Once you've begun to form your proposal, you will start to discuss it on list, and ideally you will start to find mentors on your project from the incubator general list, so some cases you might have a pre-existing list, people that you may know internally within your organization who work with it, existing committers on your project who have worked with Apache in the past and are willing to stand up for you, or you might have brand new people who are interested in the project from a technical standpoint, like let's say you're working on a CDN network, and we have a whole bunch of people at Cisco at Apache, and they happen to be also interested in a CDN network. It might be a good fit for some of them to help you get through the incubator. Drafting your proposal will probably be a long time depending on how complicated your project structure is. It's usually a month from what I've seen from most pod links, so don't be surprised if it takes a while. At the same time, you want to make sure that you are in constant communication, so as you as a prospective pod link are trying to focus on getting into Apache, we want to see you as quick as possible turn around proposed edits that your champion might be giving to you to make it into a good proposal. Usually your champion will help you draft in a number of ways. They might be directly editing the wiki, they might be posting the actual proposal to the wiki that you have built offline through email communication back and forth. It all depends on how comfortable you are with the process and how comfortable you are typing all this up. It's not uncommon to simply see a champion one day just post a massive proposal to the incubator wiki and put it out there for an initial review and the general list. It depends on how closely you know that champion. That was actually the case for net beans when they came on board. We suddenly woke up one morning and there was a massive list of 500 potential new committers coming in. Your mentors will help guide you during the incubation process. They may help you prior to incubation as well, depending on who they are and what their strengths are, but ideally the champion will be doing a lot of the pre-incubation work with you. Ideally we want to see your champion stay on board and the best podlings are always the ones that have their mentors stay on for the duration of their incubation period. Usually your discussion threads will lead to more contributors and these would be people who have not experienced your project in the past and potentially have some thoughts on what they want to do, what they want to see from your project. You have to be very careful about these types of contributors and it's actually a good time to start looking at how to leverage the Apache way and the Apache voting process to bring in those new contributors. There are a lot of people who will sign up because they're very interested in a project that they want to be a committer and that's okay. It's also okay to tell them, let's wait to see your contributions to the project and we will vote you in as a committer if we feel that your contributions warrant that. There are a lot of cases where I've seen people sign up to commit and throughout the entire incubation process they've never committed code. They've never even subscribed to the mailing list for that project so be very selective. Your discussion thread for the proposal will also lead to your very first vote. Sometimes the champions kick this off. Today we just had Pulsar start off their vote thread and that vote thread was kicked off by their champion. In most cases it should be the people coming from the project kicking off that vote. There's also really no notion of a binding vote versus a non-binding vote. There's very few cases that I've seen where a poddling is not accepted into the incubator and if they get to the point of actually submitting their proposal to a vote it's pretty much an affirmative we are going to move forward with this. We will usually point out problems with proposals during the discussion phase and ask you publicly as well as potentially privately to consider what you're asking for and make sure that you're actually ready to go for something like this. A good case like this might be we've looked at your source code and there's a large amount of GPL, LGPL licensed source code within what you're donating. You can't just bring that to Apache. We can't re-license that source code under Apache. If you give us an SGA we can deal with that. If you're not giving us an SGA for that source code you can't come to Apache. We cannot deal with your LGPL code. It's simply one of our hard rules from a licensing standpoint. We want category A software that might include Apache licensed, MIT licensed, BSD 2 and 3 clause licensed source code but not anything that would cause a sort of copy left situation for an incoming project. So you have to be very careful about what it is you are trying to bring to us and there are certain cases where we've basically said we can't do this. NetBeans is actually another good example in this area. They have certain portions of the NetBeans IDE that are basically forks of the JDK. They cannot include that in their actual donation into Apache because it is a derivative of CDL plus GPL license code. So they're trying to figure out a way internally with an oracle to bring that over or make it a publicly dynamically linkable solution. So you've had a vote thread. You've had a discussion. You've had a vote. The incubator has accepted you. So what starts happening now? This is the very first time that you can be considered Apache foo for whatever foo is. Prior to the acceptance of your vote, you are not an Apache project and you would be violating our trademarks by saying you are Apache foo. So we do ask that prior to your acceptance you are not referred to as an Apache project even though it might be looking very good that you will get accepted. It's very rare that you'll run into this type of problem. There was a conference I was added back in September. One of the projects happened to be labeled Apache foo. They weren't actually accepted to Apache. They did get accepted a couple weeks later but it gets into this weird state of you're not actually Apache, whatever you said you were. We do want you to get started as soon as possible. So there are certain cases where I've seen pottlings take three, four months to actually start bringing their source code over, start bringing their discussion lists over. That is unfortunate but it is the fact of life just because of what the communication, the confusion around how to actually bring this project in. If you're an existing GitHub project, it's very easy to simply add one of the infragives to the committer list and they will be able to help move your source code over. If you are not already on GitHub then it's a matter of just getting a repository created. We've been able to automate about 95% of that for you. There's now just a simple web form. Your champion, your mentors can just go to create a repo and it'll be up within a couple hours. And as soon as that's there, if you have a software grant, if you have IP clearance that you might be going through, you can start writing to our repositories. The champion is done at this point. So while they might be helping you with the boot strap, if they are doing that, they're really becoming more of a mentor. And that is where the delineation between your mentors and your champion starts to change. Your champion was about getting you into the incubator. Your mentor is about getting you really out of the incubator. We hope that they are continuing on as a mentor though. It makes a lot of sense and because you are already familiar with them prior to joining Apache that you might be more comfortable with them staying on. There are certain cases where people didn't actually realize this difference and didn't make themselves a mentor. If that is the case, it's very easy to just add a mentor to a potling. There's no vote required. There's nothing. It's just, hey, I'm mentoring this potling now. Great. The other thing as mentors we'll deal with for you are mailing lists, email archives, getting accounts set up. So everyone would be expected to sign an ICLA as an individual contributing into Apache. If there is a company behind it, the company may feel the need to submit a CCLA. However, we don't actually require a CCLA. It is mostly to be able to say from company to company there is something on file saying these people who are your employees are being given right access to a project that you donated to us. There is no additional legal binding around a CCLA. So it wouldn't actually give you anything to be able to say this is the only project they're contributing to. We want to see you migrate your development over as soon as possible. We want to see everything in email. So we are very old in this case. You've heard a few people use the term gray beard in some discussions. I'm sure this isn't the first time. So we like email. We like email archives. So the more that we can see in history, the more that it's searchable, the better we are to be able to cover what has been discussed. We do run JIRA and Bugzilla internally. Most projects are using JIRA, Bugzilla, really old projects. I don't want to use that term, but Tomcat, some other projects, OpenOffice, I believe are using Bugzilla instances. So you do run into a couple of them if you do want that. We are starting to leverage GitHub more and more. So projects as they're coming on board, it may make sense for them if they're already doing GitHub. We can now support GitHub-based projects. So by being a GitHub-based project, you would have direct access to issue management, Wiki, direct write access to merge pull requests directly on GitHub. If that is what you're used to, we don't have a problem with it and we can actually support you now going forward. We have a couple of top-level projects who have been prototyping it for a couple months now. We have a few podlings who have started to use it. We had one just converted this week, Anitator, and I think MXNet is coming over pretty soon as soon as their source code comes in. So we do have a couple of projects coming in, and it was originally spun up for the OpenWis team to be able to prototype. If you are, yes. Yes. So the question is, are we talking about the GitHub mirror? In this case, we're actually talking about instead of the GitHub mirror, you have GitHub as your primary source code repository. What we do is we create individual teams for every project, including podlings, which is where the whimsy roster tools come in to be able to manage who actually has write access to that podling or to that project's source code. By doing that, what we're doing is creating a team in GitHub, assigning members to that team depending on what their permission scheme is, and that gives them write access to those repos. We mirror those back using a tool called Gitbox, very similar to what we did for Git mirroring, except it does bidirectional. We don't recommend doing it bidirectionally, though. So while it does support some bidirectional, I would strongly recommend, and this is especially based on what Infra was just telling me about half an hour ago, write to one repository. If you want to use GitHub, use GitHub. Yes? While you're in Incubation, if that's something we do after we graduate, or can we do it while we're in Incubation, we started off the kind of all-play, and we wanted to go and go GitHub if we could, and we play, or can we ask for it now? So the question is, can we use it now as a podling? Absolutely. It is open. Yes, sir? As a top-level project? So the question is, can you use its TLP? Yes. Okay. What's the process for it? Can we just... How do we get... I know. I can just spend the rest of the time talking about GitHub. Can we do it right now? So you can literally do it right now if you wanted to. It starts off as a discussion on your mailing list, just like anything else we're asking you to do. Assuming everyone feels comfortable with doing it, create an infra ticket to switch over. It is a little bit of a hard switch over, so there might be a couple of hours where you don't have right access. But once you have that, it's pretty seamless. Yes? Yes. That is true. So you will lose. That's okay. So understand that we have a lot of work. We have a lot of old URLs to keep up the work. So in our case... Yes. Those will break, but GitHub is very good on... If you're wearing GitHub and you're moving to... No, this is great to conversation because this is part of what I want to see. Podling is talking to one another. It's a little benefiting, so that's how it's going to benefit us. I wish you'd search about the good rule of GitHub and the issues that are benefiting. The full request is good. Yes, definitely. Tal. So the URL seems to me less of a problem than the users in the history. How do you do that? Because you have users on GitHub and Apache member users, and you have the whole database, the tool that migrates and also rewrite the GitHub history. So all your history stays the same. You're just moving where your primary repository is located. But I mean, if you have the same user and you have commits from before, and now you're committing with a new user, say the GitHub user, all that history still has... It's not a huge problem, but it's... There's a lot of set up steps that you do where you connect your GitHub user to your GitHub user, and those commits map one by one. And it's your history still. All your commits are still yours. There's both ways. We went from GitHub to the way they said, yeah, and all that stuff. But it wasn't actually write those commits. No, no, no, it's just a sign of identity. So the trick was, at least for Cordova, and Cordova is a bearer. So if I go to GitHub, and I see my commits, I will see my face, my profile GitHub in there. The trick is, you need to go to your Apache ID profile, and there's a box that says, whilst you're GitHub ID, and that's the connection between your Google, Apache ID, and also GitHub ID, right? And you have to go to that Apache ID, connect with us. And then the UI and GitHub would know like, oh, this ID is this guy, this profile, and we know who it is. So it's kind of a UI trickery that knows that both of those. Yeah, like I have four or five email addresses in my own GitHub account. So I've had to deal with that quite a bit. Yes. One last question. So what about getting all the Jira stuff migrated back? So that I don't believe. Yeah, I don't think that that is currently a support of migration. You would have to do an export and then an import. And I'm not sure that there's a direct import utility. I know that there were a couple of projects. The names, I'm sorry to the day, but I forgot the rest of it. They actually did an export from their preexisting Jira and imported into us. It took like 10 or 15 tries to get it right. But we were able to create a temporary project, do the test import, confirm everything was working, and then do a final import into Jira. Going out, GitHub issues aren't a huge thing for me. Okay. So now that we've had the fun GitHub discussion, let's keep going on IP issues. So in most cases, especially when it's coming from an internal develop project, you're going to have a software grant. And your software grant should be from your existing company or the existing author saying, I am granting the Apache Software Foundation the ability to use this software under the Apache license. And that software grant is meant to avoid patent issues, avoid naming issues. We're expecting as part of that grant, you're actually giving full, basically full openness of your source code and allowing it to be used by the foundation. You are not actually donating that software to the foundation. The existing authors can still claim their rights. That's actually one of the things built into the notice file that goes into your project. If you are an existing committer as a third party, you might want to list your name out in the notice file saying that prior to 2015, this was developed at Comcast or Gigaspaces. And that is okay because that software is actually developed by you internally. We want to carry forward those names as much as possible to be able to give you continued credit. Once you start developing at Apache, it is assumed that you as an individual are making that contribution. You are not making that contribution on behalf of your employer anymore. So you have to make sure that you have access to do that. I know in my company we deal with a pretty long employer covenants agreement that goes over everything that is owned by the company and everything that is not owned by the company. You should look for things like that within your own organizations to make sure that you have either signed off on it, you have listed it, or the company is saying that it is okay to do this at Apache. If you are an existing software project, you might not need a grant. If you are existing Apache licensed, if you are existing MIT or BSD and leaving that software the same, you might not have to transfer the license. As far as we are concerned, these are just software dependencies that are appropriately licensed. Category A is we like to call it. If you are outside of that small realm, Category B like EPL, CDDL where we can bring in binary dependencies, that is going to be an issue and we would expect there to be some form of grant to change that license structure. Really the grant is when you want to change the licensing of your existing source code. If you don't have access to the original author, let's say it was developed out on GitHub by some individual and they may have abandoned the project, you want to bring in that source code, you can't do that without doing a grant if it is not existing Apache licensed. You can bring it in and ideally not modify it and that will not be an issue. You just have to be very careful about headers that you add to the software. You don't want to inappropriately add Apache V2 headers to an MIT licensed project because that will lead to a lot of problems. We also want to make sure that the original author in those cases is called out correctly. If it is MIT licensed, make sure that the MIT license includes their copyright statement. If it is BSD licensed, you actually don't use the BSD license directly. Everyone who is using a BSD license is using a derivative of the BSD license with a number of placeholders replaced. You want to make sure that you are bringing in their copy of the BSD into your license file to correctly call it out. We want to keep the source code as clean as possible. So wherever possible, try to avoid bringing in other projects and instead come up with ways that you might be able to depend on them from a binary standpoint. If you get to a situation where you need to start modifying it, consult with the legal team and post on legal disgust to see what their recommendation is. In most cases it is going to be that's fine, but at least we have an audit trail now email to be able to say this project was okay to do this. Yes, sir. So I'm assuming that's what you guys were just asking about. Go is a very interesting one because it's a newer language and we haven't spent a lot of time analyzing it. I think as long as everything in go is the same license, it may work out for you, but it looks like it's a very heavy thing. It's almost like it's npm again. If there's some way that you don't have to bring in the source code and instead there's some equivalent of package JSON that brings in your dependencies during the build, that seems like a more appropriate thing to do. I don't know a lot about go, but from what I understand there's a go get. I would expect that as part of your build for any go base software you're running a go get to bring in that software. Yeah, I agree. You just have to watch out what you do including your license file because you don't want to have a bloated license file when you do cut a release. Justin's going to talk about that in a little bit, but ideally your license file should only represent what is in the source package. Your binary license file may be different and could be completely different. Is there another question? Or no? Yeah. Yes, we would expect that the import to the Apache repositories includes the re-licensing. There are certain cases where that may not have happened as long as we have an SGA on file and by the time you leave the incubator all of your license headers are correct, that's generally a good thing. That's generally true of any organization you're in, any open source project you're dealing with. You don't change someone else's license header, even if it's wrong because they're the ones who apply that license header. It's not your source code. The other case that you might have instead of doing a software grant is to do an IP clearance. IP clearances are more about donations to existing projects, but may actually be a better solution for an existing open source project. What we do is we review what the source code is out on an existing repository. In most cases, it's going to be a GitHub repository. Review it for any licensing problems. Open a 72-hour vote thread to see if anyone has any objections to bring it in and then actually bring in that source code. In a lot of cases, if you are an existing open source project, this might be the correct solution for you. You might want to check with your mentors and see which they would recommend, especially if there is no existing vendor behind it. Always credit the original author. If you are bringing in source code that wasn't developed by you specifically and was developed by someone else, the existing open source project, how many projects in here are dependent on Bootstrap for a website or some sort of UI component? You wouldn't actually, because of the way Bootstrap works, you typically have to bring in their CSS files and are making some changes to them. You need to make sure you're calling that out in your license and notice file. Well, no, your license file because it's most of it's MIT. We prefer transit of dependencies wherever possible. So if you are doing things like Go or NPM, we want to see package JSON or Godeps, you're listing that out. Yes. If you don't have to actually bring in the Bootstrap CSS into your repository, there's no reason to call it out in your license for the source license. If you start modifying the existing Bootstrap CSS, then you do have to include it. Likewise, if you have a binary output of your project that includes the Bootstrap CSS, you need to call that out in your license file. Is it checked into your repository and part of your source release? Okay. So if you are not including the file in a release, then it does not get listed in your license. If you include it in a binary release or somehow otherwise package it, repackage it, you do have to call it out in your binary release. Your source release, your binary release, this should be very specific about those contents. So wherever possible, we want to use transit of dependencies. This is what he's describing is a little bit of a hack, but it works because you're not actually using that source, that software directly in your project. So you've gotten everything into Apache. You're operating on your existing project. We want to see you start to build a community. So once your software is in and you can start working with it in our repositories on our mailing list, you can now start building that community out. Wherever possible, we want to avoid the loudest voice in the room. That happens in a lot of places and a lot of different opinions, but sometimes when you're dealing in corporate environments, the person speaking the loudest or talking the most is the one who wins. Email helps avoid that. It also helps avoid anyone feeling left out or not even knowing that a decision was made. So while I know a lot of people are using Slack or HipChat or other synchronous communication mechanisms, we want to see as much as possible communication happening on mailing lists. We want to see decisions happening on mailing lists so that everyone is aware of it. It is the biggest struggle for podlings, especially when everyone is co-located in a single office where everyone is working in a same time zone. It's very hard to switch from I'm walking up to your desk to ask you a question or I'm actually sitting next to you and we're working on this together to, hey, I just sent you an email about this. Can you respond? Very different mindsets and sometimes doesn't work in corporate mentalities. I know for my day job, we actually do paired programming a lot. I don't see my email after about 9.30 in the morning. So it gets very hard to respond to emails if I am pairing with someone. That's still good. As long as you are communicating it and it's mirroring back to our mailing lists, that will solve that issue. If you are more comfortable talking on a GitHub pull request or on a Jira issue tracker or even a GitHub issue or a Bugzilla issue, as long as we have some way to be able to go back and say this is what happened, if someone is not even listening to that Jira ticket, the fact that the Jira tickets are all getting mirrored back to your email is what makes that work. And everyone is going to have different opinions about how they want to operate. As long as that is clear to any new contributor that this is how they are expected to operate, it's okay. We don't want to tell you that you have to directly write every single email. We want to be able to say, okay, it's fine that you have Jira and we are mirroring all the Jira issue communication back. Or if you have a GitHub issue, it's going back to your GitHub issues mailing list. As much as that is possible, different ways to communicate. But all welcome. So that's the critical piece. You want to make sure it's consistent so that if I were walking in as a new contributor, I immediately know how to gain access to start talking to you guys. Do I raise an issue? Do I send an email out saying, hey, what do you think about this feature? That's what you want to make sure is clear to everyone who's participating. So your dependencies are only going to become a problem when you start to get into a binary release typically. Your source release should just be an exact mirror of what's existing in your GitHub repo minus a couple of things that may have been excluded. I know a lot of newer projects, especially in the JVM world, have been using Gradle. Unfortunately, we cannot support the Gradle wrapper jar file in a source release because it is a binary file. There are other cases like that where we simply can't include binaries in the source release. That's the whole point to it being a source release. There are certain things that we do include like images where we're expecting, guess this is an image and it's not a virus. In fact, the last VP legal mentioned they're worried because they think it might be a virus in a jar file. That's fine, but that's something that we do have to look out for in a release. Your transit dependency should not bring in anything that to an end consumer is either not obvious. So if you're using Hibernate and you are a standalone application, that would not be obvious. If you were a library that happened to bring in Hibernate as an optional integration, that is actually an acceptable thing to do under the LGPL because you're not directly modifying anything about Hibernate, you're instead just bringing it in as a dependency. Similarly for CDEL, you can depend on CDEL license software even as binary dependency because you're not modifying anything about it, you're simply leveraging it from an API standpoint. So that's stuff you have to be very careful about and make sure that it's either obvious to your consumer that it's supposed to be there or directly called out as being something that is going to be used as part of your software. If you are something that is completely standalone, a standalone server, don't try to avoid a lot of those dependencies. We have a full list of existing resolved licenses that you should be reviewing on the legal pages. If you don't see a license for what it is you're using, ask before you bring it in. We will generally be accepting new licenses. There's been some discussion about whether we require OSI approval or if we're okay approving it ourselves. Just don't assume that your license will be accepted. There may be certain clauses in that license that make it not usable to third parties that might be working with your software. So how do we get a release out the door? There's a bunch of things behind it. Justin's going to be talking a little bit about it, but I do want to cover some very high level things, especially what we consider to be good practice in the incubator. Do frequent releases. Don't wait until you have all your features said done to do your first release. That makes a very difficult thing to do. We want to see small releases that may not actually have business value because really what we're after in the incubator is to see, do you understand the mechanics and all the licensing that goes into that release? We're less worried about the feature set and more worried about the technical mechanics behind it. So the more often that you can do a release, the cleaner your releases get, release after release, the better off you'll be. If you have started a release vote and you've gotten a questioning response, try to understand whether that's something that can be cleared up in a following release or is that something you should be fixing right now. More often than not, the IPMC will say this is a problem. We're okay with you fixing it in the next release, but we need you to ask that question. And there are certain cases where it won't be obvious to the person calling the release that is the IPMC member's opinion. Because it is asynchronous, you might not, as either the person sending the email, the person receiving the email, there might be something lost in translation. Every release should get better. What we don't want to see is you had a release problem in your last release, and now you have a continued release problem. You didn't fix this license issue that we said has to be fixed. That is a bad sign and it's not something that we want to see happen. So the more releases you can do, the better each release gets, the better off we'll feel from a project standpoint to say you are getting the Apache way. All of our releases are source-based releases. While there may be binary releases that go in tandem to your source release, all of our releases from a licensing standpoint are meant to be source code releases. We expect tar GZs with signed files next to them indicating what this release is. We allow you to publish convenience binaries. For a while, the incubator actually did not allow pod links to produce binaries. You could only produce source code. We do allow you to mirror to Maven Central. We have the infrastructure behind Maven Central as well that we can help synchronize you. We do allow you to publish to other binary repositories like PyPy and whatever else might be out there. I'm assuming Go has a similar one or maybe they're just pointing to GitHub to bring in their source code. The other critical thing is how do you name your release? This is a very confusing part for a lot of projects. What we are expecting is that your source distribution includes the word incubating in it. We do not expect that your version number includes the word incubating in it. A lot of projects have done that for convenience, but at the end of the day what we're really expecting is that you have something including Apache, poddling, version incubating in your source distribution. That is only your source distribution. We don't have any restrictions on what goes into your binary distribution. In a lot of cases, your binary distribution may be something that has to be driven from what the consuming parties are looking for. If you have a binary distribution that has to go out there, I think PyPy has certain formats that they're expecting, if you need to do that, that is what is needed to get this published into that binary format. Other than making sure that the naming makes a lot of sense, like if you are my new and you publish into PyPy called runtime new instead, that would be a problem for us from a branding standpoint. However, from the source release standpoint, we are expecting you to call yourself Apache, poddling name, version number, incubating, to be able to get your source released through. There is none yet. It is a problem that we have to start talking about. I suspect that that problem will not be an incubator-specific problem. We're going to have to be very careful about what we do. I think from a foundation standpoint, we're going to have to answer that question, because we do have TLPs who are doing it today. I think CouchDV was the very first one to go to GitHub as their primary. They haven't done a release yet, but I suspect that we'll have to come up with an answer about what that release is supposed to look like. I did just give some input to MXNet on what they should do to avoid some naming issues, because we don't want to include free releases out on GitHub. If you do call for a vote on something, we want to make sure that that doesn't automatically create a release for you, which GitHub's behavior is as soon as you tag something, that's a release. People get a little bit worried about it. I talked about what goes into it. It's your source code and don't include any binary source code. No jar files. Images are okay. Don't depend on executables. Don't depend on existing TARGV files that might be in your source code. Try to strip all that out or come up with a build structure that doesn't require it. That's about it. That's really what I want to talk about. Justin will be in here in a few minutes to talk about the actual mechanics behind creating these releases. It is a very hands-on session that he's doing, where he's going to be going through some existing stuff that he's done on something called Apache Wombat. Apache Wombat doesn't exist, but it's a project he came up with to be able to demonstrate how to cut a really good release at Apache and get yourself out of any problems that may be popping up. I know we took a lot of questions during this, are there any other questions that I could answer for you? I saw you first. You mentioned before the focus on email, and I know for our poddling, Haria and Pasta, that we are moved to that because we use Slack a lot. We're very active and we have constant discussions there. Are we the only ones using Slack? No. So a lot of projects use Slack today. What I personally would like to see is more projects move to the Apache branded Slack instance, the-asf.slack.com. We do have that out there. We are also working on ways to be able to mirror that information back. Unfortunately, the test that we ran last night so far hasn't been successful. It's meant to be like a daily digest of all of the email that's gone back and forth with Slack, or sorry, all the messages. So we just got the free version, we'd be happy to move. Yeah, I mean we have the free version as well. It's more of- Yeah, it is a 10k limit. Anything else you're going to- Yes. Go on, figure the decision and the summary back in the- That's the most important part about this. We want to make sure that the discussions, the decisions that are happening, are making it back to the general public. However, to make that happen, just make that happen. The Slack is considered offline. The Slack is considered offline synchronous communication. What we're looking for is asynchronous email-based communication. Yes. Carlos. For a release, the incubation, this isn't just really a mentality changing, but the incubation, the IPC, the incubation product is a PLP. So when I do a release, I'm not doing it myself. You guys are doing it on my behalf. So that means that this is an official Apache software release backed up by Apache, meaning that anyone can report a CVE security issue and we are responsible to be fun and fix it and report that release. Yes. Just because it's a following doesn't make you say- Yeah, we're about- We've been released, right? There's some security and critical marks. That's where I spent more of my time in Cordova. So that's maybe the reason I'm holding up on releases is not the mechanics, but when I do a release, I want to make sure that I have the bandwidth very important to fix the CVE right away. Yeah. We're about to go through the CVE process or something, kind of an art pot, playing through that whole process, and we had one other security issue. We kind of didn't do it the right way and we kind of went and slapped for it. And so we're going to do it better next time we email our security list and we're giving people time to mitigate, and then we're going to report the CVE process once everybody has submitted the issue. Yeah. And that's kind of a black magic one, Jordan. I get people from probably the other CVE, I think that they actually would guide you, right? So we actually are taking more of a hands-off approach when it comes to a lot of that, and we are delegating most of that work to the security team at Apache to follow up directly with the podling. The expectation is that they're escalating to the IPMC when the podling doesn't answer. So then you'll get slapped twice, but ideally you're just getting slapped only by the security team. Yeah. Yeah. Or if you have a security list. Yeah. We send the badge to the security. The whole phone probably. Yep. So VRWare, when you do release, it's not just sipping something, putting it out there and kind of... Exactly. Yeah. Yeah. Yep. When you're at PLP, you'll be out by yourself, so you'll be, you know, dealing by yourself with different things. Absolutely. All right. Well, thank you, everyone. Hope you got what you were looking for out of this.