Howto revive inactive projects ?

Hi everyone,

Moving this from the private list to general (this is actually a spin of from a thread about adding
a committer to an inactive project, hence that it was on private).

Definition list :

Inactive project = a project that has no *developer* community.

The Apache Way :

To become committer on a project you have to earn that right, you have to stand out, submit patches,
show you care, learn the apache way and have to get noticed by the current committers who can
nominate such a person.

Problem :

If that didn't happen enough in the past, it can happen that at a certain point no developer
community is active anymore.

Which causes :

A catch22 situation. Since there is no developer community, no one is able to determine if people
deserve to become a committer. Even if you are monitoring such a list (such as I do for all Jakarta
lists), it is hard to determine if people deserve committership.

Solution :

I don't have one specifically :)
Part of the solution is always that a project needs a kind of mentor that is willing to invest time
in a project, teach the Apache way, etc..

Let's come up with a way to get around the catch22 scenario..

Mvgr,
Martin

Re: Howto revive inactive projects ?

Hi, Martin, and Everyone,

If someone is interested in taking over a truly inactive project,
maybe they should fork and start their own SVN repository from their
own domain. The person should make it clear that their fork is in no
way sanctioned by Apache.

The only responsibility Apache might have in this situation, if so
inclined, is to include a link from "[inactive-project].apache.org" to
the fork, with some warnings that Apache's higher standards with
respect to intellectual property are not in effect if you follow the
link.

If the fork proves popular, and the person wants to bring it back into
the family, the person could write an email to Jakarta-General asking
to be nominated, become a committer, and then merge the fork back in.

I'm assuming that a reactivated project with only one committer is
still better than an inactive one with none I'm also assuming that
the majority of "inactive" projects are smaller ones which probably
only had one main committer / benevolent-dictator in the first place:

http://blog.generationjava.com/roller/bayard/entry/enterpris e_communities_episode_2

Commons is a very interesting case study here. Here's a pretty obvious
white elephant - nearly every Commons component is running under the
dictator model. You can point to any component and as long as it's
active, it's "So and so's" baby.

Re: Howto revive inactive projects ?

Hi Julies,

Julius Davies wrote:
> Hi, Martin, and Everyone,
>
> If someone is interested in taking over a truly inactive project,
> maybe they should fork and start their own SVN repository from their
> own domain. The person should make it clear that their fork is in no
> way sanctioned by Apache.

That's a requirement, since it cannot be called the same as the Apache project name.

>
> The only responsibility Apache might have in this situation, if so
> inclined, is to include a link from "[inactive-project].apache.org" to
> the fork, with some warnings that Apache's higher standards with
> respect to intellectual property are not in effect if you follow the
> link.

Don't agree here. Our current code base is our responsibility, even though there are no active
developers. Better information on the project status could be useful however.

>
> If the fork proves popular, and the person wants to bring it back into
> the family, the person could write an email to Jakarta-General asking
> to be nominated, become a committer, and then merge the fork back in.

They will have to come through the incubator to come back to us, because of legal issues. The
problem most of the time that there isn't even someone asking to take over.. A fork may also not use
our project name. So I prefer to get momentum back here :)

>
> I'm assuming that a reactivated project with only one committer is
> still better than an inactive one with none I'm also assuming that
> the majority of "inactive" projects are smaller ones which probably
> only had one main committer / benevolent-dictator in the first place:
>
> http://blog.generationjava.com/roller/bayard/entry/enterpris e_communities_episode_2
>
>
>

> Commons is a very interesting case study here. Here's a pretty obvious
> white elephant - nearly every Commons component is running under the
> dictator model. You can point to any component and as long as it's
> active, it's "So and so's" baby.
>

Re: Howto revive inactive projects ?

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.

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!).

