With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
Gittensor is a specialized subnet on the Bittensor network that incentivizes and rewards developers for contributing to open-source software. In essence, it creates a decentralized “open-source workforce” by allowing developers (as miners) to earn cryptocurrency for meaningful contributions (like code improvements and pull requests) to selected open-source projects. This addresses the common problem that open-source contributors usually aren’t paid for their work – Gittensor provides a protocol-level reward mechanism to fill that gap. Successful contributions to designated repositories are measured and translated into token rewards on the Bittensor blockchain, so that developers are financially rewarded for improving and maintaining open-source software.
To achieve this, Gittensor defines two participant roles in its network:
Gittensor turns open-source code contributions into a “mining” activity in a blockchain context. By marrying GitHub activity with Bittensor’s incentive model, it accelerates open-source development and ensures developers can be rewarded for meaningful work on public software projects. The subnet effectively creates a positive feedback loop: important open-source projects get more contributions, and developers receive crypto tokens (called alpha on this subnet) as compensation for improving those projects.
Gittensor is a specialized subnet on the Bittensor network that incentivizes and rewards developers for contributing to open-source software. In essence, it creates a decentralized “open-source workforce” by allowing developers (as miners) to earn cryptocurrency for meaningful contributions (like code improvements and pull requests) to selected open-source projects. This addresses the common problem that open-source contributors usually aren’t paid for their work – Gittensor provides a protocol-level reward mechanism to fill that gap. Successful contributions to designated repositories are measured and translated into token rewards on the Bittensor blockchain, so that developers are financially rewarded for improving and maintaining open-source software.
To achieve this, Gittensor defines two participant roles in its network:
Gittensor turns open-source code contributions into a “mining” activity in a blockchain context. By marrying GitHub activity with Bittensor’s incentive model, it accelerates open-source development and ensures developers can be rewarded for meaningful work on public software projects. The subnet effectively creates a positive feedback loop: important open-source projects get more contributions, and developers receive crypto tokens (called alpha on this subnet) as compensation for improving those projects.
Gittensor’s “product” is essentially an incentive layer and platform for open-source development, built on the Bittensor blockchain. Technically, it consists of a custom Bittensor subnet (network) with corresponding open-source software that developers and validators run to participate. The core components of the build include:
Bittensor Subnet Logic: Gittensor is implemented as Subnet UID 74 on Bittensor (hence the moniker Subnet 74). The subnet defines a unique incentive mechanism tailored to code contributions, embedded in the Bittensor Subtensor chain. This includes the on-chain logic for registering miners, validating contributions, and minting rewards (alpha tokens) based on the custom reward function. The reward function (open-sourced in the code) quantitatively measures developers’ merged pull requests to determine payouts. In Bittensor terms, Gittensor produces a new kind of digital commodity – instead of AI model responses or data, it produces open-source software improvements, with their value judged by decentralized consensus.
Miner Client Software: An open-source client that developers (miners) run locally. This is typically a Python-based daemon or script (the project is primarily written in Python) that interfaces with both the Bittensor network and GitHub. Miners provide a fine-grained GitHub PAT to this client (scoped to allow read access to their repositories and PRs) and register on the subnet. The miner software monitors the developer’s pull request activity on the approved repositories and interacts with the Bittensor chain to claim rewards when contributions are verified. Essentially, from a miner’s perspective, the “product” is a background agent that turns their GitHub contributions into token earnings automatically.
Validator Node Software: Open-source software that validators run to power the network’s consensus. A validator node connects to the Bittensor Subtensor chain and continuously checks miners’ contribution claims. Using the miners’ provided GitHub tokens, the validator software calls GitHub APIs to list the miners’ merged pull requests on the recognized repos. It then scores each miner (e.g. based on number of merged PRs, potentially the significance of the changes, etc.) and submits those scores to the blockchain’s consensus mechanism (likely using Bittensor’s Yuma consensus paradigm adapted for this task). The validators collectively decide the reward ranking of miners each epoch. In return, validators receive a portion of the emissions (and/or fees) for contributing compute and accuracy in verification.
Supported Repositories List: Part of Gittensor’s build is the curated set of open-source repositories that are being incentivized. Initially, the team has whitelisted a selection of important OSS projects where contributions count for rewards. (For example, these could be popular libraries or critical infrastructure projects – though the exact list is determined by the Gittensor team and can evolve.) The platform likely includes a mechanism to update or expand this list over time (perhaps via governance or the project team’s decisions). This ensures that the rewards target meaningful projects and that validators know which repos to monitor. Miners must contribute to one of these recognized repositories for their work to count.
Web Dashboard and Interface: Gittensor also provides a front-end interface (the official website at gittensor.io) which serves as the user-facing part of the product. This site is described as a “dashboard” for the open-source workforce, suggesting it may display statistics, leaderboards, or status of contributions. It likely allows users to see which repositories are supported (“new repositories” section) and possibly to suggest or vote on adding others. The About/FAQ sections would explain how to participate, and a Community link (possibly to Discord or X) helps coordinate participants. While we did not scrape the full site content, its navigation hints that Gittensor is presented as a platform or service for open-source collaboration (with a UI for tracking progress) rather than just code running in the background. This web component makes the experience more accessible – developers can monitor their contribution rewards and the community can observe the network’s impact on various projects.
Open-Source Code and License: All of Gittensor’s software is open source (hosted on GitHub under the user entrius). The project is released under the MIT License, meaning anyone can inspect, use, and modify the code. This openness is fitting given Gittensor’s mission to support open-source work. The repository shows a typical Bittensor subnet structure (with folders for miner, validator, etc.) and is primarily composed of Python code. Developers can thus contribute to Gittensor itself or even fork it to create similar subnets for other domains, thanks to the permissive license.
Overall, the “product” is not a traditional app but a decentralized protocol plus tooling. Developers interact with it by doing normal GitHub pull requests (no special app needed for that part), and the Gittensor network runs in parallel to track and reward those actions. To participate, one would use the provided Gittensor miner program and have some TAO (Bittensor’s token) for staking or registration fees on the subnet. Then as they contribute code, the system automatically tallies their impact and rewards them in the subnet’s native token (SN74’s alpha tokens). These alpha tokens can be converted to TAO through Bittensor’s dTAO mechanisms or markets, giving the rewards real monetary value. In summary, Gittensor’s build delivers a novel integration between GitHub and blockchain: it’s an incentive platform for open-source development, composed of blockchain smart contracts (in Subtensor) and off-chain infrastructure (clients/validators and a dashboard) working together to pay developers for improving open software.
Gittensor’s “product” is essentially an incentive layer and platform for open-source development, built on the Bittensor blockchain. Technically, it consists of a custom Bittensor subnet (network) with corresponding open-source software that developers and validators run to participate. The core components of the build include:
Bittensor Subnet Logic: Gittensor is implemented as Subnet UID 74 on Bittensor (hence the moniker Subnet 74). The subnet defines a unique incentive mechanism tailored to code contributions, embedded in the Bittensor Subtensor chain. This includes the on-chain logic for registering miners, validating contributions, and minting rewards (alpha tokens) based on the custom reward function. The reward function (open-sourced in the code) quantitatively measures developers’ merged pull requests to determine payouts. In Bittensor terms, Gittensor produces a new kind of digital commodity – instead of AI model responses or data, it produces open-source software improvements, with their value judged by decentralized consensus.
Miner Client Software: An open-source client that developers (miners) run locally. This is typically a Python-based daemon or script (the project is primarily written in Python) that interfaces with both the Bittensor network and GitHub. Miners provide a fine-grained GitHub PAT to this client (scoped to allow read access to their repositories and PRs) and register on the subnet. The miner software monitors the developer’s pull request activity on the approved repositories and interacts with the Bittensor chain to claim rewards when contributions are verified. Essentially, from a miner’s perspective, the “product” is a background agent that turns their GitHub contributions into token earnings automatically.
Validator Node Software: Open-source software that validators run to power the network’s consensus. A validator node connects to the Bittensor Subtensor chain and continuously checks miners’ contribution claims. Using the miners’ provided GitHub tokens, the validator software calls GitHub APIs to list the miners’ merged pull requests on the recognized repos. It then scores each miner (e.g. based on number of merged PRs, potentially the significance of the changes, etc.) and submits those scores to the blockchain’s consensus mechanism (likely using Bittensor’s Yuma consensus paradigm adapted for this task). The validators collectively decide the reward ranking of miners each epoch. In return, validators receive a portion of the emissions (and/or fees) for contributing compute and accuracy in verification.
Supported Repositories List: Part of Gittensor’s build is the curated set of open-source repositories that are being incentivized. Initially, the team has whitelisted a selection of important OSS projects where contributions count for rewards. (For example, these could be popular libraries or critical infrastructure projects – though the exact list is determined by the Gittensor team and can evolve.) The platform likely includes a mechanism to update or expand this list over time (perhaps via governance or the project team’s decisions). This ensures that the rewards target meaningful projects and that validators know which repos to monitor. Miners must contribute to one of these recognized repositories for their work to count.
Web Dashboard and Interface: Gittensor also provides a front-end interface (the official website at gittensor.io) which serves as the user-facing part of the product. This site is described as a “dashboard” for the open-source workforce, suggesting it may display statistics, leaderboards, or status of contributions. It likely allows users to see which repositories are supported (“new repositories” section) and possibly to suggest or vote on adding others. The About/FAQ sections would explain how to participate, and a Community link (possibly to Discord or X) helps coordinate participants. While we did not scrape the full site content, its navigation hints that Gittensor is presented as a platform or service for open-source collaboration (with a UI for tracking progress) rather than just code running in the background. This web component makes the experience more accessible – developers can monitor their contribution rewards and the community can observe the network’s impact on various projects.
Open-Source Code and License: All of Gittensor’s software is open source (hosted on GitHub under the user entrius). The project is released under the MIT License, meaning anyone can inspect, use, and modify the code. This openness is fitting given Gittensor’s mission to support open-source work. The repository shows a typical Bittensor subnet structure (with folders for miner, validator, etc.) and is primarily composed of Python code. Developers can thus contribute to Gittensor itself or even fork it to create similar subnets for other domains, thanks to the permissive license.
Overall, the “product” is not a traditional app but a decentralized protocol plus tooling. Developers interact with it by doing normal GitHub pull requests (no special app needed for that part), and the Gittensor network runs in parallel to track and reward those actions. To participate, one would use the provided Gittensor miner program and have some TAO (Bittensor’s token) for staking or registration fees on the subnet. Then as they contribute code, the system automatically tallies their impact and rewards them in the subnet’s native token (SN74’s alpha tokens). These alpha tokens can be converted to TAO through Bittensor’s dTAO mechanisms or markets, giving the rewards real monetary value. In summary, Gittensor’s build delivers a novel integration between GitHub and blockchain: it’s an incentive platform for open-source development, composed of blockchain smart contracts (in Subtensor) and off-chain infrastructure (clients/validators and a dashboard) working together to pay developers for improving open software.
Gittensor appears to be developed and maintained by a small, dedicated team within the Bittensor community. The GitHub repository lists two primary contributors – Ander (GitHub user anderdc) and Landyn (LandynDev) – as the core developers of the project. These individuals are likely the co-founders or lead engineers of Subnet 74. For example, Landyn is active on social media (X) discussing Gittensor’s progress and roadmap, indicating a leadership role in the project’s direction. Ander and Landyn have built the Gittensor codebase under the GitHub handle “entrius”, which might be the name of their development team or organization. The entrius team not only wrote the smart-contract logic and client software, but also operates the official website and coordinates community efforts.
Beyond the two lead developers, there may be additional community members contributing to Gittensor’s growth (through testing, feedback, or minor code contributions), but no large formal organization is publicly known. Unlike some other subnets that are launched by established companies or academic labs, Gittensor is an open-source initiative driven largely by independent developers. It is not directly affiliated with the Opentensor Foundation (which oversees the Bittensor ecosystem) except for being part of the Bittensor network. However, the project’s goals align closely with Bittensor’s ethos of decentralized innovation and open collaboration.
As of now, Ander and Landyn are the primary points of contact and likely the ones who envisioned the idea of rewarding open-source work through a subnet. They engage with the community via the Bittensor Discord and X (Twitter) to answer questions. For example, they have provided guides for miners and validators in the repo and respond to any technical issues on GitHub. In summary, Gittensor is led by a small expert team (Entrius, comprising at least Landyn and Ander) who are passionate about open-source development, and they are supported by the broader Bittensor community in testing and adopting the subnet.
Gittensor appears to be developed and maintained by a small, dedicated team within the Bittensor community. The GitHub repository lists two primary contributors – Ander (GitHub user anderdc) and Landyn (LandynDev) – as the core developers of the project. These individuals are likely the co-founders or lead engineers of Subnet 74. For example, Landyn is active on social media (X) discussing Gittensor’s progress and roadmap, indicating a leadership role in the project’s direction. Ander and Landyn have built the Gittensor codebase under the GitHub handle “entrius”, which might be the name of their development team or organization. The entrius team not only wrote the smart-contract logic and client software, but also operates the official website and coordinates community efforts.
Beyond the two lead developers, there may be additional community members contributing to Gittensor’s growth (through testing, feedback, or minor code contributions), but no large formal organization is publicly known. Unlike some other subnets that are launched by established companies or academic labs, Gittensor is an open-source initiative driven largely by independent developers. It is not directly affiliated with the Opentensor Foundation (which oversees the Bittensor ecosystem) except for being part of the Bittensor network. However, the project’s goals align closely with Bittensor’s ethos of decentralized innovation and open collaboration.
As of now, Ander and Landyn are the primary points of contact and likely the ones who envisioned the idea of rewarding open-source work through a subnet. They engage with the community via the Bittensor Discord and X (Twitter) to answer questions. For example, they have provided guides for miners and validators in the repo and respond to any technical issues on GitHub. In summary, Gittensor is led by a small expert team (Entrius, comprising at least Landyn and Ander) who are passionate about open-source development, and they are supported by the broader Bittensor community in testing and adopting the subnet.
The Gittensor team has outlined an initial roadmap focused on expanding its impact and refining its reward mechanisms for open-source development. While a full public roadmap document is not yet available, we can summarize the trajectory based on team communications and the project’s current status:
Current Phase – Pilot with Select Repositories: As of now, Gittensor is in a pilot stage, incentivizing contributions to a handful of chosen open-source repositories. According to a team update, the subnet is actively rewarding developers for PRs merged into these select projects to prove out the concept and ensure the reward algorithm works fairly. This phase helps calibrate the scoring system (for example, evaluating how to weight different sizes or types of contributions) and build trust with open-source maintainers. It effectively tests that the network can correctly identify meaningful contributions and distribute rewards accordingly without abuse. (Status: operational – developers are already earning rewards for accepted PRs on the supported repos).
Near-Term Plans – Expand Repository Coverage: Once the initial subset of projects runs successfully, the next step is to onboard more open-source repositories into Gittensor’s program. The team’s goal is to accelerate more OSS projects, so they intend to gradually widen the pool of recognized repositories. This could involve adding popular libraries, frameworks, or any open-source software that would benefit from extra developer attention. In practical terms, the “recognized repositories” list will grow, and validators will be updated to track contributions across an expanding array of projects. The team may set criteria for inclusion (e.g. repository must be active, significant, and align with Bittensor’s mission) and possibly work with project maintainers to integrate Gittensor incentives. During this phase, the dashboard might introduce a feature for the community to suggest or vote on new repositories, making the expansion process more decentralized. (Expected timing: incremental, over the next few Bittensor network epochs or quarters – specific timelines not publicly stated).
Mechanism Refinement: In parallel with scaling up, the Gittensor developers will be fine-tuning the reward function and consensus parameters. For instance, they will monitor if certain behaviors need addressing (like discouraging trivial typo fixes just to earn rewards, or preventing any potential gaming of the system). Adjustments could include weighting contributions by lines of code, complexity, or the importance of the repository. They might also tweak how validator scoring works to ensure honest validation. Bittensor’s flexible subnet design (e.g. support for multiple incentive mechanisms within one subnet) could be leveraged in the future – for example, Gittensor could potentially introduce multiple reward categories (one for code contributions, another for code reviews or issue triage) using separate “mechanisms,” although no such multi-faceted plan is confirmed yet. (Ongoing: improvements will be implemented as the project learns from real-world usage).
Long-Term Vision – Decentralized Open-Source Economy: The ultimate roadmap for Gittensor is to mature into a broad, self-sustaining platform that significantly boosts open-source development across the industry. In the long term, we expect to see Gittensor: support a wide range of OSS projects (potentially hundreds or more), attract a large pool of developer-miners who regularly contribute code, and engage many validators to keep the system honest and efficient. The reward budget (emissions) may be adjusted via Bittensor governance to ensure it remains an attractive incentive as participation grows. Additionally, the team might explore integrations beyond GitHub – for example, supporting GitLab or other version control platforms in the future – to broaden the reach. They will also likely work on outreach, getting more open-source maintainers onboard with the idea that contributions to their projects can earn contributors crypto rewards (this could involve education and partnerships). (Timeline: long-term and open-ended – dependent on community growth and Bittensor’s overall evolution).
No Fixed Dates Yet: Because Gittensor is a cutting-edge initiative in a decentralized setting, the roadmap is driven by iterative development and community input rather than fixed deadlines. The team has not published a detailed timeline or quarter-by-quarter plan in our sources. Instead, progress is communicated via community channels (such as Discord and Twitter/X posts by the developers). Milestones – like adding new repositories or updating the scoring algorithm – are likely announced informally as they occur. For example, when Gittensor first launched, community members on X welcomed “Subnet 74: Gittensor” and shared excitement about its purpose. Going forward, similar announcements will accompany major updates (e.g., “Now supporting 10 new projects” or “Version 2 of the reward model deployed”). Stakeholders in the Bittensor ecosystem will also watch Gittensor’s performance (e.g., how much development activity it generates, the value of its alpha token, etc.) and that feedback could influence its future direction.
In summary, Gittensor’s roadmap starts with a cautious rollout on a few repositories, then plans to scale up and refine. The vision is to turn Subnet 74 into a robust marketplace for open-source development labor, where any important open-source software can tap into decentralized incentives to drive its growth. As the project is still young, we will have to stay tuned to official updates for specific roadmap details. What is clear is the ambition: grow the open-source workforce and make contributing code financially rewarding at scale. Gittensor is poised to evolve rapidly in service of that mission. (If more formal roadmap information becomes available – for instance, a published document or blog post – it would likely be added to Gittensor’s FAQ or the Bittensor documentation in the future.)
The Gittensor team has outlined an initial roadmap focused on expanding its impact and refining its reward mechanisms for open-source development. While a full public roadmap document is not yet available, we can summarize the trajectory based on team communications and the project’s current status:
Current Phase – Pilot with Select Repositories: As of now, Gittensor is in a pilot stage, incentivizing contributions to a handful of chosen open-source repositories. According to a team update, the subnet is actively rewarding developers for PRs merged into these select projects to prove out the concept and ensure the reward algorithm works fairly. This phase helps calibrate the scoring system (for example, evaluating how to weight different sizes or types of contributions) and build trust with open-source maintainers. It effectively tests that the network can correctly identify meaningful contributions and distribute rewards accordingly without abuse. (Status: operational – developers are already earning rewards for accepted PRs on the supported repos).
Near-Term Plans – Expand Repository Coverage: Once the initial subset of projects runs successfully, the next step is to onboard more open-source repositories into Gittensor’s program. The team’s goal is to accelerate more OSS projects, so they intend to gradually widen the pool of recognized repositories. This could involve adding popular libraries, frameworks, or any open-source software that would benefit from extra developer attention. In practical terms, the “recognized repositories” list will grow, and validators will be updated to track contributions across an expanding array of projects. The team may set criteria for inclusion (e.g. repository must be active, significant, and align with Bittensor’s mission) and possibly work with project maintainers to integrate Gittensor incentives. During this phase, the dashboard might introduce a feature for the community to suggest or vote on new repositories, making the expansion process more decentralized. (Expected timing: incremental, over the next few Bittensor network epochs or quarters – specific timelines not publicly stated).
Mechanism Refinement: In parallel with scaling up, the Gittensor developers will be fine-tuning the reward function and consensus parameters. For instance, they will monitor if certain behaviors need addressing (like discouraging trivial typo fixes just to earn rewards, or preventing any potential gaming of the system). Adjustments could include weighting contributions by lines of code, complexity, or the importance of the repository. They might also tweak how validator scoring works to ensure honest validation. Bittensor’s flexible subnet design (e.g. support for multiple incentive mechanisms within one subnet) could be leveraged in the future – for example, Gittensor could potentially introduce multiple reward categories (one for code contributions, another for code reviews or issue triage) using separate “mechanisms,” although no such multi-faceted plan is confirmed yet. (Ongoing: improvements will be implemented as the project learns from real-world usage).
Long-Term Vision – Decentralized Open-Source Economy: The ultimate roadmap for Gittensor is to mature into a broad, self-sustaining platform that significantly boosts open-source development across the industry. In the long term, we expect to see Gittensor: support a wide range of OSS projects (potentially hundreds or more), attract a large pool of developer-miners who regularly contribute code, and engage many validators to keep the system honest and efficient. The reward budget (emissions) may be adjusted via Bittensor governance to ensure it remains an attractive incentive as participation grows. Additionally, the team might explore integrations beyond GitHub – for example, supporting GitLab or other version control platforms in the future – to broaden the reach. They will also likely work on outreach, getting more open-source maintainers onboard with the idea that contributions to their projects can earn contributors crypto rewards (this could involve education and partnerships). (Timeline: long-term and open-ended – dependent on community growth and Bittensor’s overall evolution).
No Fixed Dates Yet: Because Gittensor is a cutting-edge initiative in a decentralized setting, the roadmap is driven by iterative development and community input rather than fixed deadlines. The team has not published a detailed timeline or quarter-by-quarter plan in our sources. Instead, progress is communicated via community channels (such as Discord and Twitter/X posts by the developers). Milestones – like adding new repositories or updating the scoring algorithm – are likely announced informally as they occur. For example, when Gittensor first launched, community members on X welcomed “Subnet 74: Gittensor” and shared excitement about its purpose. Going forward, similar announcements will accompany major updates (e.g., “Now supporting 10 new projects” or “Version 2 of the reward model deployed”). Stakeholders in the Bittensor ecosystem will also watch Gittensor’s performance (e.g., how much development activity it generates, the value of its alpha token, etc.) and that feedback could influence its future direction.
In summary, Gittensor’s roadmap starts with a cautious rollout on a few repositories, then plans to scale up and refine. The vision is to turn Subnet 74 into a robust marketplace for open-source development labor, where any important open-source software can tap into decentralized incentives to drive its growth. As the project is still young, we will have to stay tuned to official updates for specific roadmap details. What is clear is the ambition: grow the open-source workforce and make contributing code financially rewarding at scale. Gittensor is poised to evolve rapidly in service of that mission. (If more formal roadmap information becomes available – for instance, a published document or blog post – it would likely be added to Gittensor’s FAQ or the Bittensor documentation in the future.)