Project Acceptance Guidelines
Mark
for a bit. We have, however, been hard at work. Today we have posted
the "Project Acceptance and Operations Guidelines", available on the
Foundation website and also uploaded here (http://groups.google.com/
group/codeplex-foundation/web/CPF_Project_Acceptance_and_Operation-
DRAFT.pdf). This document reflects the early planning discussions that
went into the Foundation, current thinking by the Board of Directors,
and a lot of feedback from our Advisory Board. It is still a work in
progress, and by no means final policy.
At this stage we'd like to open the discussion up to broader feedback,
and we look forward to your input. You have asked -- rightly so --
what, concretely, the Foundation will be doing, and how that will
impact open source projects or companies that support them. This
document should give you a more concrete idea of our thinking. Our
hope is that in the near future we will also have the first "guineau
pig" projects affiliated with the Foundation to really test the
process described in this document.
Let us know what you think.
-Mark
Mark Stone // mark....@codeplex.org // 206-839-8521
Deputy Director, Codeplex Foundation // http://codeplex.org
Fabio Maulo
--
Fabio Maulo
Garrett Serack
How would you like the feedback? Edit the word doc with 'track changes',
and upload to the google-group?
G
------------------------------------------------------------------------
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.
John Petersen
Is there going to be a parallel on the structure and governance of CodePlex itself?
< JVP/>
< JVP/>
johnvpetersen.com
twitter.com/johnvpetersen
Rodent of Unusual Size
I don't see any provisions for 'accepting' projects that are already
emplaced somewhere.
For example (my favourite, of course), the Apache Web server. Or SpamAssassin.
Or Eclipse. Or KDE. Et cetera. Perhaps I'm misunderstanding, but it
appears that
the Foundation will benefit only those projects living on the
Foundation's infrastructure.
I'm not saying that's a bad thing, but it _does_ seem a bit limiting.
With the 'facilitating
communication' meme stuck in my head, I could see CF providing bridges between
existing projects and commercial entities *in addition to* direct
sponsorship of project
infrastructure. Helping popular and useful, but commercially-unknown,
projects find
sponsors or gain commercial mindshare is something in which I'd expect CF to be
interested.
Am I 'way off base here?
--
Ken Coar
OSS developer, opinionist, author, and sanagendamgagwedweinini
Rodent of Unusual Size
<fuma...@gmail.com> wrote:
>
> Perhaps I'm misunderstanding, but it appears that
> the Foundation will benefit only those projects living on the
> Foundation's infrastructure.
Or is the infrastructure in question *not* a forge-like thing? I'll re-read
with that as an assumption instead and see what I get. :-)
Mark
@Garrett: While using "track changes" makes it easier to update the
doc, it makes it harder to generate discussion. I'd prefer making the
discussion easier, even if updating the doc is therefore harder. So
please put your comments / suggested edits in a post to the group at
large, and we'll incorporate changes as best we can from that.
@John: Yes, parallel work on Foundation governance is in progress. We
felt, however, that talking about governance for the Foundation in the
absence of a clear understanding of a project process and without at
least some example projects was going to be a pretty futile exercise.
So the focus for the short term is on the project aspects, as that
will greatly influence other decisions.
@Ken: Well, it all depends on what you mean by project. Remember, one
of the explicit goals here is to make it easier, not harder, for
software companies like Microsoft to contribute to existing open
source projects. Let's think about an example. Suppose,
hypothetically, that folks at Microsoft wanted to contribute code to
create an improved database abstraction layer for PHP, that, as a by-
product, made it easier to use SQL Server as the backend for PHP on
Windows applications. There are several "projects" that are impacted
by such work: PHP, obviously; MySQL, potentially; PDO, most likely.
But the actual work that Microsoft devs would be doing is a project in
and of itself. So: that project -- the Microsoft project -- gets
contributed to the Foundation, or worked on as a Foundation project by
Microsoft devs volunteering their time to the Foundation. Then the
Foundation releases the resulting code under an open source license
appropriate to the projects that benefit from the code. In this
example, presumably released under GPL v2 to be compatible with PHP.
This, by the way, is where the Gallery concept can be really helpful.
There could be, in this example, a PHP on Windows gallery, and there
could be a set of gallery-specific requirements (such as code must
release under GPL) that apply to all projects within that gallery. I
hope that clarifies. But I'll reiterate that the goal very much is to
have a project acceptance/operations structure that enables Foundation-
affiliated project work to benefit established open source projects.
Garrett Serack
I apologize for the length of this, it kinda got away from me.
+------------------+
+ General comments +
+------------------+
It feels as if there are three separate (perhaps four) separate concepts
being proposed here:
1. The vision/philosophy the Foundation is employing to drive the design
of the Foundation itself. I'm really glad that this document talks about
some of this, it really helps to distinguish the difference between the CPF
and other open source foundations like Apache, Eclipse or Mozilla. I'd
recommend that this be spun out into a more formal document that continues
to talk about the Foundation in broad terms, as the basis for further work.
2. The creation of a Gallery (process and requirements)
This should be spun out into a specification document that clearly outlines
the process, requirements and forms required to initiate a new Gallery. It
would also be valuable to clearly understand the Foundation's
responsibilities towards the Galleries, specifically the activities of
the Technical Program Manager and the Mentors.
Since all the fruit of the Foundation lies in the projects that Galleries
contain, this needs to be addressed in clear, unambiguous documentation as
soon as possible, so that we can spin up some galleries!
3. The creation or adoption of a project by a Gallery (process & req's)
This too should be spun out into a specification document that clearly
outlines the process, requirements and forms required to bootstrap a
project into a Gallery.
4. (The acceptance of a committer)
Spun out into its own doc too, or just a section in project
process/requirements doc?
I'm concerned in the purpose of Board of Directors' oversight deep into
Galleries and over individual projects. Should this not be left to the
responsibility of the Gallery sponsor? I guess I'm asking why there are
responsibilities being reserved for the BoD, as opposed to trusting the
Gallery sponsor, who has already had to demonstrate strong commitment
to get a Gallery created.
If the powers of the Foundation are concentrated at the top in the BoD, this
will increase the *desire* for a sponsoring company to have a representative
on the BoD, so as to have more 'influence' in the running of the
foundation (and its own sponsored Gallery or projects)
Conversely, if the Foundation would place more trust and responsibilities
with the Gallery Sponsors, there would likely be decreased reason for
companies to seek representation on the Board.
+-----------------+
+ Document Format +
+-----------------+
This document gives a great overview of the whole process of initiating
projects in the Foundation. In the spinning out of the documents into more
formalized specifications, perhaps the Foundation adopt a few 'best-
practices' from the industry around the creation of such specifications.
The IETF has published RFC1543 (http://tools.ietf.org/html/rfc1543)--
"Instructions to RFC Authors" which defines a clear and concise textual
format for RFCs. If the Foundation could adopt/adapt RFC1543 for creating
its own standards and specifications in order that the documents are clear,
consistent and accessible (hint: text files are universal ;D).
FYI: The IETF has a page which talks about their overall process
for creating RFCs at (http://www.ietf.org/about/process-docs.html).
The most significant document referenced there is RFC2026
(http://www.ietf.org/rfc/rfc2026.txt)-"The Internet Standards Process"
And another RFC worth looking at is RFC2119: "Key words for use in
RFCs to Indicate Requirement Levels"
(http://www.ietf.org/rfc/rfc2119.txt)
+-------------------+
+ Specific Comments +
+-------------------+
Page 5 under "Organization Structure"
------
"A Gallery can be run directly by the foundation or sponsored by a 3rd party,
typically a corporation."
Under what conditions would this *not* be a corporation (regardless of
profit/non-profit/charity status)? The only other choices are:
- an individual, and it seems unlikely that the criteria could be
successfully applied to an individual.
- A non-incorporated collection of individuals, (ie, a partnership).
Again, seems unlikely.
Page 5 under "Gallery Creation Checklist"
------
"Gallery Creation Application Form Submitted to Foundation"
Is there a form somewhere?
Page 5 under "Gallery Creation Checklist"
------
"Gallery Manager on board (appointed by sponsor)"
"on board" could be conflated with 'on board of directors' or 'on board
of advisors' Perhaps it should just say "Gallery Manager appointed
by Sponsor"
Page 6 under "Gallery Creation Checklist"
------
"Mentor Assigned from Board of Directors or Advisors" (gallery)
"Project Mentor selected or Technical Program Manager Assigned" (project)
It's unclear, is there a per-gallery mentor, or a per-project mentor?
(there is a similar requirement listed)
Page 6 under "Gallery Creation Checklist"
------
"After 3 years Gallery progress reviewed and board with vote to extend for
another 3 years or move projects "to storage" "
What are the criteria the board will use to guide their decision?
Page 6 under "Gallery Creation Checklist"
------
"A few Galleries will be operated directly by the Foundation Board of
Directors"
What is the process for getting the Foundation board to sponsor a
gallery?
Page 6 "How a Project Joins the Foundation"
------
"How a Project Joins the Foundation"
This whole section seems to skew towards *existing* projects joining a
Gallery in the Foundation. For brand new projects, these requirements
can be a catch-22, in that they need to be met before they can be
accepted, and being accepted may make it easier to meet the
requirements.
Page 7 under "Project Acceptance Checklist"
------
"3 Committers (Signed Contributor License Agreements)"
I can see the reasoning for this, but does this *really* guarantee
project viability? I can easily find an additional one or two people
who agree to become committers in order to round out a team in order
to literally meet the requirement, but they may never really commit
code.
As well, even if there are three active committers, social discord
could cause a one or two of them to leave the project-what happens
then?
Page 7 under "Project Acceptance Checklist"
------
"2-3 Major project releases"
Under what conditions would 2 not be ok, where three would be,
or would 4 major releases be too many?
Page 7 under "Project Acceptance Checklist"
------
"List of key adopters (e.g. if the Olympics are using version 1 they
would still qualify)"
This is an odd qualification-specifically, if there is only *one* key
adopter, what happens if they stop adopting it? If the other two
viability tests are not met, but this one is, is this really enough
to justify accepting a project?
Look at it this way: Every four years, the Olympics gets a
makeover-who says they won't change technologies drastically in
that time?
Page 7 under "Project Acceptance Checklist"
------
"3 Year Resource Commitment from a Commercial Sponsor"
When you say commitment, how *binding* is that commitment? The vast
majority of companies I've worked for tend to shy away from strong
binding commitments that span across fiscal years. For a brand new
project, this is the only viability criteria that *could* be
satisfied, and this would be a hard sell to management.
Page 8 under "Project Acceptance Checklist"
------
"Foundation board of directors votes (simple majority) to accept the Project"
I'm curious about this a bit. Why have the board micro-manage project
acceptance of the individual galleries? If the project criteria are met,
under what circumstances would the board not accept the project? If
the gallery sponsor has already pledged enough resources to maintain
the project, and it passes viability tests, this seems a bit excessively
bureaucratic in nature.
+----------------+
+ Other Thoughts +
+----------------+
One of the really cool things about the Apache Foundation is their "Incubator"
project that provides a place for brand-new tiny projects to live until they
become larger.
Perhaps the CPF could also provide an Incubator Gallery of some sort.
---
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on Windows.
-----Original Message-----
From: codeplex-...@googlegroups.com [mailto:codeplex-...@googlegroups.com] On Behalf Of Mark
Sent: Thursday, October 22, 2009 11:11 AM
To: CodePlex Foundation
Ayende Rahien
The "Smart People Need Flexibility" should probably be moved to Principles, it feels out of place where it is now.
"Strong Project Team.", "Everyone can use a mentor." - +1 on that :-)
I think there should be at least a deafult project structure, to define relationships between team members, bringing new members, resolving conflicts, etc. What do you do when you have split in the project? Where some people fork it? Stuff like that.
"Users deserve choice." - I agree in principle, but for crying out load, how many logging framework does the world really need (says the man who is thinking about tatooing NIH on his forehead).
More seriously, I assume you are familiar with the paradox of choice?
The problem is that I also know that I would be opposed to anything like "we will only have one container", so I guess that I have a conflict here.
"Secure Code and Vulnerability Response Plan" - +1 on that.
Another thing that may be great would be to setup some sort of a testing center. I got code that to properly test I need 15 machines for, that is hard to come by.
"Commercial Sponsorship of Galleries." - will the commiters get money out of that?
"Each Gallery will have a designated Gallery Manager appointed by the sponsor for that Gallery" - examples of what exactly you consider as a gallery would be really helpful.
"to ensure consistency the Foundation does make the following required of all projects joining the Foundation." - what is the following?
"Project Acceptance Checklist" - +1 to that
"if the Olympics are using version 1 they would still qualify" - smells like twisting things to fit something in particular.
"3 Year Resource Commitment from a Commercial Sponsor" - who finds this commercial sponsor? What are the duties of a commercial sponsor?
"Committer Acceptance Checklist" - What about patches?
When using something like Git, there are no committers, there is my master branch, and I my pull from other people as well. They don't have write access, I move their changes expliclty.
What about patches in SVN? Same deal.
davidc
I have looked at the pdf document and there are a few things that have
caught my eye. I think that the whole social community umbrella that
is being created is very elaborate, impressive, and very attractive on
a global scale since not all cultures are like the US. Some cultures
are community based where we aren't. I really think that is a good
thing.
When the model reaches the individual with a project to submit I am
seeing something that is bothersome. Please define minimum? Minimum
in quantity or minimum in level of what is needed? Firstly, the
project can't be a brand new project. I think several developers have
pet projects that they have been working on over the years that will
never enter because of the restriction. I have one that I have worked
on off and on for going on 3 yrs now that works with technology that
originally started in the 1960s and that technology is in the lead on
a global scale for what it is designed for. So if we look at the
other options it has to either of been adopted by and in use by
another organization or a corporate has to be sponsor it by paying a
lease with a 3 yr commitment. I can see where that will keep expenses
down on one end, which I will get back to in a second. Back to the
developer again, now the only way I am seeing that they can contribute
is to be a committer. More than likely the key point of contact.
Then there is a catch to that where they could end up walking on
eggshells running the risk of getting the boot because of a peer
process to peer them out over time since a process like this can be
born at any time with any rules.
Staying at the project level still I am seeing the license as a one
size shoe that will fit all. So basically the corporate will get a
free piece of software and a work force resource with minimal
expense. I am not saying that it isn't profitable, but some projects
might need additional layers in the licencing for safety reasons.
This isn't the main thing bothering me though.
Maybe I am way off here and I don't mean this to come off as being
harsh at all. The whole social umbrella is over a gated community.
CPF is the gatekeeper then in the gated community there are these
galleries, which have their own keepers with a CPF representative
there also. I am kind of ruling out the Mentor thing though because
these are supposed to be already mature projects. Unless the
Mentorship is for the business side of things not the development of
the project itself. Now in the gallery you have the project itself
that again has a CPF presense with a manager. I am not putting this
presence down by any means. Inside the gated community there is this
cookie jar or water well full of projects that everyone can tap into
from all the projects. Again this looks very attractive on the
outside. So the corporates can tap into that also just as the
developers can. Thats a nice bridge.
Here is what really bothers me though and I have seen this before.
John Doe peals through all the layers of the onion to get his project
in somehow with all the stipulations. XYZ corp. sponsors the project
as a tax shelter. XYZ corp. reaps the benefits of less expense to get
the product and the marketing takes off. The economy straightens out
later down the road. Then the product is out there the corp. is fine
and no longer needs the original developer so the developer gets the
boot and the project isn't extended. After all the development cycle
is gone full circle why would it be needed anymore. CPF kept their
expense down also and has more of the sponsorship lease money to
invest. Non profits can invest and it is wise and they can use the
same methodologies profit orgs can use. Thats nothing new. So the
reward to the corp is two fold and they are loving it because that is
a nice return on investment.
Where does that leave the John Doe in the community based culture or
the original developer? They can't even say they are a part of that
group if things went south.
The other thing is the smart statement. There is a difference between
smart and intelligent people. Being smart and clever can get someone
on the street out of a bind if they are quick thinker without having
to reason, but intelligent people are smart and additionally think
things through reasoning with thought. I have seen where a corp uses
a clever legal means to pull something completely away from an
individual and call it their own. It happens.
I respectfully ask that the leadership revisit things and take another
look. With the years of wisdom in CPF and the openness to evolve I am
sure that everything can be resolved.
I truly hope that I can add a project later and I don't mean to have
to bring up worse case, but it is something we all have to think
about. Again maybe I am reading it all wrong, but this all seems to
be for software that is mature and in a established status. The whole
project meaning is a business project (with corps) perspective not the
development of software projects. I am intelligent enough to know when
to admit my ignorance and I am hoping I am way off. Is there really a
way for an individual with a project to enter with all assurances?
davidc
made. It might help if a Coordinator is added into the project
level. Not to do what the manager does but to assist with the project
needs. This would free up the developers and leaderships hands more
so that they can continue to work on developing on the project or
several other projects. Don't we all jump back and forth working on
several at a time?
I think one of the challenges that is going to have to be faced is
whether this new innovation to the this new concept of software
project development is going to get more buy in. Surely it is going
to happen over time but innovation isn't automatically accepted by
others when they didn't think of it first or they are dead set in
their ways.
I really respect what Mr. Sam Ramji said earlier today. I am still
going to keep an open mind Mr. Stone.
What can I plead to CPF that would help show that a single project
that ties more than one Corporate technology together could possibly
have potential, if even from an individual?
One last question...Can a gallery have more than one sponsor?
Wouldn't that help? Okay that was two questions so I will stop here.
Rodent of Unusual Size
think need some attention or clarification. So this is going to be a
long message.. :-)
I'll go through the document in order, then collect my conclusions,
and finally try to make some constructive suggestions.
====================
Document Examination
====================
Under _Vision_:
o 'The Foundation will provide central services and governance'
Services for both galleries and projects I can see, but governance
for projects? What was the thought here? I don't think project
governance is really in the Foundation's mission. Exactly what
services are going to be provided needs to be determined.
o 'Individual contributors, corporate sponsors, and project adopters'
What about project communities? I think the omission of that is an
oversight.
o 'Individual contributors bringing projects to the Foundation'
I'm not sure how to interpret this, so I think 'individual
contributors' is the wrong word choice. Replace it with 'project
communities' and I think it works.
o Can a project be in more than one gallery?
Under _Principles_
_Community Viability_
_Smart People Need Flexibility_:
o 'providing key resources (marketing, security, best practice
repository, etc.)'
The security aspect I'll touch on a bit more later, but the
actual list of services eventually needs to be more explicit than
'etc.' :-)
Under _Principles_
_Community Viability_
_Users Deserve Choice_:
o Allowing competitive projects is cool, but what about the
unlikely event of a CPF project being forked and the fork wanting
to be under CPF as well? That's an edge-condition, I know.
Under _Principles_
_Community Viability_
_Continual Improvement Through Sharing of Best Practices_:
o 'post-mortems of all projects after major releases'
Whoa, that's a can of interesting worms! I assume it's the
release process that will be examined each time rather than the
project itself? Or both? Hearing 'We're going to do a
post-mortem on your project after your next release' sounds like
a bit of a demotivating chore -- and actually kind of scary! :-)
Under _Principles_
_Commercial Friendly_
_Commercial Sponsorship of Galleries_:
o The missing bit here is commercial sponsorship of individual
projects -- which is actually a requirement under the 'Project
Acceptance Checklist'.
o How much does it cost to sponsor a gallery? A project?
o What happens to the sponsorship money? Is any available to the
projects?
Under _Organisational Structure_
_Gallery Creation Checklist_:
o The actual P&P for this section will need to be fleshed out
considerably. (See my suggestions at the end.)
o Gallery review only every three years? I think annual, if not
quarterly, reports are a must, informing the board (among others)
on activity and status of the gallery. And what about project
review? Do galleries review the progress of individual projects?
It's implied in _Ongoing Gallery Activities_, but I think it
needs to be spelt out.
Under _Organisational Structure_
_How a Project Joins the Foundation_
_Why a Project would Decide to Join the Foundation_:
o 'The Foundation will provide administrative and infrastructure
support to projects and their communities.'
This is really vague, and sounds as though there's a forge-like
aspect involved. Since this is one of the key aspects of the
Foundation, I think it really needs detailed explanation. Of
course, maybe there isn't one yet. :-)
Under _Organisational Structure_
_How a Project Joins the Foundation_
_Project Acceptance Checklist_:
o '3 committers (signed CLAs)'
I think the CLA issue is potentially knotty. I'll defer that
until later, though.
o '2-3 major releases'
What constitutes a 'major release'? Is the definition at the
project's discretion? Many projects consider release version 0.2
to be a major event.
o 'List of key adopters'
Again, what's the definition of a 'key adopter' and who gets to
decide?
o '3-year Resource Commitment from a Commercial Sponsor'
I think this one is going to be a show-stopper. A project needs
to have a commercial entity already signed on for 3 years of
support before the project can join the CPF?
Under _Organisational Structure_
_How an Individual Becomes a Committer_:
o 'The Project Contact will make sure that all of the necessary
CLAs have been signed and returned to the Foundation prior to
granting access to the source code tree'
I found this language ambiguous, and I think it added to my
confusion about whether CPF was going to be a forge.
For projects that already have a CLA process in place, I think
this could be a source of muddle, with the two lists getting out
of sync easily.
============================
Observations and Conclusions
============================
o I think the 'infrastructure' language is potentially misleading.
Lots of people think of infrastructure as meaning code repositories,
hosting systems, mailing lists, et cetera. I suspect that CPF's
contributions to its internal ecosphere will be the form of
'services,' such as marketing, legal support, and possibly financing
to some degree.
o The interactions between the various roles need to be fleshed out.
Also, contingency plans for resignations, removals, renegements
(e.g., sponsor cannot meet support commitment), and other
exceptions.
o The whole CLA (contributor licence agreement) issue needs to be
sorted out. The potential for excess paperwork seems pretty high.
o Similarly, I don't quite see how the CPF can reasonably be involved
in the whole committer approval process. That's very
project-specific.
o What about projects that want to form their own corporations, à la
Apache and Python? Can they do that under CPF? With CPF's
assistance? I'd like to think so.
o Relatedly, what about projects that are already incorporated? Can
they join CPF? Under what scenario? I'd like to think so on this
one, too.
o The 10'000-metre view of the Security Office sounds promising, but
it needs a lot more detail.
o I think that having a code of conduct/ethics or something similar
would be useful. (Think Debian's social contract, or Google's
'Don't be evil', as starting points.)
o I really like the Best Practices repository concept. I think it has
a lot of potential. We should nurture it.
===========
Suggestions
===========
o Provided that CPF is well funded and sponsored, I think one of the
services it provides to projects should be legal advice. Things
like helping a project draw up bylaws and articles of incorporation,
or choosing the right licence or CLA, or making sure copyright
notices are correctly displayed, or mark registration, and so on.
Dealing with litigation may end up being an issue at some point.
These are not things which I think will be handled in a timely
fashion as _pro bono_, hence my suggestion that CPF retain the legal
services.
o Development of a graph of expectations/responsibility/authority
among the various roles (Foundation, board, advisors, mentors,
gallery managers, technical program managers, sponsors, etc.) should
be on the to-do list. Probably not down to the contract level
(except between the CPF and sponsors), but a clear definition of
what is expected of each role, and what authority it has, will be a
necessity.
o The requirement for a 3-year commitment by a sponsor before a
project can be accepted could possibly be extended to include
willingness by the gallery's sponsor(s) to include the project in
their support.
o If CPF is really going to be involved in security, I think each
project is going to need a specific, responsive, authoritative point
of contact for security issues. This may or may not be the same as
the general contact for the project.
o Automatic filters watching BUGTRAQ for mention of CPF projects would
be a useful function of the Security Office.
o The Best Practices (BP) office could maintain a portfolio of
recommended/preferred CLAs, alongside the licences already
mentioned in the project draft.
o The BP office could perhaps include suggested processes for creating
committers, project voting, et cetera. As far as I know, no-one
else has a 'best practices' effort going, so CPF could codify stuff
for general consumption, not just for use by CPF's own projects.
o Perhaps one of the services CPF could provide to projects in
general, as well as its own, is an electronic repository of CLA
records. Projects that already have CLA systems could perhaps use
some sort of glue to join theirs to the CPF's. *That* could be a
big boon to the industry.
o Regarding the committer approval process, I recommend that CPF's
involvement be backed off to just providing a set of Best Practices.
o Involvement works in more than one direction. There's not only
adoption, but also contribution. Galleries should highlight
organisations that are contributing (manhours, other resources) to
projects as well as those which are using/adopting the code in their
own commercial products.
o Garrett Serack had a good point when he mentioned the IETF documents
referring to standard RFC and I-D language. Using those in the
process and requirements documents might be an excellent idea.