It’s strange and sad to see that you have a highly successful package (2 million downloads per week), you have no income from this, you don’t want to maintain it and now you also have a burden to understand the intentions of people who wants take the ownership of your packages.
That’s why I think the most important issue that needs to be solved is the “financial sustainability”.
How much money could Dominic make if this would be a commercial success? Even a “Youtube video” equivalent of this would generate a fair amount of income. Then you wouldn’t want to move away from your package, you would just keep working on it.
Anyway, we are going to figure out this problem eventually, right?
Dominic Tarr: The funny thing is like, compared to the one last year, the WannaCry worm - that was a hack that only affected people that hadn’t updated their code. This one was one that only affected people who had updated their code.
Adam Stacoviak: Well, you’re screwed either way then, I guess…
The Bugmark team (me included) proposes to address financing and security through a market place for open source software issues. I still need to listen to that podcast and then write a blog post how a market place could have helped in this case. Until then, here is a paper that describes the core idea behind the market place:
“A Trading Market to Incentivize Secure Software” (PDF)
German readers can also learn more about the collaboration mechanisms of said market place.
“Marktplatz zur Koordinierung und Finanzierung von Open Source Software” (HTML, PDF)
[8:48 AM]
It’s been quite a controversial approach, but an interesting one.
I think it’s a policy that makes a ton of sense for opening issues, it’s less obvious at the PR level
They are also considering previous strong contributors as patrons, which I think is a good idea
On the flipside, the honesty policy will work up to a certain scale imho, after that it can be quite discretional unless the community does the work of coming up with a clear and transparent policy about it
in general I am thrilled that this is happening, because we need more experimentation in the space, and from a selfish standpoint I feel great we are enabling this with OC [OpenCollective]
The next step is to require patronage to post to their forum and mailing list and other communication channels. A project that adopts a pay to play model would ideally provide the most value to is members/patrons through those channels, and less through the source code or software. I think it would work well for foundational infrastructure projects where standardization is important and less for end-user facing software where out of band support can easily thrive.
Not very fresh (from August) but just finished this podcast:
Devon Zuegel is doing the interview, one of the attendees of the event.
My knowledge about blockchains is still limited (especially smart contracts - feel free to enlighten me with useful links), but I really liked this “built-in royalty system” that (apparently) comes with it. When such system would be widely used, I think that would be a game changer.
This is an interesting attempt, it would be nice to check the results once in a while.
It looks like it’s a very recent update, from December 4th.
And I found only one issue that’s closed because of this.
There is chance that they could miss some “good” contributions (bug reports etc.) with this approach, but their “you must be a patron to be our user” message looks pretty clear.
I’ve seen that podcast. “built-in royalty system” has been implemented in some blockchain projects such as Dash, where some percentage of the mining/staking gains go to a development fund, so it is part of the protocol. Unfortunately, that model is applicable only for blockchain based projects, but not to all OSS.
I believe I heard Public Money, Public Code campaign of FSFE from one of these presentations. It would be great to hear more from this one; what’s the status, whether they made any impact?
This paper was on my list for a while and finally read it. In general, it looks like a decent experiment. Are there any results that you can share?
I’d love to check it but bugmark.net seems to be off at the moment.
My main concern of these “bug bounty” type solutions is, that it takes enormous amount of time to get to know the codebase.
For a decent sized project, you may have to spend a month before you can get to a level that you can solve a random problem in a timely manner.
If there are already core maintainers (which is the ideal case), then it’s impossible for an outsider to beat them, which makes the amount of money involved irrelevant.
If there are no core maintainers, and if an organization constantly wishes to improve/contribute/solve issues, then it’s still better to hire a dedicated developer for it. Otherwise, these “improvements” would become very expensive?
So, it feels like that these type of solutions can only be applied in some “urgent / special” cases, which shouldn’t be more than 5 ~ 10% of the workload.
We have not published any results, yet. We mostly found that the complexity we can support is too much for people. A recommendation is to start with small applications, like a bug bounty program or issue reward program.
Yes, I would not consider the project sustainable at the moment because we have one core developer who is currently sharing his attention with other projects.
True. The idea behind Bugmark is to be more than a bug bounty. Bug bounty is one possible application that we can support. The larger idea is to create a futures market for trading on issues. This futures market can have people with different goals participating. For example:
a bug bounty hunter can see what the value of an issue is and focus attention accordingly.
a maintainer can triage between bug reports and funds made available (while profiting on the transactions), thus earning money from the in-depth knowledge of the project.
an investor can trade on the belief how a project will do in the future, thus having a potential for financial gain while making more money available to open source projects.
a user can put money on issues or feature requests that matter to them.
a insurance company can use prices on the futures market to evaluate the risk for cybersecurity insurance policies
… I am sure there are more users who could engage on the futures market or use information from it.
My point is, that the idea behind bugmark is to create new incentive structures that incorporate the established open source best practices with financial market mechanisms. Malvika Rao from Incentives Research and Don Marti from Mozilla had the original idea behind Bugmark.
Yes. A goal of Bugmark is to strengthen existing open source projects and their members - this includes creating financial mechanisms that give existing maintainers and core contributors a way to earn money - while transparently showing newcomers a path to participate in the wealth that a project may be making available.
Indeed. We have to start somewhere and cannot solve all financial problems in open source over night - or someone would already have done so. The idea of the futures market is another idea to be discussed as it takes a new approach compared to existing solutions.
I am well aware that I have thought through Bugmark quite a bit and I may sometimes skip important steps writing out my logic. Please ask questions if I don’t make sense or if there are details you would like to know more about. The paper you read was our first attempt at formally writing out the idea behind Bugmark, but we have ideas that didn’t make it into the paper.
Thanks for considering our futures market approach to financing open source work.
In theory, futures markets for open source issues have more features in common with prediction markets and with dominant assurance contracts than with a pure bug bounty. Bounty systems impose extra transaction costs on open source by introducing either the overhead of “claiming” a bounty-eligible task or the overhead of assigning credit for completion of a task to the correct worker. And bounties seem to have the problem of disincentivizing information sharing. (If you are close to claiming a valuable bounty but stuck on a subtask, you’re punished for sharing partial work.)
Prediction markets, dominant assurance contracts, and bug futures are all designed to reward “talking your book” – taking a market position and then encouraging others to cooperate by disclosing information.
Of course we will have to see if user behavior in an upcoming live market on real open source issues is actually going to show that this plays out, but I’m cautiously optimistic. Please let me know if you’re interested in participating in a market.
So, it will give us an idea about the health of the project as well.
When you mention these options, it gets interesting. Would be great to see it in action, so we could play around (although I know how difficult it is to create even a prototype).
