Skip to content

Instantly share code, notes, and snippets.

@yrashk
Last active February 10, 2022 04:04
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save yrashk/54d57c3cd11f9579880b862814f0746e to your computer and use it in GitHub Desktop.
Save yrashk/54d57c3cd11f9579880b862814f0746e to your computer and use it in GitHub Desktop.
OSS Token

Open Source Software Token[s]

The idea behind this is to research and experiment with "smart contract" funding for open source and free software.

  • Allow less-known developers / projects to earn the public's trust ("cautious funding" — helping them build a reputation of being able to deliver; mechanisms may vary. could be based on bounties [see below] or funds release confirmations if bounties are not suitable for any reason... or something else entirely)
  • Allow direct organization/person funding (simple token transfer)
  • Allow funding specific goals (bounties)
  • Allow branding [sub]tokens for a specific project (bragging, voting, other kinds of rights)
  • Allow continuous support pledges (recurring payments)
  • Allow nominees to exchange tokens for the amount they were originally bought for (backed by ETH, the funding is deposited through an ICO, or a series of offerings)
  • Allow project maintainers and developers to publish their expenses in IPFS and refer to hashes of the receipts

Thoughts?

@bmann
Copy link

bmann commented Jul 4, 2017

Open Collective was starting to think about ICOs / tokens as well.

Aragon allows for the creation of decentralized organizations. Can it be used as-is to create tokens / run OSS orgs?

Or do you want to run some smart contracts / a platform that perform oracle functions around bounties / feature completion?

Defining which parts are needed will help determine which parts of a platform you might build.

Stuff like Gratipay is orthogonal, and yet the "flows" of capital are super interesting.

@xdamman
Copy link

xdamman commented Jul 4, 2017

Yes. We have a #crypto channel on our slack to talk about it. Feel free to join (https://slack.opencollective.org)

The future of open collective is definitely on the blockchain in the same way that the future of Uber/Lyft is with self driving cars. But we need to build a staircase towards that future. That's why we have been focused so far on the well established technologies of credit cards and the likes.

We played with the idea of an open source coin that we could deploy across the 250 open source communities that are already under the open source collective umbrella https://opencollective.com/opensource
Biggest problems that first need to be resolved:

  • what would be the utility of the coin?
  • how do we decentralize the mining of the coin in a way that preserve the total equilibrium? (Would probably involve creating a coin per open source project that would be pegged to the open source coin)

We would love to support experiments that will go in that direction. It's a fascinating topic but there is still so much that needs to be learned. And the best way to do that is to just "do".

@cborodescu
Copy link

I think it's worth looking at http://devcoin.org/ and https://commiteth.com/ for inspiration.

@bmann
Copy link

bmann commented Jul 4, 2017

@xdamman no mining required if it is an ERC20 Ethereum coin unless I am missing something about your usage of the term mining.

Utility is the big one. Pledging support to an individual? Sounds like Patreon. Pledging to a project? Similar to Gratipay.

Which doesn't mean one can't build similar things, just have to think about what a decentralized version looks like & what lessons those other systems have already learned.

@neilk
Copy link

neilk commented Jul 4, 2017

It feels like there's something that can be done with ETH or the blockchain here, but I'm not sure what.

I have doubts about bounties for open source though. It's tried many times before with fiat currency and it hasn't worked out. At best, you get random feature requests, way underpriced. Hardly anyone is aware the bounties even exist. Even when they do know it exists, most users can't make an informed judgment about what to fund. It's not a great way to fund a long-term roadmap, even though it could provide some cash.

However, all the previous bounty programs were third-party. Maybe it would be different if there was an Open Collective type organization which embedded bounties deeply into their roadmap. It might work for some situations, like if you had an open source project that was used by many large companies as part of their infrastructure.

Coins offer the promise of decentralization & maybe unlimited funds. But coin traders would want to "invest" in something and somehow achieve a "return". But then you're just reinventing capitalism. And capitalism doesn't work very well when you're talking about nonexcludable benefits. As far as I know, there's no reliable way to capture concrete "returns" without excluding some people from the benefits.

IDEA: On the other hand, governments are all about nonexcludable benefits! But, they don't know what to fund. Maybe they could pay into a big fund of OSS coins that's somehow controlled by knowledgeable people. Or allocate coins to organizations in their jurisdiction, and qualify projects if they use appropriate open source licenses. And then just rely on the coin markets to ensure it goes to the right places? Basically a SR/ED coin, maybe exchangeable for tax credits, that you can only use to fund OSS?

@jashmenn
Copy link

I love this idea, and I've gone back and forth on if a new token is required. If you're only performing value transfer BTC, ETH, and USD work just fine today.

Creating a new token only seems justified if we're incentivizing behavior in a new way that's integral to the token. One idea I keep thinking about is that maybe the package dependency tree could be used for "mining" as evidence of a "social-proof"-of-work. You wouldn't really do that with ETH/BTC.

Another fun idea could be using the CLI post-install messages as an advertising slot. (I've seen some projects put an advert for their Open Collective in postinstall.) Fraud is always an issue, but ideally, you could identify the installing user and then both the project (and maybe even the user) are paid by the advertiser. But again, if you can solve the identity issue, it's not clear you need a token here either.

A neighboring issue I've been thinking through is if we can come up with a standard for cross-network payment addresses so that packages could specify a machine-readable way to pay the maintainers. I've written more about this here and I'd love to hear your thoughts.

@Farnaziifz
Copy link

Hi,
for success transfer, do we need to meta mask wallet or we can use trust wallet ether address?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment