共计 10392 个字符，预计需要花费 26 分钟才能阅读完成。
GitLab 在 2021 年实现了 IPO，在纳斯达克胜利上市，而且的确是没有地址（参见下图）。
我 2015 年 10 月退出了 GitLab，在那儿打了六年工，在 2021 年 12 月来到。
只管之前我写过来到 GitLab 去 Inko 的事件，但从未探讨过在 2015-2021 年间为 GitLab 工作的经验。有两个起因：
- 过后我疲劳过度，没有精力回顾我生存中近六年的工夫
- 我仍受到 24 个月 NDA（窃密协定）的束缚，不确定是否在不违反协定的状况下探讨多少内容，只管这可能并不会引起任何问题
NDA 去年 12 月曾经到期，尽管我狐疑本人仍在和疲劳过度带来的结果奋斗，但当初有更多精力回顾我 GitLab 的时光了。
本文将分为两个次要局部：依据我还记得的内容概述我的 GitLab 时光以及基于工作和教训所学到的一些货色。
纲要
- GitLab 之前
- 2015-2017
- 2017-2018
- 2019-2021
经验教训
- 可扩展性须要成为公司文化的一部分
- 团队须要由数据和开发者驱动
- 没有数据，无奈确定最小可行性产品 MVP 长啥样
- SaaS 和自托管互不相容
- 更多的人不意味着更好的后果
- 对于应用 Ruby on Rails 的矛盾心理
- 部署代码所需的工夫对组织的胜利至关重要
- 依照地区定薪资是一种歧视
- 总结一下
GitLab 之前
在退出 GitLab 之前，我曾在阿姆斯特丹的一家小型初创公司工作。像大多数初创公司一样，在我到职前的几个月里，公司开始资金短缺，不得不采取一些极其的解决方案，比方出租局部办公空间。与此同时，我感觉本人在技术层面曾经做了想做和能做的所有事件。
与此同时，我还利用业余时间参加 Rubinius 我的项目，并思考过在某些场景应用它，确保咱们所有代码都能够顺利运行。这也促成了 Oga 的诞生，一个作为 Nokogiri 替代品的 XML/HTML 解析库。
可怜的是，资金短缺以及各种技术问题意味着咱们从未推动 Rubinius 的应用。多种因素叠加，我开始寻找新工作，至多这样我能够花更多工夫来改良 Rubinius，使其足够稳固以供人们在生产环境中应用。
在此期间，我加入了阿姆斯特丹各种 Ruby 见面会，并帮助组织了几次 Rails Girls 研讨会。在其中一个研讨会上，我遇到了 GitLab CEO Sytse 和他妻子，并再次在之后另一个研讨会或 meetup（应该是，但我记忆有点含糊）。通过这个机会，我理解到了 GitLab 并对去那里工作产生趣味。
2015 年夏天，我给 Sytse 发邮件，示意心愿为 GitLab 工作并询问他们是否违心我每周一天用于开发 Rubinius。随后进行了一些谈话和面试，我于 2015 年 10 月以 第 28 号员工身份开始就任于 GitLab。我负责进步 GitLab 性能，并被容许将 20% 的工夫投入到 Rubinius 我的项目中。
退职期间，我参加过很多团队，领有很大水平上自主权，多年间向 10 位不同经理汇报过，差点使公司濒临开张，构建了 GitLab 至今依然应用着各种要害组件，目击公司从 30 多名员工增长到约 2000 名员工，并最终陷入倦怠状态，或者用荷兰俗语说: “Lekker gewerkt,pik!”（干得好，笨蛋！）
2015-2017
我之前那份工作的 last day 是 9 月 30 日，一个星期三，紧接着第二天我就开始在 GitLab 工作。也就是说我从每周五天在办公室工作变成了每周五天近程办公。尽管以前也在家工作过，次要是当火车因为积雪或树叶而停运，适应新的安顿还是须要一点工夫。
那段时间有一个特地粗浅的记忆是我白天提着袋子买菜回家，并意识到白天做这件事比上班后早晨回家时更惬意。
另一个记忆是和我的猫一起在沙发上小憩，过后拍下了这张照片：
是的，那是荷马辛普森拖鞋。
过后我租住的公寓不大，只有一个小厨房、一个小客厅和一个小阁楼，也就是说我的客厅同时兼作卧室、客厅和办公室。尽管这不是很现实的布局，但那时我只能负担得起这个，兴许低廉的 Aeron 椅子与此有关。
只管 GitLab 是一家齐全近程公司，但它也是社交型公司，常常举办团聚和流动。例如，在我退出后几周，公司在阿姆斯特丹举办了一次团聚，白天进行各种流动，并在早晨共进晚餐：
过后，整个公司还能够塞进餐厅的一个角落里。
不久之后，GitLab 迎来了第一次暴发式增长，大概新增了 100 名员工（应该是？我的记忆有点含糊）。到了 2016 年奥斯丁的下次公司团聚时，一个餐厅的角落曾经不够了：
在这段时间里，也有一些负面经验。GitLab 蒙受了蹩脚的性能、频繁的宕机（简直每周都有），治理不善以及许多其余初创企业面临的问题。这导致「GitLab 运行迟缓」成为用户最常埋怨的问题之一。尤其是在 Hacker News 上，人们总是喜爱埋怨它，无论原始话题（例如新性能布告）是什么。当然 GitLab 意识到了这一点，他们延聘我的其中一个起因就是要解决这些问题。
这是一个挑战，特地是因为 GitLab 没有足够的性能监控基础设施。顺便说一下，并非夸大其词：过后惟一运行的服务只有一个 New Relic 试用账户，只容许监控 一个或者两个服务器 的状况（咱们那时总共应该有 15-20 台服务器）。这意味着任何数据进来都不会精确反映状况，并且使得测量和解决性能方面存在艰难。
使得解决这些问题变得更加艰难的是 GitLab 的要求：咱们应用的工具都必须对自托管客户可用，并且最好开源（或者甚至可能属于硬性要求，我记不清了）。这意味着我不仅须要改良性能，还须要构建首先进步性能所需工具。同时，在公司外部写出高效代码（或者至多不会极度迟缓）没有被视作优先事项。GitLab 还偏向于更多地听取 Hacker News 上对于投诉而非外部投诉的声音。由此产生了一个外部流传笑话：如果你心愿某事扭转，请匿名在 Hacker News 上吐槽，这比通过适当渠道提出更无效。
接下来数月工夫里我致力改善性能、构建必要工具、尝试扭转公司文化 / 态度以便随着时间推移真正实现改良，并解决 GitLab 对已做出改良并不称心所带来的挑战。我分明地记得至多进行过几次视频通话，在其中差点忍不住对 Sytse 大声吼叫起来，还好从未真的产生过。
只管面临这些挑战，我还是设法建设了必要的工具，并在各个局部改良了性能（其中一些是很重要的，其余则不那么重要）。这些工具成为一个名为「GitLab 性能监控」的官网 GitLab 性能，只管多年来曾经产生了很大变动。我另外构建的一个工具是 Sherlock，一个用于开发环境的高级分析器。
在此期间，GitLab 开始意识到仅靠一个人无奈解决这类问题，特地是如果性能不是公司其余部门的首要任务。由此带来的变动之一是，我不再间接向 Sytse 汇报，而是作为新性能团队的成员向专门的经理汇报，并且该团队有估算能够雇佣更多人员。我记不清具体估算数额是多少了，但并不多：可能只有两个或三个人。思考到公司总规模以及其次要关注点是尽可能推出更多功能而言，这远远不够，但却算得上一个开始。
我的第二年中很大一部分工夫都花在了这支团队中，在那里略微有些喘息空间。我持续争取取得更多资源，并将良好性能作为新代码所需满足条件之一进行提倡，但后果参差不齐；同时咱们整个团队也在继续改良性能。
与此同时，GitLab 也经验了第一波裁员和到职潮，次要起因是 GitLab 最后招聘了些谬误的人才。这意味着 GitLab 从 30+ 增长至（据我所知）130+ 名员工，而后缩减至 80+，再开始增长。
至于 Rubinius：只管咱们试图让 GitLab 在 Rubinius 上运行，咱们从未胜利过。联合 Rubinius 我的项目负责人心愿将我的项目带入另一方向以及由此引起 Ruby 社区内争议等因素，咱们最终决定放弃 Rubinius 我的项目；我也进行全力投入其中。这很遗憾，Rubinius 多年来积攒了许多劣势，却最终受制于我的项目负责人的治理形式，而无奈胜利倒退。
2017-2018
通过最后 1.5 年的艰巨期间，状况开始有所改善。绩效大幅晋升，GitLab 开始更加认真地看待这一问题。招聘流程失去了很大改善，就像下棋一样，GitLab 开始将适合的人放在适合的地位上。性能团队的边界也产生了变动：不再专一于总体性能，而是将重点放在数据库性能上，并且作为此举的一部分被重新命名为数据库团队。随着这一变动还带来了更多用于招聘人员的估算，并指定基础设施工程师来帮助咱们进行例如筹备新数据库等工作。
我在此期间构建的一个至关重要性能是 GitLab 的数据库负载均衡器，布告在此。该性能容许开发人员持续像平常一样编写他们的数据库查问语句，而负载均衡器会负责确保不将这些查问发送到正本或主库中。执行写操作后，负载均衡器确保主数据库被应用直到所有正本都可用于已写入更改之前，通常称为粘滞位 (sticking)。引入负载均衡器对性能产生了显著和踊跃影响，我置信如果没有这个负载平衡器，GitLab 可能会陷入麻烦。我最骄傲的是能够通明地引入这个零碎。迄今为止我还没有看到一个（更别说 Ruby on Rails）你只需增加到我的项目中并立刻投入使用就好的数据库负载平衡器。相同，现有的解决方案更像是仅提供了拼图，须要你本人把所有货色粘合起来，1111 通常没有任何模式反对粘滞。遗憾的是咱们从未想过将其提取成独立库。
这段时间不仅是我在 GitLab 和整个职业生涯中极具生产力和改良的期间，也标记着我在 GitLab 工作中最低谷和最可怕的时刻：1 月 31 日，在经验了一天长时间而缓和的解决许多问题后，直到深夜问题仍然存在，我意外 解决了 GitLab 的性能问题 删除了 GitLab 的生产数据库。随后发现咱们没有任何备份，因为零碎很长一段时间都没有运行，并且负责告诉咱们任何备份谬误的零碎也未失常工作。最终咱们进行了复原，因为当天我将生产数据复制到咱们的演示环境大概六个小时前就已实现这部分工作，只管过程破费了大概 24 小时。尽管失去约六小时数据无疑是十分蹩脚的事件，但如果过后没有做备份会产生什么事件我并不确定。能够说那一天我的心跳停了几拍，并且必定多了几根白发。
在此期间一个重复引起挫折感的起因是即便引入数据库负载均衡器之后 GitLab 仍心愿对数据库进行分片。不仅我、其余工程师以及我的经理认为这种办法并非解决方案所需之处，并且咱们还有数据反对这一观点。例如，在 GitLab 中读操作远远超过写操作（比例大抵为 10:1），分片只有在写操作显著多于读操作时才有用。此外，咱们存储数据量远远不足以证实引入分片技术所需复杂度合理化。我分明地记得参谋也说过相似「请勿介意，然而咱们有客户负载和存储量高出数个数量级，即便对他们来说应用分片也属于杀鸡用牛刀」。尽管如此，Gitlab 在接下来几年里持续推动该打算，直至管理层做出放弃决定，而后再次提出（只是换一个稍微不同名字或想法）到我来到为止。
2019-2021
在 2018 至 2019 年间，我从数据库团队转入了一个新成立的交付团队，因为我曾经厌倦了过来四年始终致力于性能和可靠性工作。此外，当初有多人正在解决性能和可靠性问题，所以我感觉是时候做点新事件了。这个新团队的指标是改良 GitLab 的公布流程和工具，因为过后这方面的情况最好形容为凌乱。
例如，咱们考察了提交到主分支并部署更改到 GitLab.com 之间须要多长时间。结果显示均匀要几天，但在最蹩脚的状况下可能要长达三周。次要瓶颈在于 GitLab 社区版和企业版之间存在拆散，存在不同的 Git 仓库中，并且须要定期手动合并和解决抵触。这导致咱们破费数月工夫将两个我的项目合并为一个我的项目。尽管咱们将工作划分为前端和后端，并让各个团队负责向致力做出奉献，但最终我施行了大部分与后端相干的更改，另一位共事则负责大部分前端工作。
在此期间与团队其余成员一起，在公布流程方面获得了显著停顿，并且咱们达到能够在几小时内部署更改的阶段。只管这远远没有达到应有速度，从原来可能需三周的最差情景变成一天是最差情景，也是一个重大提高。
与以往期间一样，这段时间也并非没有动荡和变动。
2018 年是咱们最初一次举办以员工为核心的 GitLab 峰会，而 2019 年及其后的几年则更像传统会议模式，更侧重于客户而不是员工。从财务角度来看，组织 2000+ 人的团聚老本极高是能够了解的。从社交角度来看，这是一个损失，因为峰会更商业化的设置远不如旧模式乏味。我对 Sytse 在舞台上跳舞以回应团队博得较量或者 Sytse 和他的妻子衣着长颈鹿服装上健身课等美好记忆仍历历在目。这些滑稽事件在接下来的几年中将不再产生。
而后就有了笔记本电脑治理的问题：人们要求公司提供 Mac 笔记本，并基本上能够自行应用它们，或者像我一样应用本人的硬件。多年来，GitLab 管理层开始探讨应用软件远程管理笔记本电脑。在这些探讨中重复呈现的问题之一是所提议计划具都有侵入性（例如可能用于记录用户流动），没有任何避免滥用保障，并且员工（很多）提出意见却被忽视，直到要害员工开始向治理施加压力才引起留神。而后打算被搁置，只能在数月后从新开始探讨。
最引人注目的并非所提议扭转的内容，而是管理层解决反馈意见形式，以及总体变动散发出为了解决方案寻找问题的感觉。值得一提的是，大多参加此类探讨的人（包含我）都明确须要某种模式笔记本电脑治理（例如防盗），但认为所倡议的侵入性解决方案过头了。
GitLab 最终采纳了 SentinelOne 作为笔记本电脑治理解决方案。只管 GitLab 规定雇员必须装置该软件用于拜访 GitLab 资源，包含集体设施（至多正在思考），我（应用本人台式）不知何故胜利地避开了，并未被要求装置相干软件，或者因为我未应用公司配发的笔记本电脑，GitLab 忘了核实我的状况。
这些文化改革与我集体生存中的各种变动相结合，导致了能源、工作效率的降落，压力减少以及工作工夫不够稳固。团队经理（我认为是我遇到过最好的经理）也转岗到另一个职位，当初由一名新任经理领导团队。我和这位经理相处得并不好，造成了抵触，进而引发了「绩效激励打算 PEP」，旨在在须要「绩效改善打算 PIP」之前将事件从新纠正过去。绩效改善打算旨在作为最初一根稻草来改善员工、工作和雇主之间的关系。
让我感到不难受的是 GitLab 解决 PEP 的形式：我抵赖有须要改良的中央，但我感觉问题局部出自新经理的工作形式。管理层向我保障 PEP 旨在同时改善单方情况，并非只专一于我的晋升，还包含对经理进行调整。然而理论状况并非如此，PEP 只集中于我的需要做出不同解决，它对所需达成规范也有点模糊不清。原始打算是 PEP 继续一个月，在第一个月完结时我的经理决定缩短 PEP 一个月，因为他们认为这是必要的，并未明确阐明具体起因。我抉择抗拒，并且两个月后实现了 PEP，管理层认为后果令人满意。
乐观者会认为这可能只是第一个被放入 PEP 的员工，因而管理层必须在实践中找出解决办法。悲观者则对这一系列事件持更消极态度，但这些想法只是留在了本人心里。
在这段经验之后，我意识到兴许是时候来到了，因为 GitLab 和我正朝着不同的方向倒退，而且我过后对事物的状态感到不满。
这个机会呈现在 2021 年底：GitLab 要上市了，思考到我能行使我的股票期权的工夫，意味着我能够在 2021 年 12 月来到。因为荷兰过后期权税收政策的起因，我无奈提前来到：行使股票期权意味着必须领取全额所得税（52%）差额费用和估值之间的差额局部，即便该股票并非流动性资产。就我的状况而言，税款金额如此之高以至于无奈负担得起它，并迫使我期待直至 GitLab 上市。几个月后法律发生变化，当初你能够抉择是在行使时领取税款还是等到股票具备流动性再领取。但问题是如果你推延缴纳税款直至股票具备流动性，则需依据那个工夫点的价值来计算税款，并非基于行使股票期权时的价值。这显然并不现实且存在微小金融风险，但至多你有选择权。
因而，在取得我的股份后，在 2021 年 12 月辞职全职投入 Inko 我的项目中，并用我的贷款来付账单。
经验教训
历史聊完了，来看看我在 GitLab 工作期间学到的一些货色。要记住的一件事是，这些都基于我的集体教训，因而在某些方面可能是谬误的。
可扩展性须要成为公司文化的一部分
GitLab 犯了一个谬误，而且在我来到时仍在持续犯错，那就是对可扩展性不够器重。是的，领导们会说这很重要，并的确进行了改良，但它素来没有像其余指标那样成为首要任务。问题的外围在于 GitLab 盈利模式：次要通过客户自行托管 GitLab 企业版而非 GitLab.com 来赚钱。事实上，GitLab.com 的破费比带来的支出多得多。这天然导致对自行托管市场的关注，并且咱们在 GitLab.com 上遇到的许多性能问题并不适用于许多自行托管客户。
更加令人丧气的是，许多开发人员实际上想进步性能，但却没有取得工夫和资源去做到这一点。
团队须要由数据和开发者驱动
另一个因素是 GitLab 产品经理主导的个性。尽管一些要害开发人员可能有影响产品决策的能力（只有他们够响且够狠），但次要还是产品经理和总监决定须要做什么。有时这些决定很有情理，而其余时候仿佛齐全基于「我在 Hacker News 上读到这是个好主见，所以咱们必须做它」。
我置信如果 GitLab 晚期采纳了更简略的层级构造，而不是明天领有传统多层次层级构造，公司会体现得更好。特地是，我认为应该放弃产品经理这个概念，转而赋予团队领导更多势力，并让他们与用户互动更多。对我来说，产品经理应该做的就是：帮忙在技术水平上构建产品，同时也作为团队与其用户之间的联络人。
没有数据，无奈确定最小可行性产品 MVP 长啥样
GitLab 的外围准则之一是始终从最小可行性变更 (minimal viable change) 开始。这个想法是交付能为用户带来价值的最小可行性产品 (Minimal Viable Product)。听起来很不错，但实际上，最小的定义在人与人之间并不统一。后果是一个团队可能认为性能或者良好的可用性对于某事物是否可行至关重要，而另一个团队却满不在乎。
实际中，这导致 GitLab 多年来构建了许多并不有用的性能：一个没有人要求且最终被淘汰的无服务器平台、三周内都没人留神到治理 Kubernetes 集群性能生效、咱们必须基于 CI 提供解决方案（从而引入了显著提早）而非应用现有解决方案构建 ChatOps 解决方案，或者只反对创立和查看数据（甚至不能更新或删除）的需要治理性能；这些只是近年来几个例子。
要确定什么使某事物成为最小可行性产品，须要深刻理解指标受众的欲望。尽管 GitLab 每季度进行用户考察，并且一些团队能够拜访无关用户参与度的数据，但依据我的记忆和与其余前共事交谈所学到的状况看来，这些数据更像是偶尔应用，并非每个团队工作流程中外围局部。
SaaS 和自托管不相容
GitLab 提供两种产品类型：自托管和 SaaS。我认为大多数公司无奈无效地提供这样的设置，包含 GitLab 在内。你不仅会因为赚取更多钱而产生利益冲突（如上所述），而且这两种设置还有不同的要求和更新利用形式。
例如，对于 SaaS，你心愿可能疾速部署，并解决产生在集中基础设施上的大量数据和工作负载。鉴于大多数自托管实例与 SaaS 提供相比拟小，许多解决方案并不能实用于遇到问题时作为 SaaS 以及其对应解决方案的情景。这实际上导致平台许多局部存在两条代码门路：一条是针对 SaaS 版本，另一条是针对自托管版本。即便代码在物理上雷同（即你为自托管装置提供某种易于应用的封装器），你还是须要思考其中的差别。
相同，当你专一于 SaaS 或自托管设置中的一种时，能够将所有注意力都放在为相干设置提供最佳体验上。当然也有例外情况，但它们的确只是常见例外。
更多的人不意味着更好的后果
就像之前许多其余公司一样，GitLab 在过来几年里雇佣了大量员工，现在领有超过 2000 名员工。我不晓得其中有多少是开发人员，疾速浏览团队的页面，看起来应该至多有几百人。家喻户晓，减少我的项目中的人数并不能必然进步生产力和后果（参见《人月神话》），然而简直每家东方初创企业都会漠视这一点，并雇佣数百名开发人员，即便产品实际上并不需要那么多开发者。
我没有数据反对这一点，但我狐疑大多数公司其实并不需要超过 20 名开发者，局部可能须要 20-50 名，只有极少数须要 50-100 名。当逾越 100 个开发者时，请开始思考是否在进一步雇佣更多人之前要思考你产品范畴是否曾经失控。
请留神我这里特指软件开发人员。例如如果你正在制作定制硬件，则可能须要更多人来扩大生产流程。销售和反对也是两个畛域，在这些类型的工作中通常受害于领有更多人手，因为此类工作要求较少协调性。
对于应用 Ruby on Rails 的矛盾心理
GitLab 是用 Ruby 和 Ruby on Rails 构建的，这在很大水平上促使它获得了明天所享有的胜利。与此同时，当我的项目规模变大且贡献者教训不同档次时，这种组合也带来了挑战。特地是 Rails 让引入性能不佳的代码变得太容易了。
例如，想显示一个我的项目列表以及显示我的项目成员数量的计数器，很容易无心中引入 N+1 查问问题。尽管 Rails（或更具体地说是 ActiveRecord）提供了解决此问题的性能，但这是一种抉择机制，最终导致开发人员遗记了这一点。我在 GitLab 头几年解决的许多性能问题都波及 N+1 查问问题。
其余框架多年来从中吸取教训，并提供更好的代替计划。通常做法是，在任意查问相干数据之前必须先传递数据进去而非随后再进行查问。益处在于如果你遗记传递数据，则会遇到一些谬误而不会像按行根底查问数据那样引入性能问题。
Ruby 自身也是一个我持有不同意见的抉择。一方面，它是一种我喜爱应用将近十年的优良语言。另一方面，其大量应用元编程使得在大型项目中难以使用，即便引入了可选类型。这不是说说，多年前写 Ruby 的动态剖析工具 (https://github.com/yorickpeterse/ruby-lint) 时我亲身经历过这种状况。
尽管如此，我不确定除了 Ruby 和 Ruby on Rails 的组合之外会举荐什么替代品。诸如 Go，Rust 或 Node.js 这样的语言可能比 Ruby 更高效，但没有一个像 Ruby on Rails 那样功能强大的框架。Python 和 Django 可能是一个抉择，但我狐疑你会遇到与 Ruby 和 Ruby on Rails 类似的问题，至多在某种程度上。如果新的 Web 框架进行困扰于如何定义路由树，并更多地专一于整体生产力，则可能会有所帮忙。
对于 Inko 我有一些大抵想法该如何解决这个问题，但在开始用 Inko 编写 Web 框架之前还须要做很多其余工作。
部署代码所需的工夫对组织的胜利至关重要
这是我在退出 GitLab 前就曾经晓得的事件，因为我在以前的工作中花了大量工夫设置良好的部署和测试流水线，但在 GitLab 工作强化了这种信念：你须要可能疾速部署代码，即在将更改推送到任何分支 / 标签 / 货色后最多一个小时内。在 GitLab，咱们花了大概四年的工夫才靠近这一点，并且仍有很长的路要走。
除了显著的益处外，例如可能更无效地应答事变（无需热修补代码来解决因为部署须要数小时而导致问题），还有一种激励性益处：可能看到你做的更改实时失效是件不错的事件，因为能够理论看到并应用本人的成绩。没有比花几周工夫进行一系列更改而后再等两周能力实现部署更令人气馁了。
为达成指标，你须要缩短部署工夫以及运行测试套件所需工夫。依据应用程序类型和正在测试服务类型，在进行部署时可能会固有地须要肯定数量的测试运行工夫。这里重点不是「测试和部署绝不能超过 X 分钟」，而是（作为一个组织）将其视为优先事项，并尽可能疾速地依照业务要求进行部署。只管不言而喻，但我狐疑许多组织在这方面做得远不如他们本可做得那么出色。
依照地区定薪资是一种歧视
在 GitLab 赚的工资受到各种变量的影响，其中之一就是地点。你所在地点对工资的影响也不容忽视。当一个公司有实体办公室并须要在特定区域招聘人员时，根据地点调整薪酬可能是有情理的，否则可能无奈雇佣所需区域内必要人员。但对于没有实体办公室、在寰球设立法律实体的近程公司来说，在同样教训和责任下纯正基于居住地领取两个不同人员不同薪水没有非法理由。
举个例子：我来到 GitLab 时，我的年薪约为 12 万欧元，税前月支出约 8500 欧元。对荷兰而言这是一份不错的工资，在家全职工作很难找到提供更好条件的公司。但如果我住在旧金山湾区，我至多会赚取那个数额两倍以上甚至更多。并非因为我可能更好地实现工作或出于其余无效起因，而仅仅因为我生存在湾区而非荷兰。
无论如何解释这件事件都能够看作是一种歧视行为 – 纯正基于居住地给某人领取较少报酬与别人相比。想想看：如果一个公司因为某人肤色或性别而缩小其报酬，则该公司将陷入困境。但以居住地领取较少报酬却被认可？
如何解决这个问题？对企业来说很简略：只需依据岗位要求领取，并非申请者所处地位进行领取即可。无论你给在湾区还是菲律宾的某人报酬，薪水都是每年 10 万美元，对于企业来说老本都是一样的。至于员工们，我惟一的倡议就尝试会谈获取更高薪水了，但由此带来艰难兴许会证实辣手，因为依照地位付费通常意味着企业倔强保持。我心愿有朝一日咱们国家法规能跟上这种做法.
一个仿佛在这方面做得很好的是 0xide 公司。与其依据员工所在地领取薪水，0xide 向员工领取雷同金额，参阅此帖，我深表钦佩，并认为更多公司应该这样做。
总结一下
回顾过去，我在 GitLab 的时光是踊跃和消极经验的混合。我为所在团队获得的成就感到十分骄傲，也很快乐能与这些人一起工作，但最近一年左右让本来美妙的经验变得令人丧气。我对在 GitLab 工作没有任何遗憾，如果能够重来，我会做出一些扭转，因为有了上帝视角。只管有毛病，我依然举荐它作为一个值得工作的公司，因为我认为它毕竟比其余许多公司要做得 好多了。
💡 更多资讯，请关注 Bytebase 公号：Bytebase