(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.

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.


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".

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!

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?

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.

#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."

(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.



--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

Re: Howto revive inactive projects ?

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-templa te.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

Re: Howto revive inactive projects ?

Hi Julius,

> If someone is interested in taking over a truly inactive project,
> maybe they should fork and start their own SVN repository from their
> own domain. The person should make it clear that their fork is in no
> way sanctioned by Apache.

That would be OK for projects that are, as you call it, "truly inactive".
Meaning: no developers and no users. But I believe our main concern is
with projects where the developers have moved on, but a user community
is left. Forking this kind of project is disadvantages in various ways:

- The developer not only has to learn the new code base, but must also
build a new user community either from scratch or by winning over
the users of the Apache code base. That means a lot more work for
the developer candidate, and makes a successful revival less likely.

- The users are left with a choice between the inactive Apache project
and the live fork. Re-integration of the fork is a possibility but
can not be guaranteed. Meanwhile, users of the forked codebase are
missing the legal protection provided by the Apache foundation. And
potential new users of either codebase face uncertainty.

I believe that Jakarta projects with an active user base should be
revived within Jakarta. I thought a while about some kind of second
class committer status, but found more reasons against than for the
idea. Here is my take on a revival procedure...

Preconditions:
- A mentor with committer/admin access to both the software repository
and the bug tracking system. One that is willing to invest significant
time and not just give a useful tip once or twice a week.
- A CLA on file from the revival candidate. ("resurrector")

Procedure:
- Create a "revival" fork of the code base in the software repository.
- The resurrector submits patches for the revival fork in the bug
tracking system.
- The mentor reviews patches for style only, not for functionality.
- Patches are committed by the mentor to the revival fork.
- The mentor is responsible for running tools with committers-only
access, such as Clover. The mentor encourages the writing of test
cases by the resurrector.
- All discussions take place on the regular mailing list(s) of the
project, so that users are aware of the revival attempt.
- Adventurous users are encouraged to try out the revival branch.
They'll probably have to compile themselves, or use a manually
created snapshot as the nightlies would still be based on the
main trunk rather than the revival branch.
- If there is a significant number of fixes in the revival branch
and code quality is considered good enough by the mentor (for
example based on Clover test coverage results), a "Possible
REvival alpha release" (PRE-alpha) is created.
- Publication of the not-quite-release is done on a low profile,
as it is not a full quality release of an Apache project. For
example, due to the lack of a developer community, there won't
be three binding votes as required for a real release.
- Adventurous users are encouraged to try out the PRE-alpha.
- If the PRE-alpha exhibits major quality problems, continue with
bug fixes and improved test coverage. Repeat PRE-alpha procedure.
The decision about the quality is at the discretion of the mentor.
- Once a PRE-alpha release meets quality standards, the mentor
calls for a Jakarta-wide vote to promote the resurrector to
committer status.
- The first task of the new committer is to merge the revival
branch into the main trunk.

Or something along that line. Multiple mentors would be better
than one, but who believes in that many volunteers? A mentor is
of course free to ask for help, in particular on major decisions
such as whether a PRE-alpha is good enough or not.

cheers,
Roland

Re: Howto revive inactive projects ?

On 2/14/07, Roland Weber wrote:
> Here is my take on a revival procedure...
>

Pre-precondition.

We need to define what is inactive and place it in such a state.
Dormant seems a favourite word.
In the recent board report for the Commons components, we've gone with
"Inactive" to mean that there is no coding and no one is watching over
it; and "maintenance" to mean that there is no coding, but someone is
watching over it. Something that is "inactive" is up for being made
"dormant".

So we need to define Jakarta components in this way and challenge each
inactive component to explain why it is not suitable for dormancy. I
think we need to do this even if there is an active user community -
being told that Xxx is now being considered inactive might kick people
into being active.

So first - let's get the components defined in these ways and reflect
this on the website(s).

There's been a suggestion on general@incubator that dormant projects
should be moved into the Incubator.

The following becomes a process for reactivating:

> Preconditions:
> - A mentor with committer/admin access to both the software repository
> and the bug tracking system. One that is willing to invest significant
> time and not just give a useful tip once or twice a week.

+1.

> - A CLA on file from the revival candidate. ("resurrector")

The mentor should guide them through a few patches to show they are
committed, then we can make them a committer. I don't think there's
any reason to do CLAs without also making them committers.

I'm not sure we need to define a 'resurrector'. Rather we should
define the project as being revived and explain that that means that
Person X is mentoring it and that N people are submitting patches to
get it moving along. Often when one person gets active on a component,
others start to show up. Having a resurrector limits the new
contributions.

We could have a wiki page that lists dormant components and people
could put their names down (emails?) as interested in reviving a
component.

> Procedure:

Step 1 - announce to all that the dormant component is being revived.

> - Create a "revival" fork of the code base in the software repository.

Probably a good idea. I'd have immediately said to tag a "prerevival"
tag and then go for it in trunk, but that is a pain when the move
fails and someone else tries to do the same later.

> - The resurrector submits patches for the revival fork in the bug
> tracking system.

+1

> - The mentor reviews patches for style only, not for functionality.

Why not functionality? To keep the time required for the mentor low?

> - Patches are committed by the mentor to the revival fork.

+1

> - The mentor is responsible for running tools with committers-only
> access, such as Clover. The mentor encourages the writing of test
> cases by the resurrector.

I think this is pretty unnecessary in the process. Clover's the only
example and I don't think it's as used now as it used to be.
Cobertura/Emma/JCoverage seem to have done enough to stop it becoming
predominant.

However - the mentor refuses to commit without a test patch would be
something I'd expect to see.

> - All discussions take place on the regular mailing list(s) of the
> project, so that users are aware of the revival attempt.

+1, though a lot tends to take place in JIRA/Bugzilla. The mentor
should be encouraging the people contributing patches to prepare
release plans and communicate them to the mailing list.

> - Adventurous users are encouraged to try out the revival branch.
> They'll probably have to compile themselves, or use a manually
> created snapshot as the nightlies would still be based on the
> main trunk rather than the revival branch.

We could be doing the revival branch in the nightlies too.

> - If there is a significant number of fixes in the revival branch
> and code quality is considered good enough by the mentor (for
> example based on Clover test coverage results), a "Possible
> REvival alpha release" (PRE-alpha) is created.
> - Publication of the not-quite-release is done on a low profile,
> as it is not a full quality release of an Apache project. For
> example, due to the lack of a developer community, there won't
> be three binding votes as required for a real release.

-1. That's nothing more than saying "We think the nightly is pretty
good now" on a mailing list.

Do an actual alpha release. The vote should be held here if there's
not enough voting on the components list.

> - Adventurous users are encouraged to try out the PRE-alpha.
> - If the PRE-alpha exhibits major quality problems, continue with
> bug fixes and improved test coverage. Repeat PRE-alpha procedure.
> The decision about the quality is at the discretion of the mentor.
> - Once a PRE-alpha release meets quality standards, the mentor
> calls for a Jakarta-wide vote to promote the resurrector to
> committer status.

Make them a committer based on their patches. The only problem with
this now is that we don't tend to pay enough attention to people
making the patches and voting on them.

> - The first task of the new committer is to merge the revival
> branch into the main trunk.

I forgot about the revivial branch. Bit worrying having any kind of
release that is from the branch; I'd like to see this merging happen
prior to discussions of an alpha release.

> Or something along that line. Multiple mentors would be better
> than one, but who believes in that many volunteers? A mentor is
> of course free to ask for help, in particular on major decisions
> such as whether a PRE-alpha is good enough or not.

If only we could find multiple mentors :)

Good ideas. We've done variants of this in a few places:

BCEL - Dave Brosius joined. Torsten and I (and Conor from Ant I think)
mentored and he got things moving. Torsten's more involved now, it's
not moving anywhere fast though (I think... I've not looked for a
while).

BSF - Self-started. Old committers got around enough to push things on
and get the new committers in. Other Jakarta committers have helped
them with the 'how to' of things, though it took too long for that to
start up (I think).

Commons - We tried to do this with the compress component in the
sandbox, but it's not gone anywhere (we did add a committer). We tried
to do it with CLI, but the contributor didn't respond to the "we've
voted you as a committer" emails. Email is currently moving along
nicely with a contributor and a mentor. Modeler got released this way
- but the contributor was Dims.

Hen

Hen

Re: Howto revive inactive projects ?

After reading the followups, -1 to my original idea! :-)

