From: Able One <able1plus@gmail.com>
To: bitcoindev@googlegroups.com
Cc: nic.anthony@pm.me, "abubakar@btrust.tech" <abubakar@btrust.tech>,
"mike@brink.dev" <mike@brink.dev>
Subject: [bitcoindev] Re: Funding model question — unpaid exploratory work at intake
Date: Wed, 31 Dec 2025 15:40:16 +1000 [thread overview]
Message-ID: <CAO-13RDhh4CSG3DBFjU0wrOt+h18_oFHNQHEJKL1nPj0VL-2Dw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
Hi all,
Reposting from the subscribed address — apologies for the earlier bounce.
Now that I’m properly subscribed, I wanted to repost the question with a
brief, self-contained summary to avoid wasting anyone’s time.
*Summary of the situation*
I’ve been speaking with a few Bitcoin-adjacent grant administrators about
whether *paid exploratory work / experiment framing at intake* is
considered acceptable within open-source funding models.
The consistent response I received was that exploratory framing at intake
is *unpaid by definition* — funding decisions are made only after work is
already scoped, framed, or partially completed by the applicant.
That raised a broader design question for me, independent of any single
organization:
*The question*
• Is expecting unpaid exploratory framing at intake a sane and sustainable
grants model for open-source ecosystems?
• What incentive failures does this create (e.g., selection bias, wasted
contributor time, shallow proposals)?
• Are there alternative structures that fairly price early judgment without
turning grants into VC or bounties?
I’m not asking any org to defend itself here, and no one involved needs to
reply. I’m genuinely interested in how people with long experience in
Bitcoin and open-source view this trade-off.
Any perspective — supportive or critical — is appreciated.
Best,
Nic
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO-13RDhh4CSG3DBFjU0wrOt%2Bh18_oFHNQHEJKL1nPj0VL-2Dw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5719 bytes --]
next reply other threads:[~2026-01-01 14:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 5:40 Able One [this message]
2026-01-03 13:32 ` Chris Stewart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAO-13RDhh4CSG3DBFjU0wrOt+h18_oFHNQHEJKL1nPj0VL-2Dw@mail.gmail.com \
--to=able1plus@gmail.com \
--cc=abubakar@btrust.tech \
--cc=bitcoindev@googlegroups.com \
--cc=mike@brink.dev \
--cc=nic.anthony@pm.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox