GPC June 2011 Working Session Proceedings


OWASP Global Projects Committee

Produced: June 30th, 2011

Approved: July 8th, 2011


Table of Contents

Acknowledgements

Executive Summary

Working Session Budget

Working Session Agenda

Project Inventory

Projects Handbook

Project Hosting Initiative

Lessons Learned

Start Planning Early

Reserve a Separate Location

Set Appropriate Working Session Goals

Record the Working Session

Plan for a Conclusion Presentation

Future Work

Appendices

Working Session Administrivia

Working Session Agenda

Project Inventory

Projects Handbook

Projects Hosting Initiative


Acknowledgements

The Global Projects Committee would like to recognize the following participants present at the first GPC Working Session:

In addition, the GPC recognizes the following virtual participants:

The GPC would also like to thank the OWASP for approving the budget that made the session possible, and to Kate Hartmann and Alison Shrader for executing the actual financial transactions in support of the session.

Finally, the GPC would like to thank the following companies, who directly supported participants and enabled the success of the working session:


Executive Summary

Since the inception of the Global Projects Committee (GPC) at the 2008 OWASP Summit, our goal has been to foster an environment where OWASP Projects can grow and mature. As application security awareness rises, the knowledge and capabilities provided by OWASP Projects becomes increasingly important. To that end, we must balance the history of OWASP Projects as a loosely managed collection of random application security projects with the necessity to provide clarity and assurance to a world that has come to depend on many of these OWASP Projects.

Over the last three years, the GPC made great strides towards this goal, but virtual meetings have their limitations and progress slowed significantly.  Following the initial 2008 Summit, the GPC met in person only once during the 2009 Mini-Summit. During this session, we met with renewed rigor and were able to take advantage of the Summit to outline an overall OWASP Project Lifecycle, along with an ambitious but achievable agenda for the remainder of the year. The argument could be made that the productivity of a week at the Summit matched or exceeded the productivity of the GPC during the entirety of the previous year. Recognizing the value of in person meetings, the GPC requested support for two in person meetings during the 2011 year as part of our overall 2011 Budget[1], which was approved at the May 2011 Board meeting[2].

The GPC held the first of these working sessions in the three days leading up to OWASP AppSec EU in Dublin, Ireland. The GPC Working Session took place from June 6th – 8th at the Trinity Capitol Hotel, separate and away from the official conference venue. This separation was deliberate to minimize distractions and maximize productivity of the GPC. During this session, the GPC met for over 30 hours and accomplished a variety of goals including:

Many of these accomplishments were uncompleted goals from the original GPC charter[3]. The working session also resulted in several deliverable artifacts which are enclosed with these proceedings. We hope that these proceedings demonstrate the value of in person committee working sessions and provide the framework and precedent for other committees to pursue their own working sessions.


Working Session Budget

First and foremost, the GPC understands that OWASP has limited funding and our budget is granted by the OWASP Community as a privilege and a responsibility. Therefore, while we had important work to do, we were also mindful to be frugal as possible.

Our choice of holding the working session to coincide with Global AppSec EU might at first seem uneconomical. We looked at various different options for the location of our first Working Session. After running the projections, it was only approximately $2,000 more to attend AppSecEU than if we were to hold a standalone working session in a random US city. Holding the working session at a major OWASP conference gave us the opportunity to interact with other OWASPers and to support OWASP at the conference itself. Moreover, we found that piggy-backing on an OWASP event was better suited to drawing employer support and to take advantage of any members that were already attending. We felt that the value gained from conference interaction and employer support was worth the additional cost. After examining the OWASP calendar, AppSecEU was also the logical choice to coincide with our 2011 agenda.

A drafted letter, included as an appendix, was given to GPC members to solicit the support of employers. Through this effort, we were able to successfully obtain the full support of Boeing for Keith Turpin’s travel expenses and attendance time. Justin Searle was already scheduled to run a training session at the conference, and he volunteered to arrive early and participate in the first day of the working session, as well as in the evenings on the second and third days after his training session was complete. In addition, Aspect Security supported the time of Jason Li and Chris Schmidt in order to attend. Brad Causey, Larry Casey and Paulo Coimbra were unable to attend in person due to personal commitments. As the Global Industry Committee had already requested the presence of Sarah Baso during the conference for GIC initiatives, the GPC reached an agreement to fund half of her accommodations and airfare in exchange for her administrative assistance during the GPC working session.

