IAB Tech Lab Open Source Initiative

Last updated: January 15, 2024

About the Open Source Initiative

IAB Tech Lab believes that the next generation of standards will evolve as code.  We are enthusiastic about supporting the industry in this regard and facilitating the governance and management of relevant open source projects that will support evolution, deployment and adoption of standards via code development, as well as foster innovation while identifying and developing new foundational technologies in support of the advertising industry needs. Our initial focus is to develop reference implementations, actual standards implementations that can be directly integrated, and tools that can be helpful in deploying standards. The initiative will be governed by the Tech Lab Architecture Group composed of Extreme Reach, Gumgum, GroupM, Oracle, Tapad, and The Trade Desk.

Projects

Here is a list of projects that we propose to launch the initiative with:

  • Unified ID 2.0 (UID2) 
  • Brand suitability test benchmarks
  • Ads.cert
  • Open RTB and Adcom Protobuff reference  specification 
  • VAST Validator
  • Safe HTML Ad Richmedia Container (SHARC)

Open Source Initiative github instance is here: IABTechLab OpenSource

Governance

The Tech Lab team reviewed several open-source governance models to determine what we can learn from others and which model of governance most closely reflects our goals, including:

  • Allow anyone to initiate an open-source project proposal
  • Have fair mechanisms to evaluate and determine acceptance of projects
  • Ensure long-term maintenance and support of projects
  • Provide a project management mechanism and supporting infrastructure
  • Encourage collaborative approach and due diligence for development
  • Support hosting infrastructure, evaluation, and release procedures

Based on the above we have adapted a governance model similar to that utilized by the Apache Foundation.  Parameters for that model include:

  1. Tech Lab Architecture Group consisting of CTOs and other engineering leaders from member companies shall, subject to oversight by the IAB Tech Lab Board of Directors, be the overall program management body to decide on governance decisions and project approvals.
  2. To foster developer community and contribution, participation should follow an individual rather than their organization.
  3. Tech Lab will assign one of our Product Managers as Open Source Initiative lead for all projects to evangelize to the advertising/media industry developer community and coordinate and track all projects.
  4. Projects can be submitted by any individual developer as per submission guidelines. Each project shall have a Project Release Manager (usually the individual submitting the project proposal or her/his delegate).
  5. All projects will start in “Incubation” stage when approved by the Architecture Group. Projects in Incubation shall be managed by the Project Release Manager in coordination with Tech Lab Lead.
  6. Tech Lab Architecture Group shall decide when to promote the project to “Promoted” stage. Promoted projects will have additional contribution and level of support from Tech Lab team and membership —  e.g., a project-specific Commit Group, funding etc.
  7. All projects will be released under Apache 2.0 license
  8. Quarterly review of project submissions and status will be conducted by the Tech Lab Lead and Project Release Managers, leading to submission to the Architecture Group.
  9. Sprint meetings etc. will be the responsibility of the Project Release Manager. If there is a need for large group meetings Tech Lab Lead can help coordinate.

Contributor License Agreement

A Contributor License Agreement (CLA) defines the terms under which intellectual property has been contributed to a company/project. The purpose of a CLA is to ensure that IAB Tech Lab has the necessary grants of rights over all contributions to allow them to be distributed under the chosen license.

Contributors to the projects will be made under one or more roles as defined below:

  • Project Release Manager is overall responsible for the development of the project and has write access to the repository
  • Committer is a developer with write access to the repository and responsible for making final changes.
  • Developer is a contributor to the project in form of code or documentation and may take on other responsibilities for managing the project

All contributors who wish to or are required to have write access (Committers) need to be/do one of the following:

To become a Committer, please email support@iabtechlab.com with the link to the project repository to which you’d like to commit as well as the signed copy of the Contributor License Agreement if required. Additionally, for non-members who wish to contribute to the Unified ID2 (UID2), you need to sign this non-member IPR.

Code of Conduct

Any public project invites people from diverse backgrounds and to develop a healthy community, it is necessary that all contributors respect each other and the work is executed in a manner that encourages spirit of collaboration and advancement for everyone. 

To achieve a healthy and progressive community and encourage good behavior, it is necessary to ensure that all participants are aware of the Code of Conduct and know what to expect.

Our code of conduct emphasizes the following:

  • Good behavior and respect for others
  • Forbidding harassment or abusive behavior
  • Discouraging use of discussion forums to play out a fight
  • Use of the project or its forums for purpose other than building the requirements of the project

It also lists expected behavior and unacceptable behavior, as well as a way to report potential offenses. Please write to codeofconduct@iabtechlab.com for reporting misconduct and for Tech Lab to define a course of action for resolution.

Acceptable behaviours:

  • Respect others: In all communication and code reviews or comments, be respectful of others. In case of disagreements, ask, explore and debate and not judge. 
  • Be assertive but not aggressive. 
  • Be persuasive and not bitter
  • Assume positive intent
  • Welcome new members, as they may need direction on previous discussions and may have questions previously addressed. Accommodate their inquisitiveness.
  • Be kind to beginners: Many beginners join open source projects to learn. Be supportive and mentor them. This does not mean the project should lower the bar on code quality. Just ensure that a learning environment is developed
  • Be careful about what you say and how you say it to ensure people do not misunderstand — e.g., sarcasm is better accentuated with an emoticon so it’s clear to everyone. Best is to use plain language
  • Be classy when you wish to no longer participate in a project. 

