You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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 have run into difficulties, some don't built 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 and 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 to see 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 on boarding

Things like organising software grants, setup up repos 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. Because of this your 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. For instance, you now 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 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.

You will need to care about licensing and IP

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

Any major contributor to your code base will need to sign an ICLA. On some GitHub projects, finding all these contributors and getting them to do that may be difficult. If you have a large number of GitHub repositories transferring them all and checking the IP of them all 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 dependancies and 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, it is likely manual effort will be required to get them to work with your release.

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 can not be someone in charge. Everyone involved needs to have an equal say in the direction of the 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 can be challenging.

Your mentors may not vote on your releases

Releases need 3 +1 votes form IPMC members, you mentors (who are IPMC members) may not vote and you need to ask the wider IPMC for 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 teh 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

It may be hard to get new mentor late in a project if they go missing.

You may not understand the Apache Way

The Apache Way is mysterious, and means different things to different people. Some people think it cannot be documented but just is.

You will need to comply will ASF policy at some point

Your project will need to comply with ASF policy before graduating. Putting off doing 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.

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

  • No labels