After identifying the attendees, the GPC apportioned the budgeted amount for working sessions. The GPC endeavored to identify cost effective airfare and accommodations. To that end, the GPC explored multiple travel itineraries and discovered the cheapest choice was for GPC members to depart Sunday, June 5th and return Sunday, June 12th, even after accounting for the extra nights of accommodation. The difference in airfare to return Friday or Saturday night amounted to several hundred dollars per person. While the additional travel time presented some inconvenience for some GPC members with other time obligations, we were mindful of the savings to the budget. Based on this research, GPC members were given an allowance towards airfare equal to the expected cost of the June 5th-12th airfare. Costs above that expected allowance would have been the responsibility of the individual member, though no such deviations occurred.

In terms of accommodations, the GPC began with the assumption that committee members would utilize shared accommodations. Based on these assumptions and the identified travel time period, the GPC established a baseline cost for seven (7) nights of shared accommodations for committee members. In addition, the GPC sought out an appropriate venue to hold our working session separate from the main conference area. The intention of this separation was to ensure that our work would be productive and uninterrupted. The Trinity Capitol Hotel not only provided favorable rates, but also gave us a discount for booking a block of rooms and provided a board meeting room free to our group. As a result of these favorable terms, the decision was made to allow committee members to have private rooms as the final costs still fell within budget. Ironically, the terms were so favorable that several OWASP conference staff and attendees joined the GPC block and our board meeting room was also utilized as a pre-event command center for the conference. Committee members were given allowances based on the above circumstances, in accordance with our overall budget.

The following table shows the actual costs once airfare and accommodations were finalized:

Airfare

Accommodations

Total

Jason Li

$1,042.30

$627.37

$1,669.67

Chris Schmidt

$1,245.30

$697.16

$1,942.46

Justin Searle

$1000.00

$0.00

$1,000.00

Keith Turpin

$0.00

$0.00

$0.00

Sarah Baso

$542.65

$313.69

$856.34

Additional Expenses

$145.62

TOTAL

$5,614.09

In recognition of the dedication of committee members and success of the working session, Jason Li, in his sole discretion as Committee Chair, opted to utilize the budget for a celebratory dinner at the conclusion of the working session. This dinner was limited to one beverage, one entrée, and one dessert by members and is included in the final budget report at a cost of $145.62. Should there be any objections to this decision, the responsibility of this expenditure lies solely with the Committee Chair.

The total cost of the working session was $5,614.09, which falls well within the projected budget of $6,350.00.

The invitation letter and receipts for airfare, accommodations and the dinner are included in these proceedings as an appendix.


Working Session Agenda

In order to maximize our productivity, we set our working session agenda during our May 2011 GPC Meeting[4]. There were three objectives for the GPC Working Session:

  1. Select a provider from the Project Hosting RFP responses
  2. Establish the workflows for the Project Lifecycle and document in the Projects Handbook
  3. Inventory all OWASP projects for metadata and assign a provisional lifecycle phase

To accomplish these goals, our original plan for the agenda was:

Like any plans, they change rapidly when confronted with reality. We had already procured the hotel’s board meting room for our working session in advanced. As a result, many of the basic working session logistics such as tables, chairs, outlets, flip charts, water glasses, paper, and pens were already readily available. This advanced planning allowed us to focus our setup efforts[5] on quickly gather the artifacts necessary to accomplish our objectives. We began our session shortly thereafter[6] and realized that the most important objective for the working session was to inventory our projects[7]. The inventory process was tedious[8] and arduous[9] as expected and we broke the monotony by pausing to debate and discuss the lifecycle workflows. This interspersed process was dynamic and lively enough that the GPC continued working well beyond our planned time boundaries. By the end of the second day, we had completed the projects inventory[10] and focused the third day[11] the most contentious issue in our workflows: how to review a project. To conclude our session, we examined the various responses we had received to the Projects Hosting RFP and selected SourceForge with a target launch date of AppSecUSA 2012[12].

The above summary greatly oversimplifies the discussion and debate that occurred. Sarah Baso dutifully took detailed notes during the session and formatted them as working session minutes to capture our discussions.

These minutes are included in these proceedings as an appendix.


Project Inventory

Tracking the existence of an OWASP Project has been an ongoing issue for OWASP. Most new project leaders submit their requests to Paulo, who dutifully provides the leader with mailing list credentials, creates a wiki page template, and begins tracking the project. However, we have many projects that were created before we had this process and before Paulo became Projects Manager. Moreover, the reality is that our main web presence is a wiki. Anyone can create a “project” by creating their own wiki page extolling the virtues of their “project”. While the new Projects Lifecycle, as supported by the OWASP Projects Infrastructure, will help dis-incentivize projects from circumventing the new project workflow, we still needed to get a handle on our current projects.

We wanted to conduct as thorough an inventory as possible. So we started with the work Paulo had done with compiling multiple Projects Dashboards[13]. We added any project that had tagged themselves with the “OWASP Project” category on the OWASP wiki[14]. We then scanned through the list of OWASP mailing lists[15] for any mailing lists that seemed to be centered around an OWASP project. Through this compilation process, we identified 213 different “projects” across these various domains.

Our process needed to gather metadata about each individual project and determine its status. For each project identified, we searched for the following metadata:

For projects where some metadata was missing, we gave our best effort to infer the data (e.g. project descriptions scraped together from skimming project wiki pages).

In order to objectively determine the project status, we followed these guidelines:

We were extremely liberal in determining any “activity”, including (but not limited to) any updates to the project wiki page by a project contributor, any commits to a listed code repository, and any project discussion by a project contributor in the project’s mailing list. We were also extremely liberal in determining what constituted a “deliverable” and made no value judgement or quality judgement on the release. For documentation projects, if there was any file (e.g. PDF, Word doc) for download or if the wiki page had a reasonable amount of developed content, it was considered to have a “deliverable”. We did not include project wiki pages where the content was simply an outline of future content or other similar project meta data. For tool and code projects, if there was some item that was available for download, it was considered to have a “deliverable”.

These assignments are provisional and while our process could result in some miscategorization, the planned transition period for projects will allow such assignments to self-correct. Under the new Projects Lifecycle, project categorization is almost entirely community driven.. Therefore, projects that were mistakenly underrated can very easily raise themselves up while projects that are erroneously overrated will naturally fall out of favor at the end of the transition period.

As we began going through the projects, we realized there were a number of projects that were related under the same “umbrella” (e.g. OWASP AntiSamy Java and OWASP AntiSamy.NET both fall more naturally under an OWASP AntiSamy umbrella). We marked such projects and plan to follow up with project leaders to suggest merging into one overall project with sub-projects to represent the different branches. Each sub-project can still have separate project repositories if desired by the respective leaders, but these sub-projects will fall under one project heading for the simplicity of consumers.

In other cases, we noted that a project’s purpose was to act as a knowledge repository and working group to gather information about a specific topic. Such “ecosystems” are extremely valuable for OWASP, but the support and infrastructure provided by the GPC is not conducive or helpful to those efforts. As a result, we suggest that these initiatives are re-characterized into a separate OWASP initiative rather than be supported by the GPC. Under the definition of a project as a “concrete deliverable”, such amorphous projects do not fit well within the GPC’s area of focus. We would endorse a model for such communities, such as the Security Ecosystem[17] model proposed by Jeff Williams, but the GPC does not currently have the bandwidth to lead such an effort. These “projects” will be re-characterized as “Working Groups” on the OWASP Wiki to avoid any confusion until such time that OWASP has a more appropriate infrastructure to support such ecosystems.

Some “projects” were clearly initiatives that had been started (or belong to) other Global Committees and should not be characterized as projects. These “projects” will be re-characterized on the OWASP Wiki to avoid any confusion and turned over to the appropriate Global Committee.

Finally, some projects (e.g “OWASP Individual and Corporate Member Packs plus Conference Attendee Packs Brief”) are not projects at all, but instead stem from an earlier era of OWASP prior to the creation of the GPC. During that era, anything that incurred a financial cost was characterized as a a project. Because money was being spent by OWASP, the organization wanted to ensure that the service provided or the “deliverable” produced had value. The only workflow that existed at the time to perform any kind of criteria-based assessment was the Assessment Critera v1[18] for projects. As a result, any time OWASP spent money on a new initiative, the initiative was deemed a “project”. The organization has outgrown this stage and no longer consider such initiatives as “projects” As such, these “projects” will be re-characterized appropriately on the OWASP Wiki as OWASP initiatives for archival purposes.

From the project inventory, we identified a group of projects to be designated as Flagship projects by looking at looking at several characteristics:

Like all other projects we inventoried, these projects were assigned a provisional designation as Flagship projects. Flagship designations will be reviewed semi-annually as described in the Flagship Selection Process section of the Projects Handbook. The process includes working with industry experts outside of OWASP to ensure an objective selection of projects. As a result, the collection of Flagship can and will change as other projects evolve and mature. These projects were mapped to security areas and SDLC phases as described in the Flgaship Selection Process of the Projects Handbook. We will follow up those project leaders to see if they are amenable to taking on the responsibility of this important designation. Project leaders who agree to these responsibilities will serve as pilot projects for the OWASP Projects Infrastructure and the workflows identified in the Projects Handbook.

With these pilot projects, we hope to smooth out the process and pave the way for all projects by the end of this year. Provisional assignments from the projects inventory will be communicated to project leaders. Following the pilot, we will have a transition period, where project leaders can solicit community members to confirm their provisional status.

As previously noted, the assignments are the result of an imperfect manual process and merely provisional. The workflows identified in the Projects Handbook are largely community driven and project leaders have ample opportunity to self-correct any assignments. As such, there is no need to request reclassification.

The complete projects inventory is included in these proceedings as an appendix.


Projects Handbook

The GPC has made many attempts to raise the quality of projects. These attempts have met with varying degrees of success. However, we have learned several lessons about establishing good, sustainable processes:

The first attempt by the GPC to improve project quality resulted in the Assessment Criteria v2[19]. While this model has its merits, it introduced a great burden on project leaders to perform certain actions, produce certain items, or execute certain processes. Even though we never intended for it to be a burden, we realized that the model could be discouraging to current and potential project leaders. We have worked over the last six months - during the Summit, in off-list emails, and during this GPC Working session - to arrive at a new model. This new model encourages project leaders to improve the quality of their projects. It also helps OWASP consumers differentiate mature, established projects from projects that are still under development or meant to be proof-of-concept projects. We have slowly hashed out workflows in support of this model to ensure that the process does not place undue burden on project leaders.

The Assessment Criteria v2 also placed an enormous amount of strain on Paulo Coimbra, our projects manager, and on the GPC as a whole. Because GPC action was directly required in elevating projects, we became a bottleneck to the progress of projects. As the project review requests continued to come in, the GPC became inundated with project logistics and lost our ability to focus on the bigger OWASP Projects picture. We realized that any new model, and its associated workflows, would have to be scalable. The workflows we have created for this new model are designed to leverage the OWASP Projects Infrastructure. In fact, many of the feature requests enumerated in our Project Hosting RFP were made specifically with these workflows in mind. These workflows leverage the entire community and the innate buzz around a project, rather than depend on a single party managing the process. Additionally, we hope the automated, objective nature of many of these processes removes any concerns of committee favoritism towards specific OWASP projects.

Having addressed the burden and the scalability, the last element to address was to clearly document the policies. As is common practice at OWASP, we created the Assessment Criteria v2 as a work in progress on the OWASP Wiki. In fact, the Assessment Criteria v2 wiki page regarding Project Health[20] still notes its DRAFT status (as of June 2011)! We had divided the task of evaluating projects into looking at individual releases, and then at the overall project. While we were able to quickly create draft processes to evaluate project releases for their consistency with OWASP principles, we were unable to quickly create similar processes to evaluate the overall health of OWASP projects. Unfortunately, this gap left resulted in the misuse of criteria to evaluate individual releases as criteria to evaluate projects as a whole. Despite the misappropriation of our draft criteria, members of the OWASP community started imbuing release indicators with greater meaning than we ever intended. As the misappropriation became more widespread, it became impossible for us to correct and OWASP has been using “Stable”, “Beta”, and “Alpha” to describe projects ever since. As a result, we knew that any new model would have to be completely fleshed out and documented before the model gained acceptance and critical mass. The OWASP Projects Handbook is our manifestation of this lesson. It was created directly out of the work and discussions that occurred during this working session and represents a comprehensive overview of our new model for OWASP Projects.

The OWASP Projects Handbook is included in these proceedings as an appendix.


Project Hosting Initiative

During the OWASP 2011 Summit, the GPC identified Project Hosting as a critical step in standardizing OWASP Projects, and drafted an initial RFP for such a service[21]. As discussed in the GPC 2011 Budget Proposal[22], utilizing a project hosting provider gives us:

Following approval of the GPC 2011 Budget Proposal at the May 2011 Board meeting, the GPC produced a finalized version of the RFP[23], which was launched May 1st, 2011. The RFP was announced and posted on the OWASP Wiki and GPC members personally reached out to four (4) project hosting providers that are commonly seen as leaders in the industry: Google Code, SourceForge, CollabNet, and LaunchPad. In addition, Chris Schmidt and Larry Casey put together an “OWASP Contractor Proposal” that estimated the cost and effort of setting up our own service using freely available tools, such as Confluence[24]. The deadline for proposals was May 31st, 2011 so that proposals could be gathered and reviewed by GPC members in preparation for the GPC Working Session. As part of our Working Session agenda, these proposals would be discussed and compared with the selection of a provider a decision earmarked for the first day of the working session.

No proposals were received from vendors whom we did not solicit. Of the solicited providers, SourceForge engaged in dialogue immediately and provided a response. LaunchPad responded to our request with a standard form letter and did not engage us further. CollabNet originally responded with a standard form letter, but subsequently engaged in dialogue and provided a response. Google Code initially responded that custom project hosting, such as was done for Eclipse Labs, was no longer a service provided by Google. However, one day prior to our departure for the working session, Google reached out to us and indicated a potential change in stance. Our decision was postponed until the third day of the working session to give Google an opportunity to follow up with us regarding their proposal. No further contact was made and our deliberations proceeded without a proposal from Google.

The GPC compared the proposals from SourceForge and CollabNet, along with the “OWASP Contractor” proposal. Given the feature set, overall cost, willingness to provide support, and eagerness to engage in dialogue, the GPC chose to pursue SourceForge’s proposal to support OWASP’s Project Infrastructure Initiative. The GPC will work with SourceForge and the OWASP Board to ensure equitable contract terms can be met and that the service is available to pilot projects as soon as possible.

The Project Hosting RFP and responses we received, are included in these proceedings as an appendix.

Lessons Learned

Overall, the first GPC Working Session was a huge success. While many things worked, there are some things we realize we can improve next time. These items represent things we (and other Committees) should keep in mind for future working sessions.

Start Planning Early

Unfortunately, we had to wait for our committee budget to be approved before going forward with working session planning. Even so, the GPC was able to keep travel expenses reasonable. As stated previously, our research even enabled OWASP to save money by finding more economical accommodations for other OWASP supporters attending the conference! The greatest detriment of late planning was our inability to get Brad Causey, Larry Casey, and Paulo Coimbra to participate in person at the working session, as each had prior personal commitments. Advanced planning helps us ensure that we can get the entire GPC working together.

Reserve a Separate Location

At the 2011 Summit, the GPC spent much of their time hidden away in the golfer’s lounge to work without distractions. We found that any time we left the safety of this lounge, we were drawn into other worthy initiatives. Knowing that there would be conference distractions, we intentionally sought a separate, but nearby location for the working session. Our location ironically ended up being used for some pre-conference planning, but the conference team was gracious and the distractions were minimized. As a result of this separate location, the GPC was able to work productively and undisturbed for three consecutive ten-hour days. We were also able to connect with many OWASPers after the working session. We hope the high level of productivity is clearly evidenced by the documentation and artifacts included in these proceedings. Scheduling working sessions to coincide with an OWASP event works extremely well for the GPC as long as the session is held in a separate but nearby location.

Set Appropriate Working Session Goals

During the working session, we found our productivity to be maximized by intermixing our major goals for the session. The planning and timeline for the working session was driven primarily by the need to make a strategic decision in project hosting providers. In order to take advantage of the service, we needed to be able to identify our projects for eventual migration. As a result, the majority of our session was spent doing the “grunt work” that needed to be done - namely the project inventory. In order to keep the working session lively, we broke from the inventory process occasionally to discuss the projects lifecycle policies. We found that this mix of three overarching goals - a strategic decision to be made, a large task requiring bulk productive work, and a high level policy that needed architecting - served our working session well. The strategic decision ensures that we are proactive leading up to the working session. The large task ensures that we  produce something useful with the working session. The high level policy ensures that we a continually pushing forward the GPC mission. We intend to follow this goal model for future working sessions.

