Skip to main content

Project Contribution Model (v1.0)


Vision

Project Astra, Athena, and Aegis are long-term engineering initiatives focused on learning, experimentation, and building production-grade software.

The objective is learning and engineering excellence—not commercial ownership.


Roles

Founder & Lead Architect

Responsibilities

  • Product Vision
  • Roadmap
  • Architecture
  • Technology Selection
  • Final Technical Decisions
  • Code Review
  • Release Planning
  • Documentation Standards

This role remains with the project founder.


Contributors

Anyone can contribute.

Examples

  • Backend
  • Frontend
  • AI
  • Security
  • Testing
  • DevOps
  • Documentation
  • UI/UX

Contributors own the work they implement.


Ownership

Nobody owns the project except the founder.

Everyone owns their contributions.

Every merged Pull Request permanently records its author.

Credit is never removed.


Decision Making

Architectural decisions are discussed openly.

The Lead Architect makes the final decision after considering all viewpoints.

This keeps the project technically consistent.


Code Standards

Every contribution should include:

  • Documentation
  • Unit Tests (where appropriate)
  • Clear Commit Messages
  • Meaningful PR Description

No direct commits to main.

Everything goes through Pull Requests.


Credit Policy

Every contributor receives recognition.

Examples:

README

Contributors

Abhishek
Frontend Dashboard Module

John
Terraform Module

Sarah
Authentication Module

Release Notes

Git History

LinkedIn appreciation posts (optional)


AI Policy

This is important.

I would write something like this:

AI-assisted learning, brainstorming, and code review are welcome.

Contributors should understand, review, and take responsibility for any code they submit.

The project values engineering understanding over simply generating code.

Notice this doesn't ban AI or require anyone to disclose exactly how they use it. It focuses on accountability.


Intellectual Property

The overall project direction remains under the founder's stewardship.

Contributors retain recognition for their contributions through Git history and project acknowledgements.


Inactive Contributors

If someone becomes inactive:

  • Existing contributions remain credited.
  • The project continues.
  • Others may extend those modules while preserving attribution.

Communication

Technical disagreements are encouraged.

Personal disagreements are not.

Ideas are challenged.

People are respected.


Learning Philosophy

The purpose of the project is

  • Learn deeply
  • Build professionally
  • Document decisions
  • Share knowledge

No question is considered "too basic."


Success Criteria

The project's success isn't measured by GitHub stars.

It's measured by:

  • Better engineering decisions
  • Better architecture
  • Better collaboration
  • Better documentation
  • Better understanding

Comments

Popular posts from this blog

🌿 AN ARCHITECT'S FIELD GUIDE TO THE SPRING PLATFORM

Spring Forward: The Architecture-Defining Release Cycle of 2025-2026 How Spring Framework 7, Boot 4, Integration 7, Batch 6, and AI 2.0 are reshaping the way enterprise systems are designed, built, and operated — and what every tech lead needs to know before their next architecture review. The Spring ecosystem has never moved faster. Across six major projects — Framework, Boot, Integration, Batch, and AI — the teams at Broadcom have delivered what I consider the most consequential release cycle in the platform's history. This is not a changelog summary. It is an architectural assessment of what these changes mean for the systems we design, the teams we lead, and the technical decisions we will have to defend in production. 📊 Figure 1 — The Spring Platform at a Glance (2025-2026) Project Latest Version Headline Theme Key Innovations 🏗️ Spring Framework 7.0 Correct-by...

Inside the Top 5 Spring Boot Security Vulnerabilities (2026): Root Cause, Attack Surface, Patch Analysis & Mitigation

  Spring Boot remains one of the most trusted frameworks for building enterprise applications. However, even mature frameworks occasionally introduce security flaws through edge cases, configuration assumptions, or dependency interactions. This article analyzes five of the most impactful Spring Boot vulnerabilities disclosed recently—not just from a CVE perspective, but from an architect's point of view. For each vulnerability we'll cover: What was the bug? How could an attacker abuse it? (conceptually) What changed in the patch? How should enterprise teams mitigate it? 1. CVE-2026-22731 – Authentication Bypass via Health Group Path Severity: High (CVSS 8.2) What was the bug? Spring Boot Actuator allows custom health groups to be exposed under additional paths. Under specific configurations, Spring Boot generated request-matching rules that were broader than intended. As a result, protected application endpoints located beneath that path could mistakenly inherit the Actuator...

Project Aegis: From an Empty FTP Directory to a Root Shell — Exploiting vsFTPd 2.3.4 Manually

  Project Aegis | Cybersecurity Lab Sometimes the most interesting vulnerability isn't hidden in the files a service exposes. It's hidden in the service itself. During a recent Project Aegis lab session, I started with what looked like a fairly uninteresting FTP service on a deliberately vulnerable Metasploitable 2 virtual machine. Anonymous FTP login worked. The root directory appeared empty. There were no obvious files to download and nothing immediately interesting to enumerate. Yet, within the same service, I eventually obtained a root shell . The journey was a useful demonstration of a complete vulnerability-assessment workflow: reconnaissance → service identification → vulnerability research → automated validation → source inspection → manual reproduction → exploitation → impact verification Most importantly, it reinforced a lesson I want Aegis to teach: Don't just run security tools. Understand what they're actually doing. The Lab For this experiment, I used an ...