Creating New Projects
The Open Web Foundation is an attempt to create a home for new community-driven open specifications. Following the open source model similar to the Apache Software Foundation, the Foundation has built a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specifications. The Foundation is trying to break the trend of creating separate foundations for each specification, coming out of the realization that we can come together and generalize our efforts. This page describes how the Open Web Foundation manages new specification projects and how you could bring a project to the Foundation if you're interested in doing so.
What is the Incubator?
The Incubator Project Management Committee (referred to as the "Incubator" or "Incubator PMC") is how new open specification projects enter the Open Web Foundation. It accepts new projects into the Foundation, helps to provide guidance and support while developing an open specification, educates new contributors in the philosophy and guidelines for collaborative development, and ultimately sees a project through to the completion of a specification and a mature and diverse community. At the end of the process, the Incubator proposes to the Board the promotion of projects to independent project status once their community has met the requirements for graduation.
The Incubator PMC is tasked with the following responsibilities:
- the acceptance and oversight of new projects submitted or proposed to become part of the Foundation;
- providing guidance and ensuring that projects under its purview work according to the Foundation's philosophy and guidelines for collaborative development; and
- regularly evaluating projects under its purview and making the determination in each case of whether the project should be abandoned, should continue to receive guidance and support, or should be proposed to the Board for promotion to independent project status.
What are the objectives of the Incubator?
To provide a clear path for potential specification projects within the Open Web Foundation to move from a proposal through to a fully independent project with a completed specification in such a way as to ensure:
- New projects are developing specifications according to the Open Web Foundations's philosophy and guidelines for collaborative development;
- Intellectual Property Right contributions on specification work from all of the contributors have been made to the project according to the terms of the Open Web Foundation IPR Policy (link here) and all contributors have issues non-assertion statements over the completed specification; and
- Only those specification projects that meet the Open Web Foundation's requirements are fully accepted into the Open Web Foundation.
How do I propose a new specification project?
Preparation
First off, make sure you're subscribed to the OWF discuss mailing list and are understanding what is going on. Do some research around aspects of the specification you're wanting to create have been worked on in the past either within OWF or anywhere else. If you're currently thinking about making a proposal by yourself, think about others who might be interested in contributing to it as well; most of the successful projects we've seen have been started by around three initial people. Feel free to ask questions on the mailing list if there are things which you don't quite understand.
Once you've started to understand how OWF works, ideally found one or two people to make the proposal with you who are committed to working on the project, and have a more clear idea in your heads about what you're going to be creating then it's time to recruit a Mentor. A Mentor is an existing member of the Foundation which means that they've done this a few times before and will be able to help you navigate through the Incubator.
Once you have a Mentor, you'll want to actually write up your proposal more or less using the following outline. It should be sent to the Incubator mailing list (link here) first for discussion and then after a lively discussion followed with a new thread for a vote on accepting the new project.
The Proposal
Once you've worked on creating the proposal along with your Mentor, you should email it in plain text to the Incubator mailing list with a subject that is prefixed with PROPOSAL. If there is interest in the proposal, expect a lively debate to begin. Approval is an open and democratic process (link here to voting rules) where discussion is an important part of opinion formation. The proposal you initially post will probably evolve and require some more work as the discussion continues, though ultimately will become better and gain more support throughout the OWF community. Always keep in mind that people asking questions means that you're interested them in one way or another, even if hard questions are asked they are always a good thing.
It's generally recommended that you use the wiki (link here) to evolve your proposal. Placing your original proposal on the wiki before starting the proposal discussion thread is seen as best practice and then allows people to subscribe to changes to the proposal as you make them. While the wiki is a good collaboration tool, please keep in mind that no decisions or discussion should occur on the wiki; rather on the mailing list (link here).
The Vote
When the proposal seems finished and some sort of consensus has emerged, the proposal should be put to the vote. If the wiki is used to develop the proposal, please ensure that the wiki matches the final proposal then add a notice to the wiki that development of the document is now complete.
What are the roles of people involved in a project?
What is the proposal template?
The aim of presenting a template with examples and comments is educational. Proposals are not required to adopt this format. Every proposal is different. There may be sections which don't seem to be useful. It's fine to miss them out and to add new ones that the proposal seems to need. Best practice evolves. Innovation is acceptable.
The format is less important than the content.
Abstract
A short descriptive summary of the project that is ideally one sentence in length.
OAuth will allow secure API authentication in a simple and standard method from desktop and web applications based off of similar work done by AOL, Google, and Yahoo!.
Proposal
A lengthier description of the proposal that is reasonably declarative about what the specification will do.
OAuth allows users to grant access to private resources on one site, to another site without having to exchange the user's password. While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access private resources without sharing a user's identity at all or at least its secret parts...
Background
Context for those not familiar with the space and it's history. Why is a specification needed now to solve this problem? Who else has done similar work and what is it's status?
OAuth will be a standardization and combined wisdom of many well established industry protocols. It will be similar to other protocols currently in use (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). Each protocol provides a proprietary method for exchanging user credentials for an access token or ticker. OAuth will be created by the community carefully studying each of these protocols and extracting the best practices and commonality that will allow new implementations as well as a smooth transition for existing services to support OAuth...
Rationale
Explains why this specification project needs to exist and why should it be adopted by the Open Web Foundation. This is the right place for discursive material.
Current Status
Has this community started doing any work yet? Are there any other documents that might be used as a base for this specification? If so, how were they developed and by whom?
Meritocracy
The Open Web Foundation is based on the principal of meritocracy (largely popularized in open source software by Apache). This means that no one has to pay money to participate nor is given special privileges based on the company they work for. Rather, all individuals within a project are recognized based off of the merit of their contributions.
Show how this is understood by the proposers.
Community
The Open Web Foundation is interested only in communities.
Proposals should start with a small community and have the potential to grow and renew this community by attracting new users and contributors. Explain how the proposal fits this vision. What is the potential for this specification?
Initial Editors
The Open Web Foundation is comprised of individuals. It's useful to understand who the initial editors will be for this project, their backgrounds, and corporate diversity.
Mentors
The eligible and willing individuals nominated to Mentor this project. You must have at least one Mentor before making the initial proposal and most likely others may volunteer throughout the discussion.
Alignment
Why is the Open Web Foundation a good fit for this project? Has other related work occurred here in the past? What are related projects within OWF and how might this community work with them?
Known Risks
Risks aren't necessarily a bad thing by themselves, but rather help you think through what problems could be encountered and how they might be avoided. Is there a risk of the specification not being completed? Do the initial editors have experience with developing open specifications based on meritocracy? Are the initial editors and contributors from the same location or company? Is the project dominated by people who are currently being paid to work on it, what will happen if their employers no longer see the same degree of value in the specification?
An Excessive Fascination with the Open Web Foundation Brand
Concerns can be raised that some projects appear to be proposed just to generate positive publicity for the proposers. This is the right place to convince everyone that is not the case.
Documentation
What should people reading this proposal read to learn more? Maybe some links to pieces you discuss in the Background.
Mailing Lists
Subversion Directory
We've found the IETF's XML2RFC format works well and can be maintained easily in version control.
Issue Tracking
While bug trackers can work, they're often overkill for specification work. A wiki page normally works pretty well.
Comments (0)
You don't have permission to comment on this page.