Infusing POKT DNA with Open-Source Community Standards

[shane]

Summary

POKT DNA emphasizes that POKT aims to be an “open” community with “transparent” operations

@b3n

We strive to be:
A values-driven, collaborative, open-source community that is transparent, inclusive and adaptable.
We bring our values of community, inclusion, transparency, collaboration and adaptability into our behaviors when we are:
Highly Aligned Loosely Coupled, Assume positive intent, Default to open, Ideas over Egos, Faster Learning beats Better Planning

While this concept sounds noble, its real value manifests when implemented consistently. The other day I voiced concerns on Telegram regarding PNF’s inconsistent enforcement of public repos and development transparency among different initiatives. Instead of dwelling on the past, let’s focus on the future.

I propose that if the DAO funds development, the process should be conducted openly, complete with public repositories. Public development is pivotal in open-source culture. The POKT DNA should mandate public development, and PNF should ensure unbiased enforcement.

Abstract

Many equate “open-source” with publicly accessible code. However, in the FLOSS (Free/Libre/Open Source Software) culture, it also implies that the development process is transparent and trackable through Git versioning. Git’s strength lies in its ability to chronicle software development progress, fostering participation. Github, built on Git’s foundation, has become one of the most popular tools in software history because of this transparency.

To genuinely classify POKT as an “open-source” project, its development must be transparent. While many POKT components, like the Shannon development, embrace open-source principles, others do not develop with public repositories. For POKT to thrive with external contributions, a consistent definition of “open-source” is essential. Inconsistent practices, where PNF mandates transparency for some but not for others, especially when both are DAO-funded, is not tenable.

This proposal seeks to clarify and standardize the definition of “open-source” within the POKT ecosystem.

Rationale

Here’s a guideline for POKT and PNF:

To qualify for DAO development funding, a project should have previously established public repositories, mirroring the Sockets’ requirements. While there could be exceptions, they must be explicitly presented to the DAO. Git’s versioning system should be the default, setting the standard for public development and determining the conditions for DAO fund allocation.

PNF must impartially uphold this requirement for any project seeking DAO development funding. Projects funded via an RPG (Retroactive Public Good) should make their repositories public, including the Git version history, before obtaining funds.

I welcome feedback from both PNF and the POKT community. The objective is to create a standard ensuring equitable treatment of all developers.

Dissenting Opinions

This is merely adding bureaucracy.

Contrarily, inconsistencies in POKT’s open-source requirements will breed more bureaucracy and drama. This proposal doesn’t add to PNF’s workload; it merely requires projects to make their repos public before funding. PNF already demands this for Sockets, so this just extends that requirement to all DAO beneficiaries.

POKT didn’t mandate this earlier; it shouldn’t now.

Pocket has evolved significantly since its mainnet launch in August 2020. Initial proposals weren’t always fully open-source, but they met their deliverable goals. Today, POKT is a maturer ecosystem without the same risks for early contributors, and the ecosystem has grown to fully rely on open-source principles for it’s progress. While the POKT DNA captures the spirit of open-source culture, its implementation has been inconsistent, underscoring the need for clarity.

This will stifle support of projects that are not open-source.

If PNF believes that a project deserves DAO funds despite not adhering to open-source principles, they should clearly communicate this stance. This proposal doesn’t necessarily reverse previously made decisions, like the funding of POKTScan. Instead, it emphasizes a consistent standard for all DAO-funded open-source initiatives.

Public development isn’t crucial if the final code is eventually accessible.

To non-developers, public development might seem trivial. But for developers, tracking commit history is vital for understanding coding decisions. While some projects, like Uniswap, prefer private development followed by restricted open-sourcing to guard against imitation (e.g., SushiSwap), this approach isn’t universally accepted and has faced criticism.

POKT operates differently from monolithic structures like Uniswap. It benefits from being an entirely open-source initiative where everyone can contribute and learn. If POKT were to allow some initiatives/companies to develop in private with DAO resources, then it opens to door to competitive advantages or lack of accountability. Competitive advantages are neutralized when the development is public and transparent. Projects funded by the DAO shouldn’t erase their development histories as well, and there’s little justification for DAO-backed projects to be non-transparent.

[RawthiL (Ramiro | POKTscan)]

I think this is a fair thing to ask, the only difference with today’s procedure is that you want to enforce open development as a default?
In the telegram you talked about NodiesDLB, they will make the founded module open source as per their agreement with the DAO, the only difference I see here is that they are not developing it in the open. Is there any other example?

[shane]

@RawthiL

you want to enforce open development as a default?

Yes, which is what POKT DNA already establishes in spirit, but doesn’t explicitly define. If something is said to be “open-source”, then we operate within a standard definition which means the development itself is open.

@RawthiL

In the telegram you talked about NodiesDLB, they will make the founded module open source as per their agreement with the DAO, the only difference I see here is that they are not developing it in the open.

The agreement specifically sounded like open development, with all the references to “open-source”, “collective knowledge”, Gateway Office Hours, POPs, Community Developers, Community members - Provide input and comment on this project, including supporting Nodies with feedback and testing of their gateway. Everything in that agreement sounded like the development itself would be open collaborative. To say otherwise would be negating the clear spirit of the post and relying on subjective verbiage technicalities, which is not a healthy way for a DAO to operate. This is why an explicit definition is now important.

Grove in the past has been publicly criticized numerous times for not having an open-source culture where collaborators could contribute. With the start of Shannon, much of that changed, but that change hasn’t carried to others initiatives in the same way.

@RawthiL

Is there any other example?

There is a positive example, and it is the Shannon initiative. Ironically, I wrote the original gateway spec, which the Shannon team fully embraced in a collaborative spirit, however the gateway implementation in Morse has not been collaborative or open to the outside.

Many would argue that Morse’s development is a past example of not doing it right. All other DAO funded initiatives today are small POPs or Sockets, which each have their own requirements (Sockets are the smallest yet actually require the most amount of transparency).

Shannon and the gateway initiative are the only large ticket development projects within the ERA budget, and both were presented as collaborative and open in nature. Since Shannon is a model of true open-source, where the development is open, we should adopt that definition of “open-source” and apply it anywhere DAO funds are used.

[shane]

I brought some concerns today to PNF since the OS-Gateway was released via a new repo that was created on Thursday. I find this disappointing that again, a tool funded by the DAO, is being released without the development history included.

This is what I shared with PNF, from my understanding

It sounds like at first it was integrated into their closed-source code… then they started building it as a standalone repo, then they transferred the code from the standalone repo to a new repo on Thursday for release.

The thing is… this looks like a solid tool. It’s clean, it’s simple, and seems to be well made. It’s built to programmatic usage (not just a bunch of config files you have to edit). Changing repos for release is annoying and why I’m mentioning it.

I don’t agree with this practice and believe that POKT should have established requirements, that are specific, moving forward. I believe PNF is in agreement, but I again wanted point out that this practice is the antithesis to transparency and open-source, and I feel like we should have an ecosystem wide definition of what open-source means.

[b3n]

Thanks @shane for starting up this topic and for the desire to keep iterating on clarity around our DNA.

DAOs are as much a social contract as an autonomous system built on blockchains. That social contract generally evolves with the energy of the community. The idea listed here is something we probably all broadly agree on and in some ways is trying to litigate on a lesson that has already been taken by the people involved. I think the best course of action is to take that lesson and assume positive intent that we will make the right adjustment, without having to codify things in real time.

Ultimately I lean towards rough consensus. If people felt this was something that needs to be codified then I’d expected to see more support (via seconding and adding and liking). Given there hasn’t been much engagement, my interpretation is that people trust PNF to set clearer expectations when operating DAO funds in future, or they don’t think it’s a big deal.

But that’s just my interpretation. If people now want to add their support to this type of action - great! Here’s your chance.

And fwiw if that does happen, a proposal probably isn’t needed anyway. The social contract is an incredibly important part of how we try to steward the project, and 50 thumbs up in support for this topic would be enough for PNF to pick it up and carry it forward, whether it’s a formal proposal or not

[shane]

Thanks @b3n. If some funding initiatives are required to be developed in public with normal public repos, then I believe on a social contract level it would be easier to just make it a universal standard. For me the confusion is coming from having different standards for different teams, which is why it would make more sense to just have a simply defined social contract standard.

I’ve already communicated to PNF our challenges with the wallet because knowledge was lost from using new repos, so my intent is not to have ill will towards PNF, Nodies, or anyone else. We’ve had to cross this bridge before with other repos, and it’s just not fun.

I’d prefer just to have a unified social contract where everyone knows what to expect across any POKT initiative… and then build great stuff