Record the Working Session

The GPC arranged for Sarah Baso to attend the working session to support our efforts. Through her work with the Conferences, Chapters and Industry Committees, she has proven an invaluable resource. Sarah kept running notes and produced the detailed minutes that are included in these proceedings as an appendix. Even with this great work however, we found ourselves wanting even more detail later on. There were subtle points from our debates that we had resolved which were to numerous and small to notate. But as we pieced together these proceedings and the Projects Handbook, we found ourselves recreating and rehashing the same debates only to arrive again at the conclusions detailed in the minutes. We realized that in addition to taking notes and producing minutes, recording working sessions would be a valuable reference to remember subtleties of conversation. Recording a working session also benefits other members of the community by showing the policies and philosophies of the GPC are not created in a vacuum.

Plan for a Conclusion Presentation

Our original model for working sessions from our budget proposal was actually for a two-day period, which was to include documenting conclusions and sharing with the community. We only decided to arrive in Ireland one day earlier because of economics. Flights were cheaper to arrive on Sunday - so much so that it offset the additional night of accommodations. As a result, we ended up holding a three-day working session. Moreover, we could never have anticipated how enthusiastic and productive we would be during our sessions. We certainly did not plan on working ten hour days! While all this work is fantastic, we missed an opportunity to share our completed work with OWASPers at the conference. While we shared much of our progress abstractly in hallway conversations and over late night activities, there is a larger audience that we could have reached. Preparing a short presentation, such as a video or slide show, that briefly recaps our session will help promote awareness of our work, even if official proceedings and documentation are not yet ready.


Future Work

We are already moving forward with SourceForge to establish the OWASP Projects Infrastructure. Once the pilot with select Flagship projects is complete, the next laborious task will be to migrate existing projects from the OWASP Wiki to the new Projects Portal. Part of that task will also be to clean up the Wiki of any stale or outdated information about the GPC. Additionally, we need to acquire and retain various services as outlined in the Projects Benefits section of the Projects Handbook.

During the working session, we came up with the OWASP Enterprise Edition model. This model would be similar to the Flagship designation but instead be centered around individual releases of select OWASP Projects. The idea is for OWASP to provide official, ongoing production-level support for select versions of popular OWASP projects. Such an endeavour would be challenging not only due to the logistics but also due to OWASP principles. While many of the concepts we developed have potential, serious consideration needs to be given in order to flesh out the model. Knowing that we have many other important issues at hand and that no current OWASP projects are ready for this type of model anyway, we deferred further discussion. In the long term, the GPC will continue to develop this model as appropriate.

The GPC anticipates our next working session will coincide with AppSecUSA 2011 in Minneapolis, Minnesota. At the working session, we plan to unveil the OWASP Projects Portal, mark the start of the project transition phase, and begin enforcing the policies laid out in the Projects Handbook.


Appendices

Working Session Administrivia

Working Session Agenda

Project Inventory

Projects Handbook

Projects Hosting Initiative


[1] GPC 2011 Budget Proposal

[2] Board Minutes (May 2, 2011)

[3] Original GPC (then the Global Projects & Tools Committee) Agenda

[4] GPC Meeting Minutes (May 13, 2011)

[5] Live Tweet #1 From the Working Session

[6] Live Tweet #2 From the Working Session

[7] Live Tweet #3 From the Working Session

[8] Live Tweet #4 From the Working Session

[9] Live Tweet #5 From the Working Session

[10] Live Tweet #6 From the Working Session

[11] Live Tweet #7 From the Working Session

[12] Live Tweet #8 From the Working Session

[13] OWASP Projects Dashboard v1;  OWASP Projects Dashboard v2;  OWASP Projects Dashboard v2.0

[14] OWASP Project Category

[15] OWASP Mailman Mailing Lists

[16] Note that we began with a fourth category to capture media projects, such as the OWASP Podcast. Ultimately, we felt that documentation projects are not limited to deliverables in print form, but any deliverable that communicates information. As such, media projects were subsumed into the documentation category.

[17] Security Ecosystem Model

[18] Assessment Criteria v1.0

[19] Assessment Criteria v2

[20] Assessment Criteria v2 - Project Health

[21] Summit Draft of Project Hosting RFP

[22] GPC 2011 Budget Proposal

[23] Final Project Hosting RFP

[24] Confluence (by Atlassian)