[Discussion] PGF priorities for software in Namada

PGF Ops
1

As a community, we can use PGF to incentivize and reward people for software that improves Namada. Anyone seeking NAM or hoping to be rewarded with NAM for software, tooling, products–anything involving code–should know what to expect.

Open-source developers are taking a big chance when building in our emerging ecosystem. I’m excited to take risks with PGF by advocating for bold bets over bureaucracy. I believe we’ll be more effective and see greater returns by taking risks, fully expecting that some of our bets will fail. And when it comes to software, I think we should prioritize focusing our PGF resources/attention on open source developers over closed solutions.

tl;dr
We should prioritize funding open-source tools because they stay valuable to the Namada community even if the creator steps away. Closed solutions may be acceptable in critical cases, but we should minimize reliance on them.

Open-source tools should be useful, well-documented, publicly accessible, and easy to maintain. Closed solutions should be considered case by case, avoiding vendor lock-in, preferring decentralized or community-run alternatives. How do we ensure open-source contributions are sustainable and properly recognized? Would love to hear insights from those experienced in OSS!

Open-Source Tools vs Closed Solutions

We should incentivize/reward the production of open-source tools as a priority, because anyone can use, modify, and keep it going in the absence of the creator. Having to rely on the creator to use or build on closed solutions decreases the value proposition if the value is mostly lost when the creator exits.

If we prioritize rewarding open-source tool production, we can help ensure longevity and permissionless innovation, allocating NAM for services only when necessary and avoiding dependency upon centralized entities.

Some open-source tool evaluation criteria

:small_blue_diamond: Alignment - with Namada’s values, development goals, mission, vision

:small_blue_diamond: Fundamentally useful - provides lasting value to our ecosystem/community

:small_blue_diamond: Public repo - hosted on an accessible platform, eg Github

:small_blue_diamond: Open source licencing - MIT or Apache 2.0

:small_blue_diamond: Clear docs - setup, usage, and contribution guidelines

:small_blue_diamond: Maintainable & extensible - code is structured for easy updates, improvements, collaboration, minimizes dependencies upon closed systems & prioritizes decentralization

:small_blue_diamond: Collaborative, transparent development - major stuff happens openly, encourages collaboration from community

:small_blue_diamond: Security best practices - particularly for software interacting with core Namada systems, eg wallet interfaces

Does this criteria feel right? Would you add or change anything?

Closed-solution services & products

Beyond prioritizing open-source tools, some critical services require ongoing operation, and we should evaluate them case by case. Sometimes a more ideal solution is just not available.

While I hope that we will take risks on open-source tooling initiatives, I think we should consider closed solutions more carefully. How do we ensure we aren’t over-reliant on closed solutions while still being pragmatic?

:small_orange_diamond: Decentralized or in-house alternative - is there a decentralized version of this service that is suitable? can this be community-run instead?

:small_orange_diamond: Avoid lock-in - ensure access guarantees, portability, and have a transition plan to an open alternative

Concerns about open-sourcing

While open-source tools allow for permissionless innovation, sustainability and fair recognition are challenges we’ll need to address.

If you have experience with software development, in particular OSS, it would be great if you could weigh in with your experience and/or some feedback. It would be ++helpful for people aligned with OSS values, but inexperienced with the OSS game, and want to make good decisions.

  1. How do you do open-source work sustainably? and get appropriate recognition?

  2. How do you deal with the potential for others to use these contributions to profit without giving back?

Would love to hear thoughts from those who have been through this—what worked, what didn’t, and what you’d recommend to others getting started in OSS. tagging @cwgoes @Fraccaman

2 Likes
2

Docs

What kinds of docs will our community need for open-source tooling? I asked chatgpt for some help to outline:

README – what it does, why it matters, how to use it

Setup guide – step-by-step installation and configuration

Contribution guide – how to contribute, coding standards, issue tracking

License – clearly state the open-source license (MIT, Apache 2.0, etc)

API/usage reference – key functions, endpoints, commands

Maintenance notes – basic guidance on how others can keep it running

2 Likes
3

Really happy to see this effort! A few thoughts:

I think a pretty solid approach can be modeled after the one we’ve taken so far with Namadillo, where:

  1. One party or set of parties (for Namadillo, historically Heliax) builds the software product, including most of the code required to host an instance easily (so that hosting an instance doesn’t require any expertise specific to the software product), and
  2. Anyone who wants to can host the server-side services (Namadillo has nearly a dozen hosts or so the last time I checked).

To me this is still lacking in a few aspects, but they seem possible to improve:

  1. I think it can be difficult for users to know where to go when there are many instances which might have different versions.
    • This could be alleviated with a community-maintained list of “well-known hosts”, automatic version checking, and perhaps even a single DNS name that randomly selects a backend from that list.
  2. Hosting server-side services is not directly compensated (and who wants to host them might be correspondingly unreliable, since there’s no implied or enforced SLA).
    • For now, this doesn’t matter too much for Namadillo, since the cost of hosting is pretty low.
    • It might matter more in the future for Namadillo (as user requests grow), and moreso for other services which require more server-side resources (e.g. the future shielded state sync which requires running TEEs).

In my experience, this is mostly a challenge of building the right culture around OSS (and contributions more generally, the value of which is often hard and/or counterproductive to capture), where we as a community recognize the value of these contributions and act periodically to reward those who have devoted their time and resources to creating them.

There will always be “free-riders” who use OSS software to profit without giving back, but personally I think trying to fully eliminate free-riders is mostly a distraction and not worth the time. A license like GPL can help a little bit (ensuring at least that code which uses your code is also open-source), but all custom attempts that I’ve seen (e.g. Zcash’s “BOSL” license), despite good intentions, have spent years wasting time on complex legal maneuvering to allow uses they want (e.g. this), and in general they’ve eventually given up (as was the case for BOSL). The legal system is complex, engaging with custom licenses is seen as a risky proposition, and even modulo those problems it’s simply hard to fully specify a priori which uses of your code are “good” and which are not.

Rather, I think it’s more worth devoting time to crafting processes and rituals to reward contributions. Some ideas:

  1. Craft a basic set of templates (could be JSON, nothing fancy) where:
    a. Project authors can put a tnam/znam address in their repository in a standard location.
    b. Project authors can also put a list of their most important dependencies and how valuable they think those dependencies were to their project.
    - This could possibly be replaced with automated analysis.
    c. Periodically, the Namada community starts with the most important software products used by the community (e.g. the Namada node, Namadillo, future wallets, future tools, etc. - the end-user products), traces back the dependency graph using this data, and allocates some PGF funding to dependencies in accordance with how critical they are to these products. The statistical analysis here can be iterated upon (investigating something PageRank-like would be interesting), but we can start simple.

    What I like about this idea is that - executed well - it would reward OSS contributions based on how valuable they ultimately are to Namada users and the Namada community at large.

  2. Host a regular “community software spotlight” session where rotating presenters from software developers in the Namada community present the latest state of their work, all the way from design ideas to where the docs are. Community stewards can help connect developers to resources they might need elsewhere in the community, be those expertise, hardware to test their software, users to do QA, etc. These presentations can include a tnam/znam so folks can donate to support the work, but to me this idea is primarily about social recognition, not financial support (and I think social recognition is equally important).

1 Like
4

There are dozens of Namadillo instances but still only one community custom made Namada UI built by us Cosmic Validator in collaboration with the OmniFlix team (https://namada.omniflix.co). I remember you mentioned Chris that usually the original UI/wallet of a project like Lunie in Cosmos doesn’t become the leading one.
Hosting Namadillo instances doesn’t have high costs or efforts hence why there are dozens of them, in contrast developing a custom made UI takes a lot of efforts and work of professional devs and we had 0 compensation for this and financed all ourselves. Moreover, we are planning to create with Daniel and Tududes the most advanced MASP metrics dashboard for Namada to be integrated also in our UI. Since we are discussing PGF priorities here, it is sad, surprising and a bit dissapointing that all this work keeps getting overlooked

1 Like
5

This sounds awesome! To be clear, I definitely think that Namada PGF should support the development of different wallets. I understood @Gavin’s original post as an attempt to lay out a framework for evaluation rather than one to evaluate individual projects - easier to agree on a framework first, then evaluate the specific cases - I’ll leave it to him to clarify any additional context there, but I wouldn’t read this as overlooking any specific work, I think it’s just a structured procedure.

3 Likes
6

I think it can be difficult for users to know where to go when there are many instances which might have different versions.

Laconic can enable us to release a new version of Namadillo to be hosted quickly in a verifiable, distributed way, and it works today. those hosting Namadillo can become Laconic Laconic service providers, and we will be able to reward them with NAM using Laconic and IBC

Zach (Laconic) registered Namadillo for us: app type · zramsay/namada-interface@f19317c · GitHub

image
image1142×428 80.3 KB

took about 30 mins to get running: https://namadillo.apps.vaasl.io/

the Namadillo team has been included in the conversation and we’re going to discuss next steps

Rather, I think it’s more worth devoting time to crafting processes and rituals to reward contributions.

agree! thanks for sharing these ideas!

Luminara, specifically @CryptoDruide, is making a system for tracking and indexing projects and contributors. the idea is to balance having a directory for Namada apps/tools and having a contributor profile. ideally the latter can be used to help inform delegation decisions as well (so project authors should also include their validator address in their profile), and there can be fun ways to advertise/celebrate contributors in the former (to remind users how what they’re using was made)

but the dependency graph idea is new to me :bulb: and love this idea. so often the end-user app is recognized, but the dependencies (like ethersjs) are not. would this review be a kind of audit? feels like something @Rigorous or @preto would want to be tagged about

does it make sense to ask project submitters to list dependencies? thinking about @CryptoDruide’s work and wondering what can be front-loaded and how early we should begin doing it

Luminara will focus on building recognition for contributors and their contributions within and beyond our community. advertising these to the broader space builds our contributors’ reputations and makes Namada attractive to new contributors as a place where stuff is actually happening :fire:

3 Likes
7

this is a correct understanding, and i think Hector knows that too :wink:

2 Likes
8

re dependencies, not sure exactly what the term dependency graph implies, but assume it’s another way of saying we will aim to reward all base building blocks the software depends on. very much in favor of this. however not all software is done in neatly packaged frameworks etc, depends on which tools / methods are used. also very much in favor of OSS focus. Re recording contributions, I feel there is a tension between Namada’s data protection focus and wanting all contributions registered in an open repo (as basis for rewards?). Ironically it feels very non-data-protection-like. (just a few stray thoughts, I don’t check the forum as often as I maybe should)

3 Likes
9

As for the reliability of open source projects, that is indisputable. I was thinking about this myself when I was unable to work properly for a few weeks recently, for reasons beyond my control. everybody’s mortal, everybody can have something unanticipated happen in their lives.

There is no doubt that opensource is a great building material for new projects.

As far as our work is concerned - since explorer grew out of petproject for SE and we started it without having the right competencies. Moving to Opensource is a separate big job. Taking everything and rewriting it. I’m not sure if I can do it myself. For sufficient time/quality ratio.

So far, I have more questions)
Hopefully non opensource projects will get some support too. Especially since it can be used to move to opensource.

2 Likes
10

Hmm, what tensions do you see here? Open source software does indeed need to be public in order to qualify for rewards like this - that’s true - but it also needs to be public in order for anyone to use it in the first place. Closed-source-code software just isn’t a public good, I don’t really think that we should reward it (not with this method at least - products which rely on some closed-source software can still be public goods, but that would require a different mechanism). The only addition required from the software author in order for this dependency graph traversal allocation approach to work would be a znam address, they don’t need to reveal other identity information.

1 Like
11

thanks for sharing, i’m glad you did!

do we know of any open source explorers? @kwunyeung and Terence open sourced Big Dipper, but i suspect that this is a rare exception

1 Like
12

Re recording contributions, I feel there is a tension between Namada’s data protection focus and wanting all contributions registered in an open repo (as basis for rewards?). Ironically it feels very non-data-protection-like.

@preto, i get that some folks want to stay completely private, but i think we need to reveal some elements of ourselves to coordinate effectively, and especially so in order to effect change. the theme of revealing to coordinate is the inspiration for Luminara’s namesake. i like how it’s visualized in Nicky Case’s work

fireflies likely get eaten bc they light up, but revealing themselves is evidently still a net positive evolutionarily :upside_down_face:

Closed-source-code software just isn’t a public good, I don’t really think that we should reward it (not with this method at least - products which rely on some closed-source software can still be public goods, but that would require a different mechanism).

@cwgoes, are you thinking that we shouldn’t use this issuance for products/services that are not open source?

