developer-event-sponsorship

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Developer Event Sponsorship

开发者活动赞助

You decide where a company's developer-event money goes: which events, at what depth, doing what on site, and what the company can honestly claim in return.
Read every package line by line, because tier names carry no meaning across events. A "Gold" at a foundation mega-conference and a "Gold" at a volunteer-run community day differ on the only things that matter: whether contact data exists, whether a stage slot is for sale, which surfaces are sold separately.
Developers read a sponsorship as a statement about the company. Trade-show behavior at a community event costs more credibility than the logo buys - that trade governs every activation choice in step 6.
Route the user elsewhere when this is the wrong table:
  • Running their own meetup, conference or hackathon →
    samber/developer-relations-skills@developer-meetup-program
    , or see-also
    samber/dev-event-organizer-skills
    for the organizer craft.
  • Getting a talk accepted →
    samber/developer-relations-skills@conference-cfp-submission
    .
  • Funding open-source projects and maintainers →
    samber/developer-relations-skills@oss-sponsors-brand-strategy
    .
  • Splitting the whole DevRel budget across pillars →
    samber/developer-relations-skills@devrel-budget-allocation
    .
你决定公司的开发者活动资金去向:赞助哪些活动、以多深的参与度、现场做什么,以及公司能够诚实地宣称获得什么回报。
逐行阅读每份套餐,因为级别名称在不同活动之间没有可比性。基金会大型会议上的“Gold”和志愿者运营的社区日上的“Gold”,在唯一重要的事情上不同:是否存在联系人数据、舞台时段是否可以购买、哪些展示面单独销售。
开发者会把赞助视为对公司的表态。在社区活动上采用展会式行为所消耗的公信力比logo买来的还多——这条规则支配着第6步中的每一个激活选择。
当这不适用时,引导用户去别处:
  • 运营自己的meetup、会议或hackathon →
    samber/developer-relations-skills@developer-meetup-program
    ,或参见
    samber/dev-event-organizer-skills
    了解组织者的技巧。
  • 争取演讲被接受 →
    samber/developer-relations-skills@conference-cfp-submission
    。
  • 资助开源项目和维护者 →
    samber/developer-relations-skills@oss-sponsors-brand-strategy
    。
  • 在多个支柱之间分配整个DevRel预算 →
    samber/developer-relations-skills@devrel-budget-allocation
    。

Interview

访谈

Ask one question at a time, multiple-choice where you can. Stop once you know the objective, the budget and the staffing ceiling; confirm the rest as the plan takes shape.
  1. Who is asking, and whose budget pays - DevRel, developer marketing, field marketing, engineering, or a founder?
  2. What should this money change: awareness in a new ecosystem, product adoption, sales pipeline, partner/ecosystem relationships, or engineering recruiting? Rank your top two.
  3. Who buys your product - a developer paying with a card, a developer who champions it to a buyer, or a buyer who never touches it?
  4. Who must be in the room: which roles, seniority, ecosystems and regions? Name the person you want your staff talking to.
  5. How much per year, and is that the fee only or everything (travel, swag, staff time)? When is the budget decided?
  6. What is your effort ceiling: how many people can you send who can debug a stranger's code, how many days each across the year, and who answers the follow-up in the two weeks after each event?
  7. By what date must the result be visible - a board review, a funding round, a launch? This is not the contract deadline; ask for both.
  8. Do you want a one-off win at one event this year, or a presence that compounds across editions?
  9. Which events are already on the table - names, dates, deadlines, quoted tiers? Which did you sponsor before, and what happened?
  10. What baseline data exists: web analytics, signup attribution, CRM, past event reports?
  11. What are the constraints - data-protection rules on collected contacts, recruiting goals, brand rules, geographies, competitors you would rather not stand beside?
  12. Who signs, and what is the earliest contract deadline you are facing?
Questions 6-8 decide the rankings in steps 3, 4 and 6, so ask them before recommending anything and say which answer moved which option:
  • A near date for the result promotes the meetup and community rungs in step 4 and the help-desk booth in step 6, and deletes the workshop outright - a quarter of preparation does not fit inside a deadline two months out. It also promotes buying an add-on at an event already contracted over adding a new event.
  • A compounding mandate promotes the ecosystem-anchored portfolio in step 3, the repeated event over the one-and-done, and the workshop in step 6.
  • A low effort ceiling deletes the workshop and the side event, caps step 3 at the shapes one team can staff, and makes the booth's full hall hours the binding constraint on how many events the year can hold.
If your harness has persistent memory, store the objective, the annual budget split, the per-event thresholds and the post-event verdicts. Sponsorships renew annually; the next session must not re-derive the portfolio from scratch.
一次只问一个问题,尽量使用选择题。一旦知道目标、预算和人力上限就停止询问;随着计划成形再确认其余内容。
  1. 谁在提问,用谁的预算——DevRel、开发者营销、现场营销、工程,还是创始人?
  2. 这笔钱应该改变什么:在新生态系统中的认知、产品采用、销售管道、合作伙伴/生态系统关系,还是工程招聘?请排出前两个。
  3. 谁购买你的产品——用信用卡支付的开发者、向买家推荐的开发者,还是从不接触产品的买家?
  4. 谁必须在场:哪些角色、什么资历、哪些生态系统和地区?说出你希望员工与之交谈的具体人选。
  5. 每年多少钱,这只是赞助费还是全部(差旅、礼品、人力时间)?预算何时决定?
  6. 你的投入上限是多少:能派出多少能调试陌生人代码的人,每年每人多少天,每个活动结束后两周内由谁跟进?
  7. 结果必须在什么日期前可见——董事会审查、融资轮次、产品发布?这不是合同截止日期;两个都问。
  8. 你想要今年在一个活动上的一次性胜利,还是跨届次复利的持续存在?
  9. 已经有哪些活动在考虑中——名称、日期、截止日期、报价级别?之前赞助过哪些,结果如何?
  10. 有哪些基线数据:网站分析、注册归因、CRM、过往活动报告?
  11. 有哪些约束——收集联系人时的数据保护规则、招聘目标、品牌规则、地理区域、你不想并肩出现的竞争对手?
  12. 谁签字,你面临的最早合同截止日期是什么?
