Projects funded via xGov should be open source

Governance
1

As community is deciding on funding a project, it should always be open-source

  1. Future developers will get a reference for easier development.
  2. Some portions of the code can be closed source (but it has to be mentioned in the proposal)
  3. Smart contracts can be verified by developer community for potential errors of vulnerabilities.
  4. The developer activity matrix on algorand will get a good boost.
10 Likes
2

I concur. Some cautions and restrictions should/could apply. Maybe open source it after the first year upon launch, Or gradually. Something like that. Completely open from the start could be harmful for new/innovative ideas and for the funding itself.

7 Likes
3

I support this proposal totally.
One thing that has to be kept in mind is that Grants are literally free handouts governed by Algorand holders. The program isn’t meant to replace typical funding and if a projects comes to ask for grants it should do it embracing its effort as part of developing the ecosystem further and not only its own project.

4 Likes
4

In general I think open source code should be encouraged, but not mandatory if good reason not to do so. Like you said.
For example bridges shouldn’t be open sources for security reasons. Maybe after years when code is proven to be absolute robust and no hacks in years. For example wormhole and other major bridges have experienced hacks despite multiple audits and huge development teams.

Regards,
ROAM

4 Likes
5

Absolutely agree.

Anyone getting a grant needs to open source all their codes.

Maybe not straight from the get go, or maybe not all the codes, etc but eventually all of it needs to be open sourced if it can be open sourced.

I’ve heard they could be some security breaches if everything is fully open sourced for certain Dapps.

But otherwise, everything else needs to be open sourced.

if you ain’t going to open source it right away and plan to open source it say after a year, someone within the foundation needs to still have access to all the codes while it’s in closed source/development mode.

2 Likes
6

My concern with applying that restriction (as someone who has created both open & closed-source Algorand products over the years) is:

  1. If the Algorand ecosystem benefits from the existence of a product - OSS or not - then value is being delivered back to the ecosystem commensurate with the grant funding.
  2. OSS-only sets limits on the “will of the people”. If people want to vote for a closed-source proposal and fund it, then so be it. If they don’t, then their decision will be made known in the voting booth. But the bottom line is there should be equality of access in which the people ultimately decide.
  3. It’s not just the product that is being funded in a proposal, but the time & expertise of the individual/team which could easily be applied elsewhere, to other companies, to other chain technologies, etc.
  4. Devs need to eat. @grzracz hinted at this on the Build-A-Bull championship live-stream that it’s hard to find&pay for Algorand blockchain devs. It’s an immature notion that a quality product can be done basically for free, on a shoe-string budget, and then all of the IP has to be given away for free as well. That’s nonsense and no quality engineer/team is jumping at that deal. Even with the most popular OSS products out there the engineers/teams usually end up funded on Patreon, via consulting arrangements, etc.
7 Likes
7

Encouraged yes. Mandatory no.

3 Likes
8

I agree on this point. A different approach would include signing a contract for a moderately long period of time that requires the grant taker to continue supporting the product if they don’t want to open source it (in order for the community to still be able to use it) - and if they don’t want to, they can forfeit that obligation with open source.
A period like 2-3 years would ensure that the grant money is well spent (there will be a product Algo community can use) and it will either be run by the person who made it without making it OSS (so they can earn revenue on it) or it will be something someone else can pick up and run themselves.

6 Likes
9
  • tooling proposals funded by xgov 100%.
  • requiring any software to be open source is not viable unless you wish to prevent majority of innovative ideas being kickstarted via xgov funding - first mover advantage in thsi space is a big thing, forfeiting that is not an option for any proejct looking to be profitable/sustainable in the near future.
6 Likes
10

If the idea is such a big leap that the devs really don’t want to have open source for the sake of market advantage then the funding should come from private funding. Ecosystem funding should be an incentives for the ecosystem sake, otherwise we end up circling back to projects asking for grants on project that may vanish because 1) granted request upfront 2) launch wasn’t successful. The xGov grant wouldn’t be enough either way.

It’s an immature notion that a quality product can be done basically for free, on a shoe-string budget, and then all of the IP has to be given away for free as well.
And:
Even with the most popular OSS products out there the engineers/teams usually end up funded on Patreon, via consulting arrangements, etc.

Why wouldn’t the situation be solved with 1) higher grant request (ask for how much you are willing to work for) and 2) provide consulting and other systems to gather funds with?

2 Likes
11

Yup this makes perfect sense.

If the dev is willing to sign a contract to prove he is fully vested in developing the dapp for the algorand community then it’s fine.

last thing you want is for a dev to build, get paid, and then dip or blackmail the foundation and community to buy the rights or source code back.

If you get a grant - you are fully vested into growing the algo ecosystem. If you want to leave, then you need to open source the code right away and then you can bounce. This way every party wins.