| RE: [technology-pmc] Nexus project |
|
It's true that there is a lot of overhead to being an
Eclipse project.
I don't agree with that
assessment. The only thing I can think of that Eclipse projects have as overhead
that is in addition to the usual overhead of running any project is the IP
process and even there the IP team has been working hard to make that as low
overhead as possible. Things like builds and plans - every successful project,
no matter how large or small, needs to do those things so they are not "overhead
of being an *Eclipse* project" but rather "overhead of being a software
development project".
Don't get me wrong, I'm all for (and am working on) reducing the overhead of being a software project (such as through the common build infrastructure), but I just don't agree that there is a "a lot of overhead" to being an Eclipse project. [kosta] I think you are reading too much into that statement.
IP process is just one aspect and as you say the IP team has been making a
lot of improvements. It doesn't matter how you categorize or attribute the
rest of the overhead. Overhead is still overhead. Committers just want
to write code, take a moment to plan releases and interract with the
community. Everything else is overhead. Let's take the total overhead
expenditure in hours for the first year of project's existence. My belief is
that this startup overhead stays the same regardless of the size of the project.
So it becomes a question of what percentage of committer time is going to be
eaten up by the overhead over the first year. If the project is large, the
percentage may be something like 5% of all committer hours contributed. On the
other hand, the overhead for small projects can get as high as 30% to 40%
the first year. It is my firm belief that this right there is one of the primary
reasons why we don't see more small projects at Eclipse.
Progress is definitely being made at lowering the overhead and I am
thrilled to see that we are going to have a common build infrastructure, but
more work still needs to be done. I want to work towards a push-button system
for project creation and provisioning. I can see a "Create Project" link on the
Technology Project's home page where people can go with an idea for a project.
The link would take them to a form that they fill out that becomes the project
proposal. They hit submit and an e-mail is generated to the PMC. The PMC asks
questions, makes suggestions and eventually gives a thumb's up by going to the
portal and approving the proposal. An e-mail is generated to the Architecture
Council asking for mentors. What do we do if no one volunteers? Can Technology
PMC step in at that point to fill that function? Once mentors are found and
recorded in the portal, an e-mail is generated to EMO to start provisioning
everything including CC machine, download pages, build system, etc. When the
provisioning process completes, an e-mail is generated to new committers
informing them that the project has been provisioned and they can start coding.
When they have created a few plugins and some features, they can refer back to
the original e-mail that tells them where in the portal to go to so that they
can specify their root features. Once they do that, the CC machine kicks into
action and the project is producing builds for community to consume. We will not
get there right away, but that is where I think we should
aim.
Without something like Nexus,
the proposed micro projects would be required to find a more permanent home as
they reach a state of maturity.
Wouldn't it just make sense that projects that are successful and adopted
by the community to naturally have an obvious home? So I don't see this as a
problem.
[kosta] I am not seeing logic in that statement. Just because a
project is successful does not imply that there is a bucket to put it into. We
don't really have a good place to put projects and frameworks that are shared
code rather than end-user functionality. See the list of soon-to-be
project proposals that I listed in another e-mail for examples. Now, perhaps the
implication is that they could be put into the Tools Project as a general
catch-all. Perhaps that will work, but it's not entirely obvious to me that
it will or that is necessarily the best solution. Fortunately we don't have
to come up with a solution quite yet. I happen to be in agreement that such
projects could incubate at the Technology Project.
Perhaps the Nexus proposal is more about requesting a better explanation of what it means to be a project and how to run a project and so on rather than created yet another mechanism... ? [kosta] Nexus (at least as conceived at the time of last wiki update)
embodies two concepts:
1.
Making it easier for small projects to get started. After discussions with Wayne
and others, I am now in agreement that this function is covered by the
Technology Project's charter and so I agreed to join the Technology PMC to work
at solving that problem here.
2.
Container for projects that represent code-sharing efforts between other
projects at Eclipse that have hard time finding home elsewhere and don't
represent end-user functionality. My current thinking is that such projects
would get created and incubated under Technology and move to Nexus upon
maturity.
- Konstantin |