One funny thought:
I love having inactive jars in my classpath. It's the active jars
that give me all the headaches!

--
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

Re: Howto revive inactive projects ?

Hi Henri,

>> - A CLA on file from the revival candidate. ("resurrector")
>
> The mentor should guide them through a few patches to show they are
> committed, then we can make them a committer. I don't think there's
> any reason to do CLAs without also making them committers.
>
> I'm not sure we need to define a 'resurrector'. Rather we should
> define the project as being revived and explain that that means that
> Person X is mentoring it and that N people are submitting patches to
> get it moving along. Often when one person gets active on a component,
> others start to show up. Having a resurrector limits the new
> contributions.

Ok, that's a scenario I didn't consider. I didn't mean to limit
the procedure to "one resurrector only". The idea was to say:
Ok, your patches will go in without much of a discussion.

>> - The mentor reviews patches for style only, not for functionality.
>
> Why not functionality? To keep the time required for the mentor low?

I'm assuming that there is nobody around who knows the code base
well enough to tell what implications a change might have.

> However - the mentor refuses to commit without a test patch would be
> something I'd expect to see.

Hmm, you're putting the hurdly high right from the start :-)
I thought of it as "hey, here's your playground, but you'll
need to get down to business if you want to see that code
go into the trunk".

>> - All discussions take place on the regular mailing list(s) of the
>> project, so that users are aware of the revival attempt.
>
> +1, though a lot tends to take place in JIRA/Bugzilla. The mentor
> should be encouraging the people contributing patches to prepare
> release plans and communicate them to the mailing list.

