Open source is, at least in part, about you, where “you” refers to the\nuser.
\nIn other words: Rich Hickey was wrong when he wrote “Open Source Is Not About You” and I’m tired of pretending otherwise.
\nOf course he’s not completely wrong, or his famous post would not have\nresonated quite so much in the first place. Obnoxious users who demand their\npersonal use-cases be immediately addressed by volunteer maintainers for free\nshould indeed be viewed as the pariahs that they are. Similarly, corporate\nusers who want free support from the community that supplies their\ninfrastructure to lower their costs. As should those who\nprofit\nfrom this type of externalization by their own customers.
\nBut the exchange of “open source” (or even “free software”) is not as simple as “I have prepared some software for you, please enjoy it, you have no right to complain”, and maintainers ought to have a precise understanding of the costs and benefits — as well as the ethical implications — of that exchange.
\nRight now we barely even articulate that the exchange exists, let alone that\nit establishes a long-term, subtle, and implicit relationship between\nmaintainer and user.
\nLet’s fix that.
\nWhen we talk about “obligations” and “rights”, of “shoulds” and “musts”, we are\nconstructing an ethical system. The purpose of such a system is to develop\nsocial expectations and social consequences. There is not much use in me\ntelling you that you are transcendentally evil for failing to follow some\narbitrary recommendation that I have. But I am implying that I believe there\nshould be consequences for your behavior. I am also implying that there\nprobably already are some consequences, and they’re just not written down\nanywhere yet.
\nTherefore, a post like this, where I say that we should view our social\nobligations in a certain way, that is the beginning of a broader social\nconversation. I think there should be some consequences, so I am gesturing\ntowards that possibility. Exactly what consequences?
\nFor now, I’m not sure. Let’s figure it out.
\nHickey, and his many acolytes in the years since his fateful post, asserts that the process of “open source” goes like this:
\nHe makes various oblique references to the specific activities of his company,\nwhich does things vaguely related to his projects for money<sup>1</sup>. These\nactivities are exclusively characterized as for “customers”, however, a subset\nof the aforementioned users so tiny (“fewer than 1%”) as to nearly be an\nentirely distinct group.
\nBreezing past this process in an essay about obnoxious users demanding things they are not entitled to, one might nod along, as this sounds mostly sensible. Giving gifts is nice. I too love working with good teams and taking pride in things.
\nExamined more closely, however, it starts to logically fall apart. If you have\nconsulting clients and that’s where all of your money is coming from, why are\nyou bothering (as he repeatedly insists) “doing [things] for the community”?\nWhat was the point of releasing this code in the first place? You could love\nworking with your team and be proud of the work that you do in a lot of\ndifferent contexts; why bother implicating this horde of entitled and obnoxious\npeople, if that’s all you’re getting out of it? What’s in it for you?
\nIf we’ve left out something as fundamental as “why is the maintainer doing\nthis”, perhaps this story leaves out some other important bits as well.
\nThere are many possible motivations for releasing and maintaining open source\nsoftware. They are often subtle, often overlapping, and rarely clearly stated.\nMaintainers are not a monolith and not everyone does it for similar reasons.\nBut let’s review a few reasons that someone might want to contribute.
\nOne reason that you might want to release some open source software is\nadvertising. The most common form of this is self-promotion; if you are a\nvisible, prominent contributor to an open source project, it stands to reason\nthat you will have an easier time finding work in the domain of that project.
\nIf you operate a consultancy, as Rich Hickey did at the time of his famous rant, then this reputational currency translates into advertising for your services. It’s a practical demonstration of the skills of your team.
\nThe trade in this benefit is most like the traditional “gift economy” that open source has been compared to. You give the code to your users, which has some value, but the users give you back some reputation, in the form of their attention, their esteem, and possibly even their money if they become customers or employers.
\nInfrastructure is the most popular type of open source for a good reason. Programmers working on a problem are often hemmed in by sclerotic architectural choices which prevent them from solving problems in the way that they’d prefer to solve them. Major infrastructural investments are difficult to justify in a planning process, as their benefits are hard to prove. Sometimes the benefits are highly personal; different engineers have different aesthetic preferences about what types of equally-valid solutions they’d prefer to work with.
\nIf you can develop your preferred type of solution and release it as open\nsource, then you can influence how everyone else solves this type of problem.\nAs an individual, such a position of influence can allow you to have some\ntransferable expertise between employers. You know how to use the tool you\ndeveloped, so you can be very quick and effective with it, and you can shape it\nto your ongoing taste over time.
\nIf you’re an employer, and you can get everyone else to use your open source\nthing<sup>2</sup>, this can reduce both your hiring and training costs. Potential\nemployees can read the code, see that it’s good, and want to work at a place\nthat produces good code like that. They can also read the code and become\nfamiliar with it in advance of coming to work for you, which means that you\nhave a ready supply of developers who already know how your internal systems work.
\nThe trade in this benefit is more like “soft power” than a gift economy. You give the code to your users, which has some value, but the users give you back the ability to dictate their technological agenda. You gain both the ability to influence their initial direction, and, as part of ongoing maintenance, to dictate their behavior over time.
\nAs an engineer, you might want to improve your own skills. Writing something proprietary and commercial cuts against this in two ways.
\nFirst, you will want to build something that already exists within your skill set, so that it will attract commercial interest and actually be competitive. Within the context of a larger team, you will want to personally be able to be immediately effective for similar reasons. But you still need a way to learn new things.
\nSecond, you will want to build something somewhat secretively, so that the value you are producing is captured rather than released to the community. This means that you will be cut off from external sources of expert feedback.
\nAs an organization, you might want to build the skills of your staff in similar ways.
\nThe trade in this benefit is code for knowledge. You release the code or changes, and in return you expect your users to provide you good bug reports, and to induce at least some of them to become co-developers.
\nAs an engineer, you can only do so much on your own. Perhaps you want to have\nsome influence over your infrastructure so you want to write it, but you also\nwant to have a communal place to keep your infrastructure such that you can\nmake a change to something to suit your needs, but you know that even if you\nwalk away, someone else will maintain that change and keep it working across years or even decades of changes to underlying platforms, hardware, etc.
\nThis sort of communal maintenance effort can be shared among all interested\nparticipants; if a thousand companies all need the same tool, if even a few\ndozen can share it, that reduces even their own load massively, let alone\neveryone else’s.
\nThe trade in this benefit is more complex, since there’s less symmetry between\nthe main maintainer and peripheral community members who also contribute code.\nThe main maintainer is actually trading a namespace, a central place for\npeople to contribute, coordinate, and release changes, rather than the code.\nThey are a sort of market maker where then all the other contributors trade\ncode for code within that market-ish structure.
\nIn practice, this motivation produces a game theory\nproblem where, when\nmaintenance drops below a critical threshold, it creates a big enough\ncrisis that at least some\nfreeloading stakeholders will be forced to start making contributions.
\nUltimately, however, this saves all involved parties a ton on maintenance,\nmore eager volunteers who do not freeload in the first place get all the other\nbenefits mentioned above as well.
\nMost companies account for open source maintenance work as simple overhead on ongoing projects. Sometimes it’s CapEx, sometimes it’s OpEx, but it’s just “whoever happens to be working on this thing to support whatever random product it’s a part of”.
\nThis type of accounting creates distorting incentives, because it doesn’t recognize all the benefits above. Under such a fiscal regime, ongoing healthy maintenance becomes a ZIRP because when resources are more constrained, this apparent indulgence gets corrected.
\nThe ancillary benefits that open source creates ought to be properly\nrecognized. It shouldn’t just be buried as Wages or IT or whatever. If it’s\nhelping you hire better engineers, some of that expense should be allocated to\nRecruitment Costs. If it’s materially improving your reputation among your\ncustomer base, some of it should go to Goodwill. If it’s getting your product\nin front of developers who are your customers, it should be in Marketing. Most\nimportantly, if maintenance on an open source project is actually helping you\nmaintain your enterprise-wide platform, it should not be squirreled away in\nsome small team who happened to be the first one to adopt it.<sup>3</sup>
\nExactly how these costs should be allocated and cross-charged to different departments depends heavily upon your organization and your specific chart of accounts. But “whatever, it’s just part of the software product” or “I guess it’s DevRel because the SDK is in there” is guaranteed to have your open source organization destroyed along with all those side-benefits the next time that there’s a cash crunch.
\nThese categories could be made as explicit, rational trade-offs, even if they\nare often implicit and subtle in practice. They are transactions where the\nmaintainer gets something and the user gets something.
\nHowever, not everything that you are getting as a maintainer is something you\nare actually supposed to use to your own benefit. Being given trust in\nservice of a responsibility is not a transaction.
\nOpen source code is code. In our modern world of absolutely pathetic\nsandboxing,\ninstalling code from somebody else gives them control over your system, even if\nit is somewhat indirect.
\nThere is an unwritten rule that if I create an open source library, and you use\nit, it probably shouldn’t have a backdoor in it that gives me the credentials\nto your bank account. There is a trust relationship between the user and the\nmaintainer, and here, we see the first obligation that the maintainer has.\nThe maintainer is obligated *not to use the user’s computer for their own\ngain*.
\nThis rule might seem obvious and straightforward. It might even seem unfair to\nyou that I call the rule “unwritten”, because the rule is, in fact, written\ndown in a few places: for example, in the npm Acceptable Content\nPolicy,\nit says right there:
\nA few examples of unacceptable content:
\n…
\nI think we can all agree that a script which steals your bank credentials and sends them to me to buy a totally sick jet ski would qualify as “malware”, so clearly that is forbidden.
\nThere is also an enormous gray area here. npm also explicitly allows\n“Information on how to pay, donate to, and otherwise support Package\ndevelopment”, but then goes on to explicitly forbid “Packages that display\nads at runtime, on installation, or at other stages of the software development\nlifecycle, such as via npm scripts.”<sup>4</sup> How are the lines drawn around these\ngray areas? “npm will continue to apply its judgment when deciding what\ncontent is acceptable.”
\nBut also... this is forbidden by npm, not by the transcendental nature of\n“open source”. I could give away code that displays all kinds of ads to its\nusers as a “gift” on my website. The exact structure of this policy is not\nuncommon, but it also isn’t exactly the same as other such sites. PyPI, for\nexample,\nexplicitly bans “cryptocurrency mining”, which NPM does not. Is cryptocurrency\nmining “not open source”? A lot of judgement calls are happening here about\nwhat is allowable in these “gifts” that you are giving to your users.
\nBut I digress.
\nMy point is that policy-making around this concept is not clear, there are lots\nof little disagreements around the edges, but there is a very strong consensus\nthat while the user is giving you their trust here, that is not a trade.\nThe deal is not “you give the user some code, the user gives you unlimited\ncompute and access to all their financial accounts”. The user has made\nthemselves vulnerable to your code on the strength of your reputation.
\nThis creates an obligation for you to not do anything evil with that code, either intentionally or through negligence.
\nAll of this is just about the initial download of some code, and that is the way that Rich Hickey describes it, as if you just grabbed some code off a web page and put it in a folder that you like on your desktop. But that is not how open source relationships work today, if indeed it ever was.
\nThe way it works today is that you add a dependency to your pyproject.toml or\nyour package.json or your Cargo.toml and now your users are vulnerable not\njust to whatever you happened to upload in the first place, but to *whoever\nhappens to have your package index credentials*.
This creates an obligation to maintain an operational security posture that protects your users from malicious updates.
\nAnother kind of trust that the user is placing in you is the trust that you are\ngoing to have at least some kind of regard for their usage of your software.
\nIn a perfect world, the user’s expectations could be clearly circumscribed. Whatever ongoing maintenance you commit to perform would be encapsulated in clear policies that you’d write up in advance, about exactly what kind of security response policy you have, how you will communicate when you no longer have the resources for maintenance, and so on.
\nBut anyone who has been involved in any project at anything but the most extreme tier of operational maturity knows that 99% of the ecosystem relies on a set of loose conventions around how all that stuff works. We expect that maintainers will generally be around, that they’ll use existing tools like an issue tracker for triaging user bugs, GHSA and CVEs for security reporting, that they will mark the project as “archived” and maybe do a final release before abandoning it, that they will maintain a ChangeLog explaining at least a little bit of what is going on.
\nUsers assume that those conventions will be followed when there are any gaps in\nexplicit policy, or indeed if policy is lacking entirely. This assumption is\nreasonable, because otherwise nobody could ever use any open source without a\nstack of service contracts that nobody has any time to write.
\nThe strongest such convention is that an actively maintained program will, at\nleast, more or less keep doing what it does as time goes on. A user who has\nelected to use a bit of open source software has made themselves vulnerable to\nchanges and breakages in that software by the mere fact of using it. In the\ntime that they have used it and invested in it, they have not invested in:
\nThis can, and does, go badly wrong, when those expectations are mismatched.
\nLet’s say a maintainer creates an open source paint program, OpenPaint.
\nAn artist, known for their unique style of making blended collages, switches from their previous app, ProprietaryPaint, to this new OpenPaint to make these culturally significant works of art. However, the maintainer decides that the ‘blend’ tool is kind of a pain to maintain, and they remove it in OpenPaint 2.
\nA few months later, the artist’s operating system vendor issues a security update that breaks OpenPaint, because older versions of OpenPaint were unknowingly abusing some platform API.
\nThe maintainer releases a new OpenPaint 2.0.1 that addresses this incompatibility, but doesn’t care about version 1.x any more so they don’t bother to update that one.
\nThis places the artist in an impossible situation. They can stay on an old version of their operating system, putting all their personal data at risk. Or they can upgrade to the new operating system, effectively either cutting off access to their livelihood, or forcing them to change their art style entirely.
\nNow, proprietary software can place users in similarly untenable positions (and\nin fact, it is more often proprietary software that does). But does the\nopenness completely remove any obligation for this consideration? Should\nthe OpenPaint team have to at least communicate the reasons for doing this,\nto give the artist some recourse?<sup>5</sup>
\nThe only thing that “open source” does is that it allows the artist to pay a prohibitive amount of money to a new maintenance team to create a fork. This is rarely the kind of thing that individuals can manage.
\nThis creates an obligation to *at least consider how your users might be\nrelying on you*.
\nThis is the most complex obligation of the bunch. Obviously it does not\nentitle every single user to infinite work from the maintainer, but it also\nshouldn’t entitle the user to nothing for having trusted these subtle implied\nclaims that the maintainer is making by making their work public.
\nIt is a nuanced and ongoing negotiation and I do not think we have a clear moral intuition about how it should work out. But we do need to figure out a way to work it out.
\nIt also raises a clarifying question.
\nPeople generally like to do things for more than one reason. We live in an economy where people need to make money, but we mostly prefer to make that money doing things that are useful, and that make other people happy.
\nSo, yes, we create open source for self-interested reasons to improve our\nreputations, to improve our skills, to increase our influence and to share our\nmaintenance burdens. In so doing we take on some level of obligation to not\nabuse the trust that is placed in us, even if that level of obligation is not\nclear.
\nBut if we are not doing it to serve those users at least a little bit, then\nthose motivations are going to quickly ring hollow. We will not increase our\nreputation with a person if we respond to their every request by telling them\nthat we owe them nothing and that their opinions are worthless. We will not\ngain influence over a community if we ignore their desires.
\nMany interactions with open source maintainers are unnecessarily adversarial. This is of course partially the fault of those users, who should calibrate their expectations appropriately.
\nStill: maintainers could do a better job of listening before these\ninteractions become toxic. There’s no reason that “open source users” should\nbe an especially toxic group of people. At this point in history, that group\nis basically just … people with computers.
\nIt’s like that old truism. If you meet one person who is a jerk to you, that’s their problem. But if everyone you meet, everywhere you go, is constantly abrasive to you and treats you like you’re doing something wrong, maybe it’s time to look inward.
\nIf all open source users are entitled assholes, maybe it’s time to look for a structural problem.
\nSigh.<sup>6</sup>
\nUsers hate slop.
\nI know, dear AI-positive reader, your AI outputs are different from everyone\nelse’s, you aren’t pushing thoughtless slop into your code, just because\neveryone else is and it is the inevitable terminus of using those tools. You\naren’t “lazy vibe coding” with Claude, you’re doing “responsible agentic\nengineering”, which is different because you’re just built different.
\nStill, humor me, for a moment. Your users don’t know that. They know what\nit looks like when products that they like adopt slop. They know that they\nwill start leaking\ndata.\nDevelopers know that it will make them personally less\nsecure.\nThey know that they can expect more\noutages\nand that your code will inexorably decline in\nquality.
\nIn other words, your users are going to assume that this means you are\nviolating that final obligation that the software should keep working.
\nYour users are going to tell you to stop, and they are probably going to get\nmad. Maybe you, or a plurality of your team, also want to stop, maybe you\ndisagree with them, but in any case you need some way to *have that\nconversation* in a way that does not immediately overflow into every adjacent\ndiscussion forum. Users need to feel welcome in some space so they can have\nthe discussion in that space, and not explode out into a thousand different\ngroup chats and social media threads.
\nThis post was inspired by yet another prominent open source community\ndiscourse where a ton of angry users showed up to yell at developers to stop\naccepting LLM-generated code. I’m not going to link to any of these, because\nwe don’t need any more fuel for the discourse fire. But there is more than one\nsuch case and the pattern is becoming familiar.
\nOn social media - usually BlueSky or Mastodon, but sometimes a user group\nforum - users become aware of some AI-adjacent policy. They show up in a horde\nto the developer forum or mailing list. They loudly start demanding the\nproject take a hard stand<sup>7</sup> against AI. This pressure is simultaneous, but\nuncoordinated; extremely repetitive, very diverse, often inconsistent, and\npretty stressful, especially if you’re a burnt-out maintainer with other things\nto be doing who may not even like AI yourself in the first place.
\nBelieve me, I get it. It can be very unpleasant to deal with.
\nLike most problems that AI is causing, though, it’s not really an “AI” problem\nas much as it is a pre-existing dumpster fire that “AI” is pouring gasoline\nonto. In this case, an online mob is the language of the unheard<sup>8</sup>.
\nOne day, all of a sudden, you’re getting feedback from a bunch of users that\nare using inappropriate channels to complain. But did they already have\nappropriate channels to use?
\nDid you have a place for people to congregate and discuss your project? To make orderly complaints in a way that will be legible to you? Or do you just have a GitHub Issues page, which non-technical users have no idea how to interact with, and a forum for developers, where users don’t know the norms and any arriving brigade of pissed-off users will be seen as disruptive and inappropriate?
\nI don’t want to be throwing any stones from within my particular glass house. Setting up such a place has gotten harder over the years. I don’t really have one, either.
\nCould I have one, though? IRC has been slowly dying, mailing lists are\nunpopular and present increasingly annoying moderation challenges, forum\nsoftware is expensive to operate and keep maintained, Discord is a confusing\nmess and the upshot of all of this is every community needs community\nmanagement and forum moderation. Which means that for my own small solo\nprojects, I couldn’t possibly have such infrastructure because such\ninfrastructure requires a dedicated second person to maintain it, and until\nsomeone volunteers for that, it’s not really feasible. Even for my larger\nprojects you’d be surprised how slim of a skeleton crew\nwe are getting by with, and we definitely don’t have a whole spare maintainer\nto go manage this, especially as we are under attack from the slopocalypse\nourselves.
\nThe nature of open source community is that most communities start too small to\nneed such a thing, grow incrementally until one day they are suddenly way too\nbig and needed one yesterday, and then suddenly they are too small again when\ninterest wanes even a little bit. Even as we need it more and more, building\nand maintaining community infrastructure remains a challenge.
\nEven so, having a dedicated place for users — not maintainers — to converse\namongst themselves, be an actual community, and present feedback to the\ndevelopers, is fast becoming a necessary component of a successful community\nand not a nice-to-have.
\nAs trying as it can be sometimes, we maintainers all do get something out of\nopen source, and it is good to be honest with your users — and with yourself —\nexactly what you want to get out of it. In order to know whether the juice\nis worth the\nsqueeze, we\nmust know both what the juice is, and what the squeeze is.
\nPart of the metaphorical squeeze is a set of obligations, and those are the\nmost poorly defined of all. We should try to be clear about what those are\ntoo. Both about exactly what we believe we are signing up for, and also, about\nhow we are willing to let our users hold us to account for them. Codes of\nconduct are a start here, but only the absolute barest bare minimum; “do not\nharass your colleagues or your users” is not a standard of excellence to aspire\nto, it’s just basic manners.
\nI can’t tell you exactly what your obligations are, only try to gesture at my idea of the outlines of the fuzzy moral intuition we’ve all been implicitly sharing up until now.
\nDrawing this line is not just for the benefit of the users, either.\nMaintainers already feel pressure, we already feel obligations. We resent\nthat feeling of obligation. While there are a diverse array of reasons for that\nresentment, one big one is that it’s not clear, even to ourselves *where the\nobligations end*. Lashing out by saying “I promised nothing and I owe you\nnothing!” followed by some choice expletives feels cathartic, but it doesn’t\nreally solve the problem, because we clearly don’t really believe that’s where\nthe line is, or we would have already stopped there. We wouldn’t feel the need\nto say it.
\nIt is going to be a very big collective endeavor to figure out exactly where that line is. The best time to have gotten started on that endeavor was 50 years ago.
\nBut the second best time is today.
\nThank you to my patrons who are supporting my writing on\nthis blog. If you like what you’ve read here and you’d like to read more of\nit, or you’d like to support my various open-source\nendeavors, you can support my work as a\nsponsor!<sup>9</sup>
\nSomewhat to everyone’s surprise, I, too, do things for money, like writing this post. Please remember to like and subscribe ↩
\nWhether it was originally yours, or developed by an employee who happened to be on staff at the time, or adopted by an employee who just started contributing to it a lot, in any of these scenarios a company can benefit from increased consistency and increased familiarity. ↩
\nIf the rule is that they must forever endure the searing budgetary pain of gripping the white-hot potato that they unwittingly caught when they first made a good technical choice, this creates a perverse long-term incentive. ↩
\nI also find it darkly amusing that there is an explicit affordance here made for advertising, specifically, “Packages with code that can be used to display ads are fine. Packages that themselves display ads are not.” This distinction rather gives the game away, that this is a website for carnies and not for marks, and that at some level we expect our users to deserve a lower level of respect than ourselves. But a full exploration of that is another blog post, or maybe a book, that I don’t have time to write right now. ↩
\nIf you want the turbocharged ultra-dramatic version of this problem, make it open source drivers for an optical prosthesis that lets the users see instead of an art app. That level of immediate physical dependency could\nbe clarifying. It does also start to edge into an area where you could say\nthat biomedical devices ought to be regulated differently, and that’s not\nreally a “software” problem but a “healthcare” problem and I’d mostly\nagree. Except for the fact that this is avery short distance away from\nbreaking everyone’s screen-reader with no notice or\nrecourse. ↩
\nDid you believe I could write a blog post in 2026 which wasn’t somehow about AI? I wish I could still believe that. ↩
\nIt doesn’t help that many of the most pro-AI voices are starting to have an, ahem, discernible political valence that is very unpopular among users. ↩
\nMy apologies to MLK. ↩
\nIf you read this whole post you can see that I sure need the help with all that. ↩
","headings":[{"level":1,"text":"Who Is Open Source About?","id":"who-is-open-source-about"},{"level":2,"text":"Open Source Is Not About “Open Source Is Not About You”","id":"open-source-is-not-about-open-source-is-not-about-you"},{"level":3,"text":"A Brief Aside about Meta-Ethics","id":"a-brief-aside-about-meta-ethics"},{"level":2,"text":"What Are We Doing When We Do An Open Source?","id":"what-are-we-doing-when-we-do-an-open-source"},{"level":2,"text":"Why Are You Doing This?","id":"why-are-you-doing-this"},{"level":3,"text":"Reputation","id":"reputation"},{"level":3,"text":"Influence","id":"influence"},{"level":3,"text":"Improvement","id":"improvement"},{"level":3,"text":"Outsourcing","id":"outsourcing"},{"level":3,"text":"A Brief Aside about your Chart of Accounts","id":"a-brief-aside-about-your-chart-of-accounts"},{"level":2,"text":"The Things that Aren’t Supposed To Be Benefits","id":"the-things-that-aren-t-supposed-to-be-benefits"},{"level":3,"text":"“Oops, All Root Shells”","id":"oops-all-root-shells"},{"level":3,"text":"The Roadmap Is Someone’s Life","id":"the-roadmap-is-someone-s-life"},{"level":2,"text":"Why Are We Even Doing This, and Who Are We Doing It For?","id":"why-are-we-even-doing-this-and-who-are-we-doing-it-for"},{"level":3,"text":"Surprise, It’s About AI Again","id":"surprise-it-s-about-ai-again"},{"level":2,"text":"If Users Are Mad It’s Probably Already Too Late (But Maybe You Can Get Ready For Next Time)","id":"if-users-are-mad-it-s-probably-already-too-late-but-maybe-you-ca"},{"level":2,"text":"In Conclusion","id":"in-conclusion"},{"level":2,"text":"Acknowledgments","id":"acknowledgments"}]}}