28.4.1. Project startup guide

Launching an open-source project in the AI security space can be a powerful way to contribute to the community’s collective defense. However, a successful project requires more than just good code; it demands a solid foundation from the outset. This guide provides a structured approach to transform your idea into a viable, community-ready project.

Phase 1: Conception and Scoping

Before writing a single line of code, clarity of purpose is your most valuable asset. A well-defined scope prevents project bloat and helps potential contributors understand where they can fit in.

Define the Core Problem

Start with a precise problem statement. What specific gap in the AI red teaming toolkit are you addressing? A vague goal like “improve AI security” is not actionable. A specific one is:

• “Develop a tool to systematically test LLMs for susceptibility to indirect prompt injection via third-party documents.”
• “Create a curated dataset of adversarial images specifically for object detection models in autonomous driving scenarios.”
• “Build a lightweight Python library for applying common data poisoning attacks during model training for research purposes.”

Establish Goals and Non-Goals

Once the problem is clear, define your primary objectives. Equally important is defining what your project will not do. This manages expectations and focuses your efforts.

For a project focused on detecting typographic attacks:

• Goal: Provide a fast, reliable function to detect homoglyphs, invisible characters, and other visual impersonations in text prompts.
• Goal: Integrate with popular LLM frameworks like LangChain or LlamaIndex.
• Non-Goal: Provide defenses against prompt injection or data poisoning.
• Non-Goal: Function as a complete Web Application Firewall (WAF) for models.

Phase 2: Foundational Setup

With a clear plan, you can establish the technical and legal infrastructure that will support your project’s growth.

Choose an Open Source License

The license is the legal backbone of your project. It dictates how others can use, modify, and distribute your work. Choosing the right one from the start is critical. Permissive licenses (like MIT or Apache 2.0) allow for broad use, including in proprietary software. Copyleft licenses (like GPL) require derivative works to also be open source.

Repository and Project Structure

A clean, predictable project structure invites contribution. At a minimum, your repository (e.g., on GitHub or GitLab) should contain:

• A README.md file: Your project’s front door.
• A LICENSE file: The full text of your chosen license.
• A .gitignore file: To exclude unnecessary files (e.g., build artifacts, environment variables) from version control.

A logical directory structure helps everyone find their way around:

project-name/
├── .github/            # Contains issue templates, workflow actions
├── docs/               # Detailed documentation, guides
├── src/                # Main source code (or project_name/)
├── tests/              # Unit, integration, and security tests
├── .gitignore          # Files to ignore in Git
├── CONTRIBUTING.md     # How to contribute (see next chapter)
├── LICENSE             # Your chosen open source license
├── README.md           # Project overview, installation, usage
└── setup.py            # Or pyproject.toml for packaging

Phase 3: Community Readiness

An open-source project thrives on its community. Preparing for collaboration from day one sets a positive and productive tone.

Establish a Code of Conduct

A Code of Conduct (CoC) is a non-negotiable document for fostering an inclusive and respectful environment. It outlines expected behavior and provides a mechanism for reporting violations. You don’t need to write one from scratch; adopting a standard like the Contributor Covenant is a common and effective practice. Place it in a CODE_OF_CONDUCT.md file in your repository’s root.

Create Contribution Guidelines

This is your guide for aspiring contributors, typically in a CONTRIBUTING.md file. It demystifies the process of helping your project. While the next chapter covers this in detail, your initial version should include:

• How to set up the development environment.
• The workflow for submitting a bug fix or feature (e.g., fork, branch, pull request).
• Coding style or standards to follow.
• How to run the project’s tests.

With these foundational elements in place, your project is no longer just an idea; it’s a structured platform ready for its first lines of code and its first external contributor.