No objections. This was meant as "we're doing it within Jakarta,
not anywhere off-site".

> We could be doing the revival branch in the nightlies too.

If it can be done, good.

>> - If there is a significant number of fixes in the revival branch
>> and code quality is considered good enough by the mentor (for
>> example based on Clover test coverage results), a "Possible
>> REvival alpha release" (PRE-alpha) is created.
>> - Publication of the not-quite-release is done on a low profile,
>> as it is not a full quality release of an Apache project. For
>> example, due to the lack of a developer community, there won't
>> be three binding votes as required for a real release.
>
> -1. That's nothing more than saying "We think the nightly is pretty
> good now" on a mailing list.
>
> Do an actual alpha release. The vote should be held here if there's
> not enough voting on the components list.

See my "playground" comment above, plus the "style only review".
I would consider the PRE-alpha as saying: We've got something
that is significantly different from the last release, but we
don't know whether it's working. Coding style has been reviewed
by the mentor, but now we need some user feedback on the
functionality to tell us whether this is good enough to build
future releases on.
Voting on general@ can help to overcome the 3-binding-votes
requirement, but it doesn't help code reviews. Of course it
all depends on the quality you expect from an alpha release.
And there's the branch thing. If the release is not good enough
and/or the committer(s) loose(s) interest, that code will not
go into the trunk and future releases, if any, will not be
based on it.

>> - The first task of the new committer is to merge the revival
>> branch into the main trunk.
>
> I forgot about the revivial branch. Bit worrying having any kind of
> release that is from the branch; I'd like to see this merging happen
> prior to discussions of an alpha release.

That's why I suggested the "irregular" PRE-release :-)

cheers,
Roland