问题6-8决定第3、4、6步的排序,所以在推荐任何东西之前先问这些问题,并说明哪个答案移动了哪个选项:
  • 结果的近期日期会提升第4步中的meetup和社区层级、第6步中的服务台展位,并直接删除workshop——四分之一的准备时间装不进两个月后的截止日期。它也会提升在已签约活动上购买附加项,而不是增加新活动。
  • 复利任务会提升第3步中的生态系统锚定组合、重复活动而非一次性活动,以及第6步中的workshop。
  • 低投入上限会删除workshop和side event,将第3步限制为一个团队能支撑的形态,并使展位的整个展厅时间成为每年能举办多少活动的绑定约束。
如果你的harness有持久记忆,请存储目标、年度预算分配、每个活动的阈值和活动后判定。赞助每年续约;下一次会话不得从头重新推导组合。

Step 1 - Fix one primary objective

第1步 - 确定一个主要目标

A sponsorship serves one primary mandate. Everything downstream (event choice, tier, activation, metric) is decided by it, and a plan that keeps two primaries produces a report nobody can act on.
This objective table draws on Phil Leggetter's AAARRRP goal mapping, which places events and conference talks in the Awareness/Acquisition family - a corrective to pipeline-first sponsorship pitches.
This table carries no efficiency ranking, deliberately: the objective is a mandate handed to you, not an option chosen for its ratio, and ranking the rows would tell a recruiting team to chase pipeline. Every ranking further down is computed against whichever row lands here.
ObjectiveWhat the money buysPrimary metricEvents that fit
Awarenessfirst contact with an ecosystem that does not know youbranded search, direct traffic and unaided mention lift vs. a pre-event baselinelarge horizontal conferences, student hackathons
Adoptionhands on the product during the eventactivations from the event cohort still active at 30/60/90 daysworkshop-friendly events, hackathons, ecosystem conferences
Pipelinequalified conversations with people who can buy or championconversations → opportunities → influenced pipelinepractitioner and enterprise-heavy conferences
Ecosystempartner and integration conversationspartner conversations that reached a scheduled next meetingvendor-neutral foundation events, ecosystem summits
Recruitingcandidate contactcandidates entering the hiring funnelstudent hackathons, language-community conferences
Who buys changes both the objective and the measurement:
  • Developer-purchased products (self-serve, card payment, individual or team plan) behave like consumer marketing. Success is measurable in-product (event-specific signup URL, promo credit, activation curve) and the follow-up is a product invitation, not a sales sequence. Awareness and adoption are the realistic mandates.
  • Enterprise-sold products hinge on a conversation that outlives the event by two to four quarters. The attendee is often a champion, not a signer, so pipeline claims must ride on the CRM, and the event's contribution is influence rather than source.
  • Both motions in one company need the objective set per event, not per year: the hackathon is awareness, the enterprise conference is pipeline. Say which is which in the plan.
一场赞助服务于一个主要任务。下游所有决策(活动选择、级别、激活、指标)都由它决定,而保持两个主要目标的计划会产生一份没人能执行的报告。
这个目标表格借鉴了Phil Leggetter的AAARRRP目标映射,它将活动和会议演讲放在认知/获取系列中——这是对以管道为先的赞助推销的修正。
这个表格刻意不包含效率排序:目标是你接到的任务,而不是根据比率选择的选项;给这些行排序会让招聘团队去追逐管道。后面所有的排序都是针对落在这里的那一行计算的。
目标钱买到什么主要指标适合的活动
认知与不认识你的生态系统的首次接触品牌搜索、直接流量和未提示提及相比活动前基线的提升大型横向会议、学生hackathon
采用活动期间亲手使用产品活动队列中的激活用户在30/60/90天后仍活跃适合workshop的活动、hackathon、生态系统会议
管道与能购买或推荐的人进行合格对话对话 → 机会 → 受影响管道实践者和企业密集的会议
生态系统合作伙伴和集成对话达到预定下一步会议的合作伙伴对话供应商中立的基础活动、生态系统峰会
招聘候选人接触进入招聘漏斗的候选人学生hackathon、语言社区会议
谁购买既改变目标也改变衡量方式:
  • 开发者直接购买的产品(自助、信用卡支付、个人或团队套餐) 表现得像消费品营销。成功可以在产品内衡量(活动专属注册URL、促销积分、激活曲线),后续是产品邀请,而不是销售序列。认知和采用是现实可行的任务。
  • 企业销售的产品 取决于比活动晚两到四个季度的对话。参会者往往是倡导者而非签字人,因此管道声明必须依赖CRM,活动的贡献是影响而非来源。
  • 一家公司同时有两种模式 需要按活动而不是按年设定目标:hackathon是认知,企业会议是管道。在计划中说明哪个是哪个。

Step 2 - Qualify every candidate event

第2步 - 资格审查每个候选活动

Headcount is the least informative number in a prospectus. Demand this evidence before pricing anything, and treat an organizer who cannot supply it as the answer:
  1. Audience composition - role mix, seniority, company size, buying influence. Not a total.
  2. Geography and travel mix.
  3. Track record - prior editions, returning-sponsor rate, and last edition's post-event report with actual numbers.
  4. Sponsor density and which competitors have already committed.
  5. Exactly what the package includes (see step 4).
  6. Program balance - technical content versus sponsor content.
  7. Follow-up rights - whether contact data exists at all, and under which consent.
Organizers who run a healthy event already publish most of this. The PSF's PyCon US 2026 prospectus prints attendee count, job-function split (53.9% developer), industry split and company-size bands before it prints a price - that is the evidence standard to hold every organizer to, not an unusual courtesy.
Score each event against the objective rather than against other events' prices. references/event-scorecard.md holds the weighted scorecard, a worked example of a strong and a weak event scored side by side, and the request email that extracts the evidence above.
Walk away on:
  • unverifiable demographics
  • a first-time organizer making large promises
  • a prospectus that sells sponsor benefits harder than the attendee experience
  • an attendee list offered as a deliverable
  • deadline pressure arriving before the audience data does
人数量是prospectus中最没信息量的数字。在给任何东西定价之前要求这些证据,并把无法提供证据的组织者视为答案本身:
  1. 观众构成——角色构成、资历、公司规模、购买影响力。不是总数。
  2. 地域和差旅构成。
  3. 过往记录——往届、回头赞助商比例、上一届的实际数字活动后报告。
  4. 赞助商密度,以及哪些竞争对手已经承诺。
  5. 套餐具体包含什么(见第4步)。
  6. 节目平衡——技术内容与赞助商内容之比。
  7. 后续权利——是否存在联系人数据,在何种同意下。
运行健康活动的组织者已经发布了大部分内容。PSF的PyCon US 2026 prospectus在印出价格之前就印出了参会人数、职位构成(53.9%开发者)、行业构成和公司规模区间——这是要求每个组织者达到的证据标准,而不是一种不寻常的礼貌。
根据目标而不是其他活动的价格来给每个活动打分。references/event-scorecard.md 包含加权记分卡、一个强弱活动并排打分的完整示例,以及提取上述证据的请求邮件。
遇到以下情况转身离开:
  • 无法验证的人口统计
  • 首次组织者做出重大承诺
  • 推销赞助商利益比参会者体验更用力的prospectus
  • 把参会者名单作为交付物提供
  • 在观众数据之前先到截止日期压力

Step 3 - Brainstorm the portfolio, then choose one

第3步 - 头脑风暴组合,然后选择一个

Size the envelope before drawing the shortlist. One published reference point exists: events took a mean 41.1% of DevRel program budget in State of Developer Relations 2024 (DevRel.Agency, September 2024), the largest of four categories. Use it only as evidence that events historically dominate DevRel spend - 47 respondents answered that question and their shares sum to 104.5% - never as a target to hit.
Then enter brainstorming mode before committing to any single event. Sketch two or three candidate portfolios for the year, each with its allocation split, the staffing it consumes, and what it deliberately fails at. Recommend one, explain why the others lose, and get explicit agreement before negotiating anything.
Four shapes are worth drawing from, ranked by value per unit of effort. Effort is staff-days across the year, travel overhead, preparation reusable between events, and follow-up capacity after each one - never the fee. Value is qualified conversations that continue after the event, plus the recognition carried into the next edition.
  • efficiency: ecosystem-anchored > flagship-led > farm-team > regional spread
  • value: flagship-led > ecosystem-anchored > farm-team > regional spread
  • effort: regional spread > farm-team > flagship-led == ecosystem-anchored
No compliance-cost line at this altitude: contracts, consent and code-of-conduct obligations are signed per event in step 4, and a portfolio shape commits to none of them.
  • Ecosystem-anchored - every event sits inside one technology community. Leads the efficiency line because the demo, the staff brief, the prepared answers and the follow-up relationships are built once and reused at every event; credibility compounds fast. Effort: a quarter of preparation, then a standing job for whoever owns that community. Fails the moment the strategy needs a second ecosystem.
  • Flagship-led - one deep sponsorship plus small presences elsewhere. Buys the most conversations and the strongest recognition of any shape, because depth of presence is what a developer audience notices. Effort: a quarter of preparation and a standing job for the week itself. Fails at geographic coverage, and starts cold everywhere the flagship is not.
  • Farm-team - student hackathons for long-horizon awareness plus one practitioner conference for near-term proof. Two objectives and two metrics on one budget, which is also its cost: two follow-up motions and two measurement systems, each paid in full. Effort: the preparation of the flagship shape, doubled, and two owners.
  • Regional spread - many small local events. Cheap per event, good for a field team, and the only shape that reaches developers who never travel. Effort: travel overhead multiplied by the event count, with follow-up fragmented across as many owners. Rarely reaches decision-makers.
  • Justify the effort tie: flagship-led and ecosystem-anchored concentrate the same people on the same preparation for the same total number of days. The ecosystem shape spreads those days across more editions without adding any, which is why it wins on efficiency and not on effort.
  • Default to ecosystem-anchored, and move to flagship-led when one event demonstrably holds the audience the objective names, or when recognition inside a single ecosystem is already established and the mandate is to be seen beyond it.
  • What this order starves: the regional spread, the only shape that gives a field team local coverage. Promote it when go-to-market is regional and the staff already live in those cities - a team travelling nowhere new turns its worst axis, travel overhead, into near-zero.
  • Delete the farm-team, rather than ranking it last, whenever one person owns event measurement: two objectives with one owner produce one metric and two excuses.
  • Re-rank against what you already know about this team: an ecosystem where the company is already a known name, a staff roster clustered in one region, or an existing workshop curriculum all move a shape up before the default order applies.
Keep a slice of the annual budget unallocated - 15-25% is this skill's default, not an industry figure - because the best-fit event is rarely the one visible in January.
先确定预算信封,再画候选清单。有一个公开参考点:在《State of Developer Relations 2024》(DevRel.Agency,2024年9月)中,活动平均占DevRel项目预算的41.1%,是四个类别中最大的。只把它作为活动历史上主导DevRel支出的证据——47位受访者回答了该问题,份额总和为104.5%——绝不是要达到的目标。
然后在承诺任何单一活动之前进入头脑风暴模式。为年度勾勒两到三个候选组合,每个都要有分配拆分、消耗的人力,以及它刻意失败的地方。推荐一个,解释为什么其他组合落选,并在谈判任何东西之前获得明确同意。
有四种形态值得画出来,按单位投入的价值排序。投入是全年员工天数、差旅开销、活动间可复用的准备、每个活动后的跟进能力——绝不是赞助费。价值是活动结束后继续进行的合格对话,以及带入下一届的认知度。
  • 效率:生态系统锚定 > 旗舰主导 > 农场队 > 地域分散
  • 价值:旗舰主导 > 生态系统锚定 > 农场队 > 地域分散
  • 投入:地域分散 > 农场队 > 旗舰主导 == 生态系统锚定
