Hi Julius (learning here :), Thanx for the comprehensive and well thought out mail..
Julius Davies wrote: > Thanks for your reply, Martin! > > To reiterate (hopefully more clearly this time), I see two dilemmas > and two problems: > > Dilemma #1: > ------------------------------ > You can't stop people from forking. Forking is the "lowest barrier" > way for a committer-less community to revive an inactive project. So > should you fight the fork, or roll with the fork? Keep in mind that > forking itself is not an insignificant act! To learn the code, create > new code, setup a new SVN, host a new domain - these are all real > work. So I think a "fork" should be recognized as a sign of > significant community interest in reviving the project. A fork, while > the "lowest barrier", is still not something to be dismissed. Goal is not to stop forking. A lot of code is forked (even I do it, although normally not complete codebases), although I like to prevent forking for the wrong reasons, which in this case means a project that is inactive. > > Dilemma #2 (Martin's dilemma) > ------------------------------ > To keep things in the family (avoiding the fork), you need a > committer. On an inactive project a committer cannot be created > without lowering Apache's standards. Lowering standards, while > problematic in itself, is politically infeasible, since it debases the > status of being a fully fledged "committer". (Some people will not > care about this, but some people will, and I think "@apache.org" email > addresses are an important status symbol in the IT world, and not > worth debasing.) (If I may be bold, I would cry out to you all, > "Don't be ashamed of the status!" You have established an IT > "peerage" of sorts, and it's quite miraculous to see it both community > and meritocracy based!). There are acutually 2 problems : 1 is reviving and 2 prevent projects from being inactive. Both can be achieved without lowering Apache standards I think. > > (The aside that lowering standards "is problematic in itself" points > to other problems that I hope are obvious, and are perhaps as big a > deal as any status issues mentioned above). > > (I wonder if I love parentheses so much because I am a programmer?) > > > Problem #1 > ------------------------------ > Code developed outside Apache will not have Apache's strong guarantee > that the code is not stolen, and is indeed available for use under > ASL. (As someone trying to donate "not-yet-commons-ssl" - let me tell > you - Apache is serious about this stuff!). So it's hard to bring any > forked code back in. It isn't that hard, just legal paperwork and a legal check (see http://incubator.apache.org/ip-clearance/ip-clearance-template.html for more info) You are kind of in a different spot, since you have an original work created by you (/ the company you work for), which depending on where it will end up could require full incubation or just ip clearance. The paperwork as far as Apache goes (for not-yet-commons-ssl) is already in place. As said I will restart the discussion on this when your employer is happy. > > Problem #2 > ------------------------------ > Any solution that requires an existing committer become more busy than > they already are will not work. I find that existing committers are > extremely busy. Imagine a perfect solution where all that is needed > is that an existing committer scratch their nose once. I think such a > solution will fail because committers (and contributors as well) are > already too busy. Ok what you are saying here is that reviving a project is effectively not possible. To notice new committer "material" you have to invest some time, after a vote, you have to mentor them. Now let's assume there is fork. When you want to bring the fork back, we need to do a lot more work than just that, clear ip, vote to get the codebase back in and also do the same as getting a new committer on board. So in the end it will mean twice as much work. > > > My Solution > ------------------------------ > I think it's important to ride the community wave. With inactive > projects, the community has no committer, so I believe they are > essentially forced into a fork in this case. I think Apache should > try to create a procedure that leverages as much of the existing > committer-less community momentum as possible. For inactive projects, > try to become "fork friendly". Or to become more friendly to people who want to get involved.. > > How much external code can the fork generate before it's time to bring > it back into the family? I figure 95% - 99% of the pre-existing code > will remain. A simple diff will make this apparent. Full incubation > is too heavy when you know that 95% of the code is already pure Apache > already! It doesn't matter if the code new is 0.1% or 50%. The amount of work is the same (though if you want to review every change, the 50% thing takes more time of course) > > But Martin has an excellent point here: > > "The problem most of the time that there isn't even someone asking to > take over." > > The "@apache.org" email address is a big carrot. Somehow that can be > used to help solve this problem? If people need the carrot of an apache e-mail address to bring the work here, I actually would be -1 getting that person on board. The drive should be you want to continue development in the Apache community, with a benefit of bigger exposure of your code. > > Solution in a nutshell: > > #1. Apache needs to recognize that a project is inactive. Perhaps > the committer-less community can trigger this recognition by > harrassing the existing mailing list. We definitely need to make clear that a project is inactive (committer wise). > > #2. Once a project is recognized as "inactive", the carrot should be > introduced. Some kind of notice on the old webpages should be > introduced saying "Would you like to revive this project? Please try > "forking", but continue to use the mailing lists. If community > interest in your fork looks promising after 3 or 6 months, please send > an email to jakarta-general and we will consider making you an Apache > committer on this project." I agree with the part of settings up a page on eg the main page of the project, just with different content. Something along the lines : Want to get involved ? - Help users out and subscribe to the dev list - Send patches to bugzilla/jira. - If no response comes, complain on the dev list - If you really think no one is listening, start a thread on general. Above will show that you care and even people not known with the project are able to see what the person in question is trying to do and is able to start a committer vote. People still need mentoring after that (but in every scenario we need some kind of mentoring) > > (Unfortunately #1 and #2 are a bit more work than a nose scratch. > Hopefully I was exaggerating a little.) > > #3. Introduce some kind of "incubation-lite" for situations where 95% > or more of the existing code base is already "certified" Apache. See above, there is an incubation light when appropriate. Mvgr, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
