DRAFT DRAFT DRAFT

Why incubating at the ASF may not be for your project

The majority of ASF projects go through incubation and become top level project without any trouble. A few projects have run into difficulties, some don't build a community around them and decide to retire, and a couple have decided to leave. It's best to find out if you are a good fit before you join the ASF. Carefully consider what changes your project needs to make before starting on your incubator journey. It's a good idea to discuss this in detail with your champion before joining the Apache Incubator. Carefully consider if you are likely to encounter any of the situations listed below.

As an incubating ASF project, you may run into one or more of the following issues.

You may have trouble onboarding

Things like organising software grants, setup up repositories or websites may take longer than you think. Some manual steps may be required.

You may not be able to use the services you previously used

Your choice of CI server or other infrastructure may not be in use at Apache. You may have to change your development workflow.

The ASF documentation needs improvement

Some documentation may be out of date, misleading or confusing. Mentors have different knowledge and experience. Because of this, you may get unclear, or even contradictory answers to questions.

You will need to change the way you build and distribute software

The ASF gives legal protection to people making releases. Because of this, it's very likely to require several changes in how you are currently releasing software. You will need to vote on releases over two 72 hour cycles, including have the IPMC vote on your releases. The IPMC may require fixes to your release, starting this cycle all over again. Your project may need to change the way it publishes software on GitHub, Docker or other 3rd party distribution mechanism. All this may slow your project down.

You may need to change how and where you communicate

Apache projects communicate on mailing lists. There's a lot of good reasons for this. You may be used to communicating on instant messaging platforms or in real-time meetings. Your project may need to change this. All important decisions need to be made on the mailing list.

Your GitHub permissions may be restrictive

Your project will not have admin access to your repo and some things that you could do before may not be possible. Permission to install bots or other GitHub tools are going to be limited, and contributors may have less access than they did.

You will need to care about licensing and IP

Apache takes licensing and IP very seriously, you need to check the license of all files and know where each line of code came from.

Any major contributors to your code base will need to sign an ICLA. On some GitHub projects, finding all these contributors and getting them to submit an ICLA may be difficult. If you have a large number of GitHub repositories transferring them all and checking the IP of each one can be a lot of work.

Some open source licenses are not compatible with the terms of the Apache license. This may come as a surprise to your project. Your project may need to remove or replace code or replace some of its dependencies.

If your project has complex licensing or dependencies and/or includes lots of 3rd party code, it might be challenging to assemble the license and notice files. This is hard to automate, and while we have tools that may help, manual effort will likely be required to create these files.

You will need to care about trademarks and branding

The project will need to look out for how others are using its name. Some existing websites and 3rd party repositories may need to change names. This may be difficult if you are not in control of them.

No dictators (benevolent or not) or corporate overlords

For consensus-driven development to work, there cannot be someone in charge. Everyone involved needs to have an equal say in the direction of the project. No dictators or corporate overlords are allowed in an Apache project.

The ASF may feel bureaucratic to you

The ASF has a lot of policy and traditions. Some of these are not written down. If your project comes from a place with little or no policy, this may be challenging to adapt to.

Your mentors may not vote on your releases

Releases need 3 +1 votes from IPMC members, your mentors (who are IPMC members) may not vote and you need to ask the IPMC for extra votes. This may slow down your releases.

Your mentors may go missing

Mentors are volunteers and may not be able to help all of the time. Occasional they may go missing, sometimes they may not come back. You can ask for more mentors or the IPMC to help but people available to help and the time they can give may be in short supply. You may have to work out things on your own.

It may be hard to replace missing mentors

If a mentor goes missing, it may be hard to get a new mentor late in a project life cycle.

You may not understand the Apache Way

The Apache Way is mysterious and means different things to different people. Some people think it can't be documented but just is. People experienced with the Apache Way may have different opinions on what it means and how it should be applied in a particular situation.

You will need to comply will ASF policy at some point

Your project will need to comply with ASF policy before graduating, putting this off to just before graduation may not be the best plan and cause delays in your project graduating. If your project has spent a long time in incubation, your mentors may no longer be around to help you graduate.

If during incubation you run into any of these issues, ask your mentors or on general@incubator for help.