在这个高度没有合规成本线:合同、同意和行为准则义务是在第4步按活动签署的,组合形态不会承诺其中任何一项。
  • 生态系统锚定 ——每个活动都处于同一个技术社区内。在效率线上领先,因为演示、员工简报、准备好的回答和后续关系一次构建,并在每个活动中复用;公信力快速复利。投入:四分之一的准备时间,然后是拥有该社区者的常设工作。当需要第二个生态系统时就失败。
  • 旗舰主导 ——一次深度赞助加其他地方的少量存在。买到最多的对话和最强烈的认知度,因为展示深度是开发者观众注意到的关键。投入:四分之一的准备时间和当周的常设工作。在地域覆盖上失败,并且在旗舰不存在的地方从零开始。
  • 农场队 ——学生hackathon用于长期认知,加一个从业者会议用于近期验证。一个预算上两个目标和两个指标,这也是它的成本:两套跟进动作和两套测量系统,各自全额支付。投入:旗舰形态的准备时间翻倍,和两个负责人。
  • 地域分散 ——许多小型本地活动。每次便宜,适合外勤团队,是唯一能触达从不旅行的开发者的形态。投入:差旅开销乘以活动数量,跟进碎片化到同样多的负责人。很少触达决策者。
  • 解释投入平局:旗舰主导和生态系统锚定将相同的人集中在相同的准备上,总天数相同。生态系统形态将这些天数分散到更多届次而不增加任何天数,这就是为什么它在效率上而不是投入上胜出。
  • 默认选择生态系统锚定;当一个活动明确拥有目标所指定的观众,或者单一生态系统内的认知度已经建立而任务是要被外部看到时,转向旗舰主导。
  • 这个顺序饿死的:地域分散,唯一能给外勤团队本地覆盖的形态。当销售模式是地域性的且员工已经住在那些城市时提升它——一个不前往任何新地方的团队,把它最差的一轴——差旅开销——变成接近零。
  • 当一个人拥有活动测量时,删除农场队而不是把它排在最后:一个负责人两个目标会产生一个指标和两个借口。
  • 根据你已经知道的团队情况重新排序:公司已经是知名名称的生态系统、集中在某个地区的员工名单、或现有的workshop课程,都会在默认顺序应用之前让某个形态上移。
保留年度预算中未分配的部分——15-25%是本skill的默认值,不是行业数字——因为最合适的活动很少是一月份看到的那一个。

Step 4 - Choose the model and the tier

第4步 - 选择模式和级别

Read the prospectus for three clauses before looking at the price:
  • what contact data the sponsor receives
  • how a stage slot is obtained
  • which surfaces are sold separately
Package models return different amounts of qualified conversation per staff-day, which is the one axis a price sheet never shows. Effort below is people on site × days plus the preparation and follow-up the model generates; compliance cost is the review a model triggers and how little of it can be undone once signed.
  • efficiency: meetup / user group > community conference > foundation or large vendor conference > hackathon > in-kind
  • value (qualified conversations that continue): foundation or large vendor conference > hackathon > community conference > meetup / user group > in-kind
  • effort: hackathon > foundation or large vendor conference > community conference > meetup / user group > in-kind
  • compliance cost: foundation or large vendor conference > hackathon > in-kind > community conference > meetup / user group
Package modelWhat money buysWhat it never buysEffortHow to win there
Meetup / user groupone evening in front of a small, high-intent local audiencescalean hour of preparation, one evening, local staffsponsor a series rather than one night; let the host keep editorial control
Community / volunteer conferencepresence among peers, a table, passes, a brief timed pitchattendee contact data, badge scanning, purchased talkstwo technical people for the length of the event; opt-in follow-up only, so the follow-up list stays smallsend people who help; capture interest by opt-in only; submit to the CFP separately
Foundation / large vendor conferencebooth space, passes, consented badge-scan data, à-la-carte surfaces (wi-fi, lanyard, scholarships, activation zones), published multi-event discountsmain-stage session slots, editorial contenta standing job for several people across several days, plus the follow-up that scan volume createsbuy a lower tier plus the one add-on that reaches your audience; logo size scales with price, surfaces do not
Hackathonmentorship access, a prize track, workshop slots, product placement in what gets builtjudging outcomes, guaranteed adoptiona standing job across nights and a weekend, judging includedframe the prize around the problem, not the product; staff the crunch hours
In-kind (credits, hardware, infrastructure)reach at low cash cost for an early-stage vendorpredictable visibilitynear-zero on site, a week spent pinning deliverables in writingpin every deliverable in writing; in-kind visibility drifts unless specified
  • Read the efficiency line as ordering models, not events: it decides where a marginal staff-day goes when two candidate events both survived step 2.
  • What this order starves: the foundation or large vendor conference - top on value, second on effort, so a ratio picks the meetup every time, and a year of meetups never reaches an ecosystem that does not know you. Promote it when the objective is awareness in a new ecosystem, or when the buyers you named in the interview travel to one event and no other.
  • Delete in-kind, rather than ranking it last, unless the company is early-stage and cash-constrained. Elsewhere it buys visibility nobody committed to, at the price of a contract negotiation with no money in it.
  • Read the compliance line as the review triggered and the reversibility spent:
    • a large conference's contract is signed a quarter ahead and cannot be unwound, and its consented badge data needs a data-protection review before anyone may use it
    • a hackathon's prize rules and judging criteria are published and fixed the moment entries open
    • a community conference asks you to sign its sponsor code of conduct and holds no data at all
    • a meetup is a handshake
  • This ranking is a default, not a law, and it shifts with who executes it. Re-rank when the team already attends an event for other reasons, when the product demos badly in five minutes, or when a local user group is run by someone the company already works with.
Inside a chosen event the tier is its own menu. Efficiency: lower tier plus the one add-on that reaches your audience > cheapest tier clearing the booth price floor > logo-only tier > top tier.
Effort scales with what a tier obliges you to staff rather than with what it costs: ten passes and a large booth are a staffing commitment, and a booth nobody can staff for the full hall hours is worth less than a workshop. Check for eligibility-gated startup or end-user tiers before picking a rung, since they are the same product cheaper, for reasons unrelated to audience quality.
Work back from the calendar: three mechanics are decided there rather than at the negotiating table.
  • Contract and add-on deadlines: large events close roughly a quarter out - KubeCon NA 2026 required signed contracts by 14 August for a November event - so put the decision in the fiscal quarter before the event it affects.
  • Multi-event discounts: check for published ones before inventing an ask, since some marketplaces fix them rather than negotiate them (CNCF: 3% for one event, 5% for two signed together, 8% for three or more).
  • Branded surfaces: move early, since the best ones sell out months ahead and are the cheap half of the lower-tier-plus-add-on play.
Where published prices exist, read them before accepting a quote. references/published-price-ladders.md carries the two 2026 prospectuses that print full price lists, the booth price floor they reveal, what a hands-on slot really costs, and the tier-name comparison trap to avoid.
在看价格之前,先读prospectus中的三个条款:
  • 赞助商获得什么联系人数据
  • 舞台时段如何获得
  • 哪些展示面单独销售
套餐模式每个员工日返回的合格对话数量不同,这是价目表永远不会显示的一个轴。下面的投入是在场人数×天数加上该模式产生的准备和跟进;合规成本是某种模式触发的审查,以及一旦签署后有多少无法撤销。
  • 效率:meetup / 用户组 > 社区会议 > 基金会或大型供应商会议 > hackathon > 实物
  • 价值(继续的合格对话):基金会或大型供应商会议 > hackathon > 社区会议 > meetup / 用户组 > 实物
  • 投入:hackathon > 基金会或大型供应商会议 > 社区会议 > meetup / 用户组 > 实物
  • 合规成本:基金会或大型供应商会议 > hackathon > 实物 > 社区会议 > meetup / 用户组
套餐模式钱买到什么永远买不到什么投入如何在那里胜出
meetup / 用户组一个晚上,面对小而高意向的本地观众规模一小时的准备、一个晚上、本地员工赞助一个系列而不是一晚;让主办方保留编辑控制权
社区 / 志愿者会议在同行中的存在、一张桌子、通行证、一次简短的限时推介参会者联系人数据、徽章扫描、购买的演讲两名技术人员覆盖活动全程;仅限选择加入的跟进,因此跟进名单保持很小派去帮忙的人;仅通过选择加入获取兴趣;单独提交CFP
基金会 / 大型供应商会议展位空间、通行证、经同意的徽章扫描数据、单点附加项(wi-fi、挂绳、奖学金、激活区)、公布的多活动折扣主舞台时段、编辑内容几个人跨数天的常设工作,加上扫描量带来的跟进购买较低级别加上一个触达你受众的附加项;logo尺寸随价格增长,展示面不随
hackathon导师机会、一个奖品轨道、workshop时段、产品被用在所构建内容里的机会评审结果、保证采用跨夜晚和周末的常设工作,包括评审围绕问题而非产品设计奖项;在冲刺时间派人
实物(积分、硬件、基础设施)以低现金成本触达早期阶段供应商可预测的可见性现场近乎为零,用一周时间把交付物钉在书面上把每个交付物钉在书面上;实物可见性除非指明否则会漂移
  • 把效率线理解为对模式而非活动的排序:当两个候选活动都通过了第2步时,它决定一个边际员工日放在哪里。
  • 这个顺序饿死的:基金会或大型供应商会议——价值第一、投入第二,所以比率每次都会选meetup,而一年的meetup永远无法触达不认识你的生态系统。当目标是在新生态系统中的认知,或当你在访谈中点名的买家只去一个活动而不去其他时,提升它。
  • 删除实物,而不是把它排在最后,除非公司是早期阶段且现金受限。否则它买的是没人承诺的可见性,代价是一场没有钱的合同谈判。
  • 把合规线理解为触发的审查和消耗的可逆性:
    • 大型会议的合同提前一个季度签署且无法撤销,其经同意的徽章数据在任何人使用前需要数据保护审查
    • hackathon的奖项规则和评审标准在提交开放那一刻就发布并固定
    • 社区会议要求你签署其赞助商行为准则,且完全不持有数据
    • meetup是一次握手
  • 这个排序是默认值,不是法律,它会随执行者而变。当团队已经因其他原因参加某个活动、产品在五分钟内演示效果差、或本地用户组由公司已经合作的人运营时,重新排序。
在选定活动内部,级别本身就是一份菜单。效率:较低级别加上一个触达你受众的附加项 > 最便宜且达到展位价格下限的级别 > 仅logo级别 > 最高级别。
投入随级别要求你配备人员的程度扩展,而不是随其成本:十个通行证和大型展位是人力承诺,而一个无法在全部展厅时间配备人员的展位比一个workshop价值更低。在选择一档之前检查是否有资格限制的创业公司或终端用户级别,因为它们是以更低价格提供的相同产品,原因与受众质量无关。
从日历倒推:有三个机制在那里决定,而不是在谈判桌上。
  • 合同和附加项截止日期:大型活动大约提前一个季度关闭——KubeCon NA 2026要求11月活动在8月14日前签署合同——所以把决定放在它影响的活动的上一个财季。
  • 多活动折扣:在编造要求之前检查已公布的折扣,因为一些市场固定它们而不是谈判它们(CNCF:一个活动3%,两个一起签5%,三个或更多8%)。
  • 品牌展示面:尽早行动,因为最好的展示面提前几个月售罄,而且是较低级别加附加项策略中便宜的一半。
在有公布价格的地方,在接受报价之前先读它们。references/published-price-ladders.md 包含两份2026年prospectus,印出了完整价格表、它们揭示的展位价格下限、一个动手时段真正花费多少,以及要避免的级别名称比较陷阱。

Step 5 - Negotiate

第5步 - 谈判

Packages move, especially for early commitment, multi-event or multi-year deals, off-peak editions, growing events, and sponsors who bring something the organizer wants (a workshop, a mentor pool, a scholarship fund).
The asks compete for one budget that is not money: the number of things an organizer says yes to before the conversation turns. Spend it in this order.
  • efficiency: previous edition's post-event report > extra staff passes > timing of lead-data delivery > placement on a specific high-traffic surface instead of a generic logo tier > a workshop or demo-theatre slot > permission to publish content from the event > a written attendance estimate with a remedy if the event undershoots badly
  • value (qualified conversations that continue): workshop or demo-theatre slot > high-traffic surface > extra staff passes > lead-data timing > permission to publish > attendance remedy > post-event report
The report leads because it costs nothing to ask, arrives before signature, and can still cancel the deal. What this order starves is the attendance remedy and the workshop slot, the two hardest asks.
Make the remedy your first ask at any first edition, where an unmet estimate is the whole risk. Make the workshop your first ask whenever step 6 chose it. The ordering sequences the asks; it never shortens the list.
Never buy a keynote's content, a judging outcome, an attendee list the attendees never consented to, or an implied speaking slot at an event that runs a CFP. None of these is a gray area to probe in negotiation: each is an ethics failure, and each becomes a story that travels faster than the sponsorship does.
套餐会动,尤其是对于早期承诺、多活动或多年度交易、淡季届次、成长中的活动,以及为组织者带来某种他们想要的东西(workshop、导师池、奖学金基金)的赞助商。
这些要求竞争一个不是钱的预算:组织者在对话转向之前会答应的事情的数量。按这个顺序花它。
  • 效率:上一届活动后报告 > 额外员工通行证 > 线索数据交付时间 > 特定高流量展示面的位置而非通用logo级别 > workshop或演示剧场时段 > 发布活动内容的许可 > 书面出席估计并在活动严重不足时提供补救
  • 价值(继续的合格对话):workshop或演示剧场时段 > 高流量展示面 > 额外员工通行证 > 线索数据时间 > 发布许可 > 出席补救 > 活动后报告
报告领先因为要求它不花任何钱、在签字前到达、并且仍然可以取消交易。这个顺序饿死的是出席补救和workshop时段,两个最难的要求。
在任何首次活动中,把补救作为你的第一个要求,未达标的估计是全部风险。每当第6步选择了workshop时,把workshop作为你的第一个要求。排序安排要求的顺序;它永远不会缩短清单。
绝不要购买keynote的内容、评审结果、参会者未同意的名单、或在一个运行CFP的活动上隐含的演讲时段。这些都不是在谈判中可试探的灰色地带:每一个都是道德失败,每一个都会成为比赞助传播得更快的故事。

Step 6 - Design the on-site activation

第6步 - 设计现场激活

Spend commits immediately after this choice, so brainstorm two or three activation options for the chosen tier, name the trade-off in each, recommend one, and validate it before anything is bought.
Value here is qualified developer conversations that continue after the event, never badge scans. Effort is staff-days on site, preparation before it, follow-up capacity after it, and opportunity cost - the same two engineers cannot run a workshop and staff a booth.
  • efficiency: help-desk booth > prize track > side event > workshop
  • value: workshop > help-desk booth > side event > prize track
  • effort: workshop > side event > help-desk booth > prize track
  • compliance cost: prize track > side event > help-desk booth == workshop
Effort in magnitudes:
  • the booth costs an hour of preparation and then a standing job for the hall hours
  • the prize track costs a week to frame and procure, and borrows mentoring hours you were staffing anyway
  • the side event costs a week of guest-list and venue work plus an evening that also costs you the next morning
  • the workshop costs a quarter of preparation and takes your two best engineers off the floor for its whole slot
  • Default to the booth as a help desk: technical staff who debug a stranger's code, a demo the attendee drives, a quick win within reach (the five-minute bar is this skill's default). That pattern is practitioner convention, not a measured result - but it is the behavior developer audiences reward, and the pitch-first booth is the one they punish.
  • Justify the compliance tie: a booth and a workshop each collect contact details under one consent line, reviewed once and reused all year, and trigger nothing else. The prize track tops that axis because prize promotions are regulated in some jurisdictions, judging criteria are published and fixed once entries open, and prize value can be reportable. A side event you host carries the venue contract, the alcohol, and a code of conduct the conference organizer is not enforcing on your behalf.
  • What this order starves: the workshop and the side event, the two deepest engagements available and the two most staff-intensive, so a ratio picks the booth every round. Promote the workshop when a curriculum already exists - that alone collapses its preparation from a quarter to a week and moves it to the top of the efficiency line. Promote it too when the product cannot show a win in five minutes and the booth's whole premise fails. Promote the side event when the objective is ecosystem and the twenty names already sit in the CRM, or when the team was travelling to this event anyway, which drops its marginal cost to the evening alone.
  • Delete rather than demote:
    • the prize track at any event with no build phase
    • the workshop where the package sells no hands-on slot or nobody can be spared for its preparation
    • both the workshop and the side event when only one person is travelling, since a team of one can staff exactly one thing
  • The scholarship or diversity fund sits off this ladder on purpose. It buys goodwill and stage-level thanks and produces no conversations by design, so it has no value on this axis and ranking it would be false precision. Choose it deliberately as an awareness or employer-brand purchase, or leave it out.
references/activation-playbooks.md details each activation in that order - staffing rhythm per event type, the staff brief, and a positive/negative example pair of booth conversations.
Two rules bind every activation. Staff conversations toward the qualification bar defined in step 7 rather than toward badge count. And where a live demo is part of the activation, design its failure plan with
samber/developer-relations-skills@developer-live-demo-design
- a booth demo fails in front of the exact person you were trying to convince.
花钱在此选择之后立即承诺,所以为选定的级别头脑风暴两到三个激活选项,说出每个选项的权衡,推荐一个,并在买任何东西之前验证它。
这里的价值是活动结束后继续进行的合格开发者对话,绝不是徽章扫描。投入是现场员工天数、之前的准备、之后的跟进能力,以及机会成本——同两名工程师不能既运行workshop又值守展位。
  • 效率:服务台展位 > 奖品轨道 > side event > workshop
  • 价值:workshop > 服务台展位 > side event > 奖品轨道
  • 投入:workshop > side event > 服务台展位 > 奖品轨道
  • 合规成本:奖品轨道 > side event > 服务台展位 == workshop
投入的量级:
  • 展位花费一小时的准备,然后是展厅时间的常设工作
  • 奖品轨道花费一周来设计和采购,并借用你本来就在安排的指导时间
  • side event花费一周的嘉宾名单和场地工作,外加一个晚上,还会让你损失第二天上午
  • workshop花费四分之一的准备时间,并在整个时段内把你的两名最好的工程师从现场调走
  • 默认将展位作为服务台:调试陌生人代码的技术人员、参会者自己操作的演示、随手可及的快速胜利(五分钟门槛是本skill的默认值)。这种模式是实践者惯例,不是测量结果——但这是开发者观众奖励的行为,而先推销的展位是他们惩罚的。
  • 解释合规平局:展位和workshop各在一个同意行下收集联系方式,审查一次并全年复用,不触发其他任何东西。奖品轨道在该轴上领先,因为奖品促销在某些司法管辖区受到监管,评审标准一旦提交开放就发布并固定,奖品价值可能需要报告。你举办的side event承担场地合同、酒精,以及会议组织者不会替你执行的行为准则。
  • 这个顺序饿死的:workshop和side event,现有最深度的两种参与,也是两种最耗人力的,所以比率每一轮都会选展位。当已有课程时提升workshop——仅此一项就把它从四分之一准备时间压缩到一周,并把它移到效率线顶部。当产品无法在五分钟内展示胜利、展位的整个前提失败时,也要提升它。当目标是生态系统且二十个名字已经在CRM中,或团队本来就要去这个活动(将其边际成本降到只剩晚上)时,提升side event。
  • 删除而不是降级:
    • 在任何没有构建阶段的活动上的奖品轨道
    • 套餐没有出售动手时段或没人能被抽调来做准备的workshop
    • 当只有一个人旅行时,workshop和side event都删除,因为一个人的团队只能值守一件事
  • 奖学金或多样性基金故意不放在这个阶梯上。它买的是善意和舞台层面的感谢,刻意不产生对话,所以在这个轴上没有价值,给它排序会是虚假的精确。有意识地把当作品牌或雇主品牌购买来选择,或者干脆不选。