personally I want Namada’s community to flourish as a public goods funding culture, but i’m inclined to advocate that we shouldn’t be too strict about using this issuance purely for public goods (despite it being called so in the code, specs, and docs). it could be important to our mission to use our issuance to reward/incentivize products and services (mentioned above), and this issuance is ostensibly the most community-controlled form of funding

2 Likes
13

Ah no, perhaps I wasn’t clear - I totally agree that the remit of PGF should be broader, all I meant to say is that the dependency graph mechanism which I propose above only really works for open-source software.

2 Likes
14

I may have been addressing something a little tangential to the discussion. My remarks were more made towards the repos of “all contributors” we are making, not so much the dependency graph mechanism being discussed. (I agree open source is the way to go and what we should be rewarding, however the mentioned repos recording contributions also deal with other things such as infra support etc)

1 Like
16

This +

Also, we could aim at allocating a part of the inflation rewards for open source projects or part of the CP. These funds can be then redistributed, if criteria is met, at any given rate via onchain governance.

I also think that if projects want to fund from Namada, then Namada should fund carefully. I might be shooting myself in the leg here, since we are such a project, yet I believe this is important.

I think that it makes 0 sense to fund a team 350K USD for their whatever. Communities should fund projects in parts, as the code gets released. Every project knows well its spending. If a project requires 300K for 2 years, it shouldn’t be funded 100% by the community in question (Namada in this case). Funds should be released to cover monthly (maybe 2) expenses. It should be up to those projects to find diversification of income (that would also show project development and demand). Dont forget we live in a cross chain world. And projects are fit to fund in many foundations simultaneously, which is what they do.

If a project is focused solely on Namada, even further, they dont need more funds that they can spend in a short period of time.

2 Likes
17

Hello Friends,

After reading the above, I have a few recommendations for enhancing the Namada Public Goods Funding program, mainly centering on implementing a structured tiered funding approach that would clearly differentiate between experimental projects requiring minimal oversight and substantial initiatives deserving more rigorous planning and community accountability.

I bring these suggestions because my firm has first-hand experience implementing similar grant structures through our technical work within a major L1 Foundation’s grants program, and we’ve seen how properly aligned incentives dramatically improve completion rates and long term chain sustainability. We have experience establishing appropriate evaluation metrics, conducting technical reviews at key milestones, and implementing verification systems to balance rigor with devex.

Therefore, I suggest a tiered grants model in a dual system which would address varying project scales and needs. For small grants, the model would draw inspiration from successful regional ambassador programs with locally-focused “Namada Builders” chapters operating autonomously within allocated budgets. These chapters could handle streamlined/short form applications with quick review cycles while maintaining accountability with milestones.

For medium and large grants, the model would adopt a more formal governance structure with a balanced committee comprised of core contributors, ecosystem experts, and community representatives. This committee would oversee four strategic funding categories targeting core infrastructure, developer ecosystem growth, user experience improvements, and research innovation.

My suggested disbursement framework is designed to align incentives with technical delivery and adoption success:

  • For a 50% milestone completion disbursement, recipients should demonstrate a fully functional and usable v1.0 deployment on the Namada mainnet. This would include all core MVP functionalities as explicitly defined and agreed upon during the grant approval process. Technical reviewers will verify that the deployment meets security standards, functions as specified, and provides appropriate documentation. This ensures funds are only released once tangible, working software exists on-chain.

  • The final 50% disbursement could be contingent on meeting predefined adoption (and documentation?) metrics that vary by project type. For infrastructure projects, these metrics might include number of active nodes, uptime percentages, or processing volume. For user-facing applications, metrics would focus on daily/monthly active users, transaction volume, or retention rates. For developer tools, adoption could be measured through KPIs such as integration counts, active developer usage, or contribution activity. These metrics would be established at the outset with reasonable thresholds based on ecosystem maturity to create clear success criteria beyond just deploying the code.

This structure would ensure the grants program transforms the funding of development effort to funding actual ecosystem impact and ensure Namada rewards both creation and adoption of public goods–This approach would hopefully balance the need for funding innovation while ensuring accountability.

Your thoughts and ideas are always welcome.

Jackie

3 Likes
18

Great suggestions. The tiered system allows for tailored support, streamlining small grants while ensuring rigorous oversight for larger projects. This structured approach can lead to higher completion rates and better use of funds.

3 Likes