jetDS Contributor Roadmap And How To Get Started in Contributing Towards Upstream and jetDS

[GraysonPeddie]

A clear guide for contributors who want to help build the jetDS identity appliance.

Overview

jetDS is an identity‑centric server appliance built on Linux, powered by 389 Directory Server, managed through Cockpit, and designed for administrators who prefer browser‑based workflows over CLI complexity. This roadmap outlines areas where contributors can help expand jetDS into a full identity platform.

High‑Impact Contribution Areas

1. DHCP Server Panel

   jetDS needs a Cockpit module for managing ISC DHCP or Kea DHCP:

   • Create/edit scopes
   • Manage reservations
   • View leases
   • Integrate with LDAP for identity‑based assignments
   • Apply safe defaults and validation

   This replaces CLI‑only workflows with a graphical interface.

2. DNS Server Panel

   A Cockpit module for BIND or Knot DNS:

   • Zone creation
   • Record management
   • Reverse zones
   • DNSSEC integration
   • Identity‑aware DNS (future)

   This is essential for organizations using jetDS as a core identity appliance.

3. FreeRADIUS Panel

   A Cockpit module for managing FreeRADIUS:

   • 802.1x configuration
   • MAC Authentication Bypass (MAB)
   • VLAN assignment rules
   • LDAP integration
   • Certificate management

   This enables identity‑based network access control.

4. LDAP Object Presets

   jetDS needs simplified LDAP object creation:

   • Basic User
   • Basic Group
   • Service Account
   • Device Object (MAC address)
   • 802.1x Object
   • Organizational Unit templates

   These presets reduce LDAP jargon and help administrators get started quickly.

5. Replication Wizard

   389 DS replication is powerful but confusing. jetDS needs:

   • A Cockpit‑based replication wizard
   • Automatic supplier/hub/consumer role assignment
   • “Join existing identity cluster” workflow
   • Automatic agreement creation
   • Replication health dashboard

   This makes jetDS replication behave more like Windows AD domain joining.

6. OU‑Level Policy Engine

   Long‑term vision: a policy engine similar to Windows Group Policy.

   • Per‑OU policy assignment
   • Policy inheritance
   • Policy enforcement agents
   • Policy auditing
   • Integration with Ansible (future)

   This is the most ambitious part of the roadmap and will define jetDS’s identity‑appliance future.

Supporting Contribution Areas

Documentation Improvements

• jetDS architecture overview
• jetDS identity workflows
• jetDS appliance philosophy
• jetDS PowerShell usage
• jetDS Cockpit module development guide

Note that the documentation will need to be compliant with accessibility standards (WCAG) in order for users of screen readers to properly access the documentation. Use Axe to do automated testing and perform manual testing by using TAB keys to navigate between links. Ensure that there is a focus outline for links in documentation. HTML is preferred whenever possible, although in the Discussion Forum, GitHub uses Markdown, so GitHub should take care of ensuring accessibility for everyone. The Documentation Standards section goes into more detail.

Testing & Feedback

• ISO testing
• Cockpit workflow testing
• Identity workflow testing
• Replication testing
• Certificate‑loading bug reproduction

Bug Reports & Issue Triage

Especially around 389 DS, Cockpit modules, and PowerShell integration.

Development Skills That Help

• Cockpit module development (HTML, JS, systemd integration)
• 389 Directory Server administration
• LDAP schema design
• FreeRADIUS configuration
• DNS/DHCP server configuration
• PowerShell scripting
• Systemd service design
• Identity management concepts
• UI/UX for admin tools

Contributors don’t need all of these — even one area helps.

How to Get Started

• Clone the jetDS repository
• Join the Discussions
• Pick a roadmap item
• Ask questions
• Share prototypes
• Submit pull requests
• Help test new features

jetDS is built for administrators who want safety, clarity, and browser‑based management. Contributors help make that vision real.

Documentation Standards (Accessibility‑First)

jetDS documentation must follow accessibility best practices so that all administrators — including those using screen readers or keyboard navigation — can fully access the content. Documentation is part of the appliance experience, and accessibility is a core requirement.

Accessibility Requirements

• WCAG compliance
  All documentation should follow WCAG 2.1 AA principles for perceivable, operable, understandable, and robust content.
• Use semantic HTML whenever possible
  HTML provides better structure for screen readers than Markdown.
  GitHub Discussions uses Markdown, but contributors should still follow semantic structure (headings, lists, alt text, etc.).
• Keyboard navigation must work
  Test documentation using the TAB key to ensure:
  • links are reachable
  • buttons are reachable
  • interactive elements have proper focus
  • no “keyboard traps” exist
• Focus outlines must be visible
  Links and interactive elements must have a visible focus outline so keyboard users can track navigation.
• Use Axe (browser extension for Chrome, Edge, or Firefox) for automated testing
  Contributors should run Axe (browser extension or CI integration) to detect:
  • missing labels
  • contrast issues
  • missing alt text
  • incorrect heading structure
  • ARIA misuse (ARIA is Accessible Rich Internet Applications)
• Avoid jargon when possible
  jetDS documentation should be approachable for administrators who are not LDAP experts.
  Use presets, examples, and plain language.
• Images must include alternate (alt) text
  Every screenshot or diagram must include a meaningful description (simply provide a visible text below the screenshot or diagram; if writing HTML, simply mark decorative images as an empty or null string such as alt="").
• Color is not the only indicator
  Avoid instructions like “click the green button.”
  Use labels, icons, or text descriptions.

Why This Matters

jetDS is designed for administrators who prefer browser‑based workflows and guided interfaces. That audience includes:

• screen‑reader users
• keyboard‑only users
• users with low vision
• users with cognitive load concerns
• users who rely on clear structure and predictable navigation

Accessible documentation ensures jetDS is usable by everyone, not just those comfortable with traditional Linux documentation styles.