references/activation-playbooks.md 按此顺序详细说明每个激活——每种活动类型的值班节奏、员工简报、以及一对正面/负面的展位对话示例。
两条规则约束每个激活。员工对话朝向第7步定义的资格标准,而不是徽章数量。当现场演示是激活的一部分时,用
samber/developer-relations-skills@developer-live-demo-design
设计其失败方案——展位演示会在你正试图说服的那个人面前失败。

Step 7 - Build the measurement plan before signing

第7步 - 在签署前建立测量计划

Cost the sponsorship fully - fee, add-ons, booth build, shipping, swag, prizes, travel and accommodation per person, and loaded staff time for preparation, travel, on-site days and follow-up. Staff time is the line most teams omit and the line that most often doubles the total.
Then fix the threshold before signing: a target cost per qualified conversation, plus a minimum conversation count that makes the trip worth staffing. Derive the target from the current blended acquisition cost rather than from the sponsorship fee.
Only one unit survives comparison across a hackathon, a community day and a mega-conference: the qualified conversation - someone who has the problem, holds or influences the decision, and agrees to a named next step. Define the bar and the next step before the event and brief every staffer on both.
Route each logged conversation to the team that can use it, and name the destination in the log. Mary Thengvall's DevRel Qualified Lead (2019) gives the routing table:
Conversation typeRoute to
Case-study materialMarketing
Feedback and beta candidatesProduct
BugsEngineering
Partner interestPartnerships
CandidatesRecruiting
BuyersSales
Most booth conversations are not sales leads, and defaulting them all to sales is what fills a CRM with records nobody works.
references/sponsorship-roi-model.md holds the cost worksheet, the metric definitions per objective, and the tracking mechanics (event-specific URLs and codes, baseline capture, consented capture where scanning does not exist, the conversation log shape). It also covers the 30/60/90 windows and a worked calculation with the same event judged well and badly.
在签署之前全面计算赞助成本——费用、附加项、展位搭建、运输、礼品、奖品、每人差旅住宿,以及准备、旅行、现场天数和跟进的人力时间。人力时间是最多团队省略的行,也是最多使总额翻倍的行。
然后在签署前确定阈值:每个合格对话的目标成本,加上使行程值得安排的最低对话数量。从当前混合获客成本推导目标,而不是从赞助费推导。
只有一个单位能跨越hackathon、社区日和大型会议进行比较:合格对话——一个有这个问题、持有或影响决策、并同意一个明确的下一步行动的人。在活动前定义标准并培训每个员工。
将每条记录的对话路由到能使用它的团队,并在记录中指明目的地。Mary Thengvall的《DevRel Qualified Lead》(2019) 给出了路由表:
对话类型路由到
案例研究素材市场
反馈和beta候选产品
Bug工程
合作伙伴兴趣合作伙伴
候选人招聘
买家销售
大多数展位对话不是销售线索,把它们全部默认为销售,正是让CRM充满无人处理的记录的方式。
references/sponsorship-roi-model.md 包含成本工作表、按目标划分的指标定义、跟踪机制(活动专属URL和代码、基线捕获、无扫描时的同意捕获、对话记录形态)。它还涵盖30/60/90窗口,以及一个同一活动评价为好和坏的完整计算。

Step 8 - Review, then renew, renegotiate or drop

第8步 - 复盘,然后续约、重新谈判或放弃

Run the review within two weeks, while the conversation log is still accurate, and write the verdict down where next year's budget cycle will find it:
  • Renew - threshold met, staffing sustainable, audience unchanged.
  • Renegotiate - right audience, wrong package: drop a tier and buy the add-on that produced the conversations, or trade the booth for a workshop.
  • Drop - audience mismatch, or the same outcome is reachable elsewhere for less.
These three carry no efficiency ranking: the verdict is read off the threshold set in step 7, not chosen for its ratio. Ranking them would let the cheapest verdict win an argument the data already settled.
Judge a first edition against awareness-stage expectations and reserve the pipeline verdict for the second, since recognition and relationships compound across editions. That patience is not a license to renew an event that has missed its threshold twice.
在两周内进行复盘,趁对话记录仍然准确,并把判定写下来放到明年的预算周期能找到的地方:
  • 续约 ——达到阈值、人力可持续、观众未变。
  • 重新谈判 ——受众正确、套餐错误:降一级并购买产生对话的附加项,或者把展位换成本地workshop。
  • 放弃 ——受众不匹配,或者同样的结果在别处可以用更低成本达到。
这三个没有效率排序:判定是根据第7步设定的阈值读出的,不是因为比率而选。给它们排序会让最便宜的判定赢得一个数据已经解决的争论。
用认知阶段的期望来评判首次活动,把管道判定留给第二次,因为认知和关系会跨届复利。这种耐心不是允许续约一个已经两次未达阈值的活动。

Pass threshold

通过阈值

The plan is finished when every event on it carries:
  • one primary objective
  • a fully loaded cost
  • a target cost per qualified conversation
  • a minimum conversation count
  • a named owner for the follow-up
An event that cannot be given a threshold cannot be judged and should not be signed - say that out loud instead of softening it.
After the event, the sponsorship passes when it met its threshold on its own primary metric. Missing it triggers step 8's renegotiate or drop, not a search for a secondary metric that happens to look better.
当计划上每个活动都带有以下内容时,计划才算完成:
  • 一个主要目标
  • 完全加载的成本
  • 每个合格对话的目标成本
  • 最低对话数量
  • 一个指定的跟进负责人
无法给定阈值的活动就无法评判,也不应该签署——大声说出来,而不是弱化它。
活动结束后,当赞助在其自身主要指标上达到阈值时,它就是通过。未达标触发第8步的重新谈判或放弃,而不是寻找一个碰巧看起来更好的次要指标。

Invocation examples

调用示例

  • "Should we sponsor KubeCon next year?" → run the interview, then steps 1-2 on that single event, and answer with a threshold or a decline, never with a maybe.
  • "We have €60k for developer events in 2027, what should we do with it?" → steps 1-3, deliver two or three candidate portfolios with the allocation split, recommend one.
  • "They quoted us Gold at $18k, is that worth it?" → step 4 against the line items and
    references/published_price_ladders.md
    , then step 7's fully loaded cost before any verdict.
  • "We're sponsoring a hackathon in six weeks, what do we do there?" → steps 6-7 only; the event is bought, so design the activation, the qualification bar and the tracking.
  • "Was last year's conference worth it?" → step 8, using whatever cost and conversation data exists; if no threshold was set, say the question cannot be answered honestly and fix it for the next one.
  • “我们明年应该赞助KubeCon吗?” → 运行访谈,然后只针对该活动执行第1-2步,并用阈值或拒绝回答,绝不用“也许”。
  • “我们2027年有6万欧元用于开发者活动,应该怎么花?” → 第1-3步,交付两到三个候选组合及分配拆分,推荐一个。
  • “他们给我们Gold报价1.8万美元,值吗?” → 对照细项和
    references/published_price_ladders.md
    执行第4步,然后在任何判定之前执行第7步的完全加载成本。
  • “我们六周后要赞助一个hackathon,现场做什么?” → 只做第6-7步;活动已买,所以设计激活、资格标准和跟踪。
  • “去年的会议值得吗?” → 第8步,使用任何现有的成本和对话数据;如果没有设定阈值,说明这个问题无法诚实回答,并为下次修复。

Failure modes

失败模式

SymptomCauseFix
Big attendance, no useful conversationsevent chosen on headcount, not compositionre-qualify on role mix and buying influence (step 2)
Booth ignorednon-technical staff, pitch-first posturestaff with engineers, lead with help (step 6)
Leads that never convertswag-for-scan capture with no qualification bardefine the bar pre-event; capture fewer, better records
No verdict at renewal timeno threshold and no baseline set before signingfix both in step 7, before the contract
Repeated one-off sponsorshipsportfolio never designed, events bought reactivelyrun step 3 once a year and keep a reserve
Community backlashtrade-show mechanics at a community eventread the three prospectus clauses in step 4 first
Missed the good eventscontracts close a quarter ahead of the eventmap deadlines during the interview, not after
症状原因修复
参加人数多,没有有用对话根据人数而非构成选择活动根据角色构成和购买影响力重新资格审查(第2步)
展位被忽视非技术人员、先推销的姿态用工程师配备人员,以帮助为先导(第6步)
线索从不转化为扫描而赠品,没有资格标准在活动前定义标准;捕获更少但更好的记录
续约时没有判定签署前没有设定阈值和基线在第7步、合同之前修复两者
重复的一次性赞助从未设计组合,被动购买活动每年运行一次第3步并保留储备金
社区反弹在社区活动上采用展会式机制先读第4步中prospectus的三个条款
错过了好活动合同在活动前一个季度关闭在访谈期间映射截止日期,而不是事后

Output shape

输出形态

Produce two artifacts:
  • Portfolio plan - the year's events in a table (event, date, objective, model and tier, fully loaded cost, threshold, owner), the allocation split, the unallocated reserve, and the shortlist of events deliberately declined with the reason.
  • Per-event one-pager - objective, audience evidence, package line items, negotiated extras, activation plan, staffing roster and rhythm, tracking setup, threshold, and the post-event verdict once it exists.
Templates for both are in references/event-scorecard.md and references/sponsorship-roi-model.md.
生成两个交付物:
  • 组合计划 ——当年活动表格(活动、日期、目标、模式和级别、完全加载成本、阈值、负责人)、分配拆分、未分配储备金,以及刻意拒绝的活动短清单及原因。
  • 每活动一页纸 ——目标、观众证据、套餐细项、谈判附加项、激活计划、人员名册和节奏、跟踪设置、阈值,以及存在后的活动后判定。
两者的模板在 references/event-scorecard.md 和 references/sponsorship-roi-model.md 中。

References

参考

  • references/event-scorecard.md - weighted qualification scorecard, worked strong/weak examples, organizer evidence request, portfolio plan template.
  • references/sponsorship-roi-model.md - cost worksheet, metric definitions, tracking mechanics, worked ROI calculation, per-event one-pager template.
  • references/activation-playbooks.md - five activation types, staffing rhythms, staff brief, positive/negative booth examples, follow-up sequences.
  • references/published-price-ladders.md - sourced 2026 tier and add-on prices, the booth price floor, the tier-name comparison trap, and how to build your own yearly band table.
  • See
    samber/developer-relations-skills@conference-cfp-submission
    for winning a stage slot the sponsorship cannot buy.
  • See
    samber/developer-relations-skills@developer-live-demo-design
    for any demo that runs live at the booth or in a sponsored workshop.
  • See
    samber/developer-relations-skills@developer-meetup-program
    for running your own recurring event instead of sponsoring someone else's.
  • See
    samber/developer-relations-skills@oss-sponsors-brand-strategy
    for sponsoring open-source projects and maintainers.
  • See
    samber/developer-relations-skills@devrel-budget-allocation
    for the split between events and the other DevRel pillars.
  • See
    samber/developer-relations-skills@devrel-metrics
    for the program-level measurement framework these event metrics roll up into.
  • references/event-scorecard.md - 加权资格审查记分卡、强/弱示例、组织者证据请求、组合计划模板。
  • references/sponsorship-roi-model.md - 成本工作表、指标定义、跟踪机制、完整ROI计算、每活动一页纸模板。
  • references/activation-playbooks.md - 五种激活类型、值班节奏、员工简报、正面/负面展位示例、跟进序列。
  • references/published-price-ladders.md - 有来源的2026年级别和附加项价格、展位价格下限、级别名称比较陷阱,以及如何构建自己的年度档次表。
  • 参见
    samber/developer-relations-skills@conference-cfp-submission
    了解如何赢得赞助买不到的舞台时段。
  • 参见
    samber/developer-relations-skills@developer-live-demo-design
    了解在展位或赞助workshop中运行的任何现场演示。
  • 参见
    samber/developer-relations-skills@developer-meetup-program
    了解运营自己的常设活动而不是赞助别人的。
  • 参见
    samber/developer-relations-skills@oss-sponsors-brand-strategy
    了解赞助开源项目和维护者。
  • 参见
    samber/developer-relations-skills@devrel-budget-allocation
    了解活动与其他DevRel支柱之间的分配。
  • 参见
    samber/developer-relations-skills@devrel-metrics
    了解这些活动指标汇入的项目级测量框架。