Unacceptable behaviours:

  • Do not harass anyone
  • Do not promote bigotry by referring to anyone’s identity or background in a negative way.
  • Do not insult anyone for their lifestyle, personal choice or other practices owing to religion, ethnicity or culture
  • Do not dox anyone, i.e., reveal their personal or private information without explicit consent
  • Do not pursue unwanted attention from other participants or with content not applicable to the project

Project Submission Guidelines

All projects must be created on Tech Lab github for approval. For project submission purpose, the project proposal must contain the following information:

  • Project Name
  • Abstract: Short 1-2 sentence summary
  • Proposal: Brief description of the proposed project and objectives
  • Background: Commentary about the need for the project. This should be descriptive in a way for someone without any background in the project domain to be able to understand.
  • Opportunity Assessment: Why this project needs to be an industry effort and how it could help the industry overall. It should also include the scale of adoption and use by the industry.
  • Initial Goals: Brief outline of expected deliverables for an MVP state
  • Community Details: Introduce core developers and support that is already present for this project. What kind of skills and expertise are needed for additional contributions?
  • Other Needs and Support: If the project requires help from Tech Lab for hosting or other infrastructure, for example…
  • Project Risks
  • Regulatory requirements

Submit project proposals with the above information to support@iabtechlab.com. Once the project is submitted, the Tech Lab Lead will present the projects during a quarterly meeting of Tech Lab Architecture Group for approval.

Once approved the developer will be assigned the role of Project Release Manager and informed about the decision, and the Tech Lab Lead will monitor progress on a regular basis.

The Project Release Manager shall invite contributions from the community and begin work on the project.

Project Status

There are two statuses for any project:

  1. Incubation Stage: This is where most project will start. At this stage they are self managed by the promoter of the project, i.e., The Project Release Manager
  2. Promoted Stage: Projects will be upgraded to promoted stage from time to time by the Tech Lab Architecture Group based on criteria like development milestones accomplishment, adoption status, contribution levels, industry urgency etc. In the promoted stage IAB Tech Lab will review for the support and project needs to deliver higher value to the industry. They will work with the Project Release Manager to define and establish the support needed

Quarterly Report

Each Project Release Manager needs to submit a project report for review by the Tech Lab Architecture Group. The project report should summarize the health and progress of the project and include the following:

  • Brief summary of the project to include project name, github link, and abstract
  • Project management brief:
    • How is the release being managed? 
    • If there is a team of committers, how is testing being done and code review process being followed?
  • Achievements for the quarter:
    • What key features were released or other work was completed? 
    • Number of bugs/issues reported and resolved/developed
    • Number of contributors, including growth or drop in contributors
  • Blockers, issues, contentions, etc.
  • Completion of initial goals from proposal and gap vs. initial goals from proposal
  • Committers of the project (if there is a team of committers)
  • Future plans (features to be developed in next quarter)
  • Strategic/Marketing needs
  • Infrastructure needs
  • Adoption data (Which companies are using or committed to using the project?)
  • Legal needs if any

The project should have a Project Report section where all of this information can be added and submitted to the Tech Lab Lead.

Project Management and Release

All projects must follow a collaborative and consensus driven process led by the Project Release Manager for projects in the incubation stage. Projects in the Promoted stage may follow a process defined by the project governance team, such as creating  a Commit Group or a working group.

Project Management

  • Every project should strive to have the following roles assigned:
  • Project Release Manager is overall responsible for the development of the project and has write access to the repository
  • Developer is a contributor to the project in form of code or documentation and may take on other responsibilities for managing the project
  • Committer is a developer with write access to the repository and responsible for making final changes. Please note that comitter is not a decision maker. The decision of changes to be added are made by the Project Release in consultation with a team of developers working on the project or a process as defined in the project.
  • All projects should define a cadence for releases
  • All projects should define a milestone so the community using the project has a predictable roadmap
  • Github should be used for managing milestones, issues and project work

Release Process

The objective is to be flexible and allow each project to define this as per the project structure and needs. Following is recommended:

  • All developers make a pull request for every change
  • Every pull request must be reviewed at least by one other developer
  • Project Release Manager in collaboration and consensus with other developers and committers should decide whether the pull request is accepted or rejected. In case of promoted projects, the governing group of the project should make this decision
  • Committers should commit and merge the reviewed and accepted requests
  • Project Release Manager should define the release versioning and ensure that it is followed
  • QA automation: The project should maintain some level of QA process for every release

Decision making

  • Project Release Managers should work to make all decisions with collaboration and consensus of the contributing developers and committers.
  • In absence of consensus, voting may be used
  • Yes vote (+1), No vote (-1) and abstain (0)
  • No votes should present a reasons and/or an alternative solution to be considered
  • Contributors should discuss and develop consensus on alternative proposals
  • If there is no decision, it can be referred to IAB Tech Lab contact who will consult with IAB Tech lab Architecture Group to render a decision

Related News