Open Letter to MoroccoAI: a Hackathon Manifesto
the hackathon efficiency logic should converge on conditions that mimic the startup building process: to accumulate capital with playful scarcity.
Dear Hackathon Organizers,
This letter is offered humbly, not to assume the moral high ground, but to share somewhat of a Carlylean perspective that might serve as a portal to the next valley of hackathons. I propose reimagining the hackathon framework as a problem-specific or sector-specific ecosystem, aligning all human capital and energy toward solving a single pre-defined problem each year. The point is two-fold: 1- Accumulate as much capital as possible, and 2- Make this process as non-standard and unsystematic as possible. Ideally, you want to have a maximum capital-to-abundance ratio— accumulating capital with playful scarcity on a single persisting problem is reflective of the actual startup building process i.e. capital accumulates towards the end goal of concentrating all energy towards getting that problem solved.
This is a very timely letter because systems tend to accumulate inertia and intolerance, gradually becoming hard to reform due to hysteresis effects— getting it right at the start is very important, otherwise just build a new structure. Any complex system that works invariably comes from a simple system that works (be careful, the opposite is not necessarily true, but that shouldn't bother us for now).
The Hackathon is more of a Startup than Athenian Democracy
Hackathons are rich with talent, yet this energy is often diluted across disparate issues. Many teams, despite their potential, select systemic or structural problems that no current technology—AI or otherwise—can solve. This dispersion of effort can lead to valuable human capital being "competed away" on less actionable issues. By concentrating resources on one well-defined problem that is urgent and meaningful to the community—such as a specific Moroccan challenge—we can ensure the hackathon becomes a focused problem-solving engine, much like an ant colony working collectively toward a single end goal.
A hackathon that works on a par with a problem-centric bounties system is much more allocatively efficient than a hackathon that throws its energy at a myriad of problems i.e. the hackathon organizers already have pre-defined problem statement— as in a real problem that persists in the real world and one that Moroccan people are in need for it to be solved. This would make the hackathon to be problem-specific or sector-specific for each year, and all teams try to compete to solve that problem, or a simple iteration thereof. This shift in telos of the hackathon towards concentrating all human capital and energy towards one end goal of solving a well-defined problem, ensures a greater market debt on the problem because the whole marketplace of ideas converges to solve the one same problem but in different lenses (that should be ideally comparable)— the whole market mechanism bends to the problem (as it should be), and the hackathon functions as a problem-oriented ecosystem or ant colony. The market training, through idea signaling, on one problem is a more efficient tool to ensure convergence to market equilibrium and error correction, than market training on many problems— the marketplace of ideas can become a psychotic tool of sovereignty very quickly if not guided by a unifying power whose sole goal is accumulate enough capital to tackle that one problem. As an addendum, putting a bounties system in place ensures that the real end goal is solving the problem, and for as much as real as solving a problem is, it certainly closes the system, closes any teleonomic leak out of the system i.e. measures are nothing but means to quantify the unsurrogatable goal of solving the problem— no leaks, no oozes, no nothing. Just you and the problem. This might sound unnecessarily abstract, but it is very important to ensure that the intermediate powers that be do not get grip of the process— the means can only invariably pre-figure the ends if the following conditions are true: 1- Absence of intermediate powers (proxy measures, Pavlovian conditioning…etc) 2- the ends are accessible, simple and timely (as opposed to inaccessible, complex and far-in-the-future). The bounties system checks both conditions: 1- the bounties system is direct meritocracy because merit or performance is actual— no need for proxy measures if the end goal is the sole measure you have i.e. solving the problem, a yes-or-no question. 2- the bounties system can divide-and-conquer any complex problem to simple and accessible problems guided by bounties subsystems— you don’t want the hackathon to be a Skinner box.
From my observation, what I've noted is that a lot of energy gets competed away in "wrong" problems (some teams with high talent who unfortunately target systemic and/or structural problems that neither AI or any technology for that matter is able to solve). It is an opinion of mine that the marketplace of ideas is better off targeting a single problem, as this increases the chance of the problem actually being solved. In fact, quiet often than not, when the problem definition is delegated to the team's jurisdiction monopoly to decide on it, it is very likely that such a team will eventually lose a little bit of interest in actually solving the problem, as this main goal gets surrogated by irrelevant subgoals e.g. financial reward, presentation skills (to maximize the chance of impressing the jury),..etc (these subgoals are important, but shouldn't be the main goal). Having an open system whose original purpose can be game and surrogated, encourages intellectual rent especially if financial rewards are present— just close the leak.
Decentralizing or dispersing human capital and energy runs into the wall of surrogating the main goal— actually solving a problem, by relatively irrelevant subgoals (this is because the inertia induced by pursuing an end goal is proportional to the energy amount allocated to it).
Instead, concentrating all energy in one problem in a resourcefully scarce environment, ensures that ideas are competing in the same pool, and this market mechanism will lead a greater market debt about the problem. If we have a darwinian engine and all this human energy available as its input, why don't we just pour all of it into one single problem— a problem that ideally haunts the Moroccan people ?
Instead of democratizing the problem-definition process, we democratize rather on the level of ideas to solve a pre-defined problem, as this ensures better energy allocative efficiency because the market dynamics shift to operate on the level of ideas, not the problem. It is an apriori fact that the problem logic dictates the efficiency logic of the marketplace of ideas, not the opposite. It is also an apriori fact there are many ways, as in many ideas, to solve a problem, but no problem is solved by any idea, specifically, not all problems are solved by a given idea— an idea may solve two problems or more, but there are others that only specifically solve that problem, and you want to include these problem-centric ideas because they’re very likely, thanks to their specificity, to solve that problem in a way that no other idea can— you want to make sure that you get on top of the pareto pile. That said, where do you think we should let the marketplace reigns ? Where do you think we should delegate all human energy ? It is in the valley of ideas, not problems. If your answer to that question is problems, just imagine trying to catch dust with your bare hands.
In order for the hackathon to fulfill its telos— accumulation of capital, it should engineer good ideas, and it should make sure as much as possible that bad ideas are turned-down, but this is a mechanical problem, not a human judgment problem— you should tweak the mechanics of the hackathon, not lobotomize human brains. So, how do you ensure a good selection engine is at place ? Certainly, you don’t want to have each team siloed in their echo chamber with no market feedback on their ideas, but that’s what you force them to do when you delegate jurisdiction monopoly to them by granting them the freedom to choose a problem— there are no solutions, just trade-offs, and I assure you that freedom always brings trade-offs with it, you want to ensure that freedom is not indistinguishable from self-sabotage. Focusing on one problem ensures, thanks to the conditionally mighty power of the market economy (idea signaling), that these ideas are more likely to be differentiable, high in quality and likely to solve the problem.
There is a trade-off between the size of the marketplace of ideas and the size of the marketplace of problems— when problems are freely (and probably even randomly) selected, the navigation of ideas becomes more limited because each team is levitating in their own problem with no possibility for idea signaling, therefore the quality of these ideas themselves become more limited— you truncate the network effects of ideas, and you end up with ideas with low comparative advantage and high-competitive advantage. As Stalin once put it, quantity is a quality in its own. And if the hackathon aims at seeding the stage for future monopolies, it should favor comparative advantage more. The good thing about this approach is that you can somewhat diversify the problem set, but just make sure to correct that diversification with sub-clusters, sub-market or sub-spaces for teams that are tackling the same problem to ensure better ideas market dynamics, and if you have many teams, that should do— you can divide-and-conquer this thing recursively thanks to positive network effects.
The Hackathon is a moral war against disorder
The hackathon should recreate the conditions of Asabiyyah— this sense of social cohesion and bond towards a unified goal with the disciplinary function of hammering men into cohesive states— the Moral Equivalence of War is revitalized.
When the moral equivalence of war is vitalized in men, any problem bends to the sheer power of unified order. Scarcity drives war and competition towards fulfilling a unified goal— any constrainable agent uniformly converge to accumulate as much power as possible as an ultimate subgoal to concentrate as much energy as possible, a state of total order.
The end goal of the Asabiyyah is to accumulate as much capital as possible in such a short timescale, and the greater this ratio, the stronger the spirit of Asabiyyah becomes— disorder outcompetes order through the weapon of time and lack of capital. To usher in a golden age, this incentive density should be as maximum as possible. The hackathon shouldn’t be subjugated to the evil forces of booms-and-busts, you don’t want balancing feedback loops throwing debt cycles at you. Instead, you want to have a positive feedback loop accumulating indefinitely, you also want to ensure that this positive feedback loop is going in the right direction, that is accumulation of capital towards the mechanics of The Ultimate Resource. Getting the direction of the positive feedback loop wrong is equivalent to self-sabotage because only a positive feedback loop can balance a positive feedback loop— only more power can fix power.
Capital seeks accumulation, Energy seeks dispersion
Democratizing the problem-definition process may not converge to a problem set that is specifically Moroccan. Teams are likely to pick up on problems that are not specific to Morocco unless the whole telos of the hackathon is to pre-define such a problem— by starting from a problem that Moroccans faces, we at least ensure (other variables held constant) that all this human capital orientes itself towards solving that specific problem.
The logic of this is four-fold:
1- A swarm ecosystem that is specifically hell-bent on solving a pre-defined problem, redirect all its control mechanisms to ensure a greater market debt on the problem—that, we call capital. The power of this ecosystem is directly measured by the number of the control mechanisms that it possesses to deal with the problems that the world throws at it, and granted a problem-centric framework, this power tends to accumulate naturally in the form of capital— these control mechanisms increase precipitously when they are directed at one problem.
2- Prevent energy leak: ceding teams the freedom to choose a problem may end up ceding power to irrelevant problems that leaks the human capital away. Ideally, the hackathon should prevent unnecessary energy dissipation. Eventually, the hackathon should accumulate enough capital in its inventory to address any problem, but to do that? the hackathon should necessarily start from intolerance problem-wise, as this outcompetes starting from tolerance, because ceding freedom to problem-definition is going to wind-up merely scratching the surface. The point is to make this ecosystem as close as possible, to prevent the end goal subversion towards merely instrumental subgoals e.g. financial reward. Trust me, you don't want to mess with entropy.
3- Intolerance always outcompetes tolerance: Starting from tolerance sounds appealing because the intuition is that tackling as many problems as possible is a good algorithm for solving as many problems as possible, but this relationship is not as linear as one might think of it. Also, concentrating all human capital and energy into one problem sounds very counterfactually inefficient (opportunity cost-wise: how about all the other problems we’re not tackling ? You might ask) but it is actually very efficient if not the most efficient— it is one of those ideas whose intuition doesn’t truly do a good service to— sounds extremely inefficient but it is actually extremely efficient. Tolerance is a very bad idea because nature is not that much of a fan of normal distributions as you think it is. Diversifying problems initially won't amass sufficient capital to solve any one of those problems— dispersing energy is a bad algorithm for survival. Dissipating energy will only fluctuate you from one problem to the other with insufficient energy to tackle it. Having each team tackle a problem bigger than itself is a recipe for failure. It might bother some folks to say that maximum allocative efficiency, solving the knowledge problem, can be achieved without decentralized market economy— that’s how Friedrich Hayek got pwned by the laws of thermodynamics.
4- The main goal is accumulation of capital— more capital, more possibility. The hackathon should converge on accumulating enough capital to tackle a specific Moroccan problem. This will ensure an efficient process for solving as many problems as possible but in a step-wise fashion— you want to solve one problem at a time more efficiently than fooling yourself by solving many problems simultaneously way less efficiently.
Imagine a swarm ecosystem, powered by the creativity and determination of hackathon participants, focusing solely on a critical Moroccan issue—be it improving our nation’s PISA scores or addressing another pressing problem. By anchoring the hackathon to one challenge, we can maximize its relevance and impact on Moroccan society, because only through accumulation of capital that the future is created.
This last point of capital accumulation also ensures that the conditions of a bureaucracy springing out are decimated to dust, but that's another topic beyond the scope of this manifesto. For now, what should bother us is how to get a hackathon to actually reflect startup talent.
The Measure Problem: Playful scarcity and Startup building
What is a good measure for a hackathon? What do you want the act of winning a hackathon to mean? The good news is: you can make it mean whatever you want it to mean. The bad news is: not all means are good means, certainly not all measures are reflective of the objective reality that they ought to reflect, and you want to be painstakingly careful with that.
Ideally, the prospective purpose of the hackathon is a preview of startup building— it is an exposition of what to come, of future startup builders. This is a real thing, and you don't want bad measures, those numbers better say something, those numbers better don't lie. You see, the problem with open systems targeting complex goals (future startup building) is that they are vulnerable to being gamed. Gaming the system is a proxy measure of its corruptibility (and maybe an actual corruption), and we don't want corrupt systems because startup building is incorruptible by design i.e. demand is conserved— you can't trick users to use your product if it doesn't truly fulfill their needs, this system is simply ungameable (this is not academia or something). The constraints of objective reality are just too sovereign to allow for any successful gaming of the system, and hackathons are (and should be) ungameable. Therefore, the measure of success in a hackathon (better) reflects an actual startup building talent— the error between winning a hackathon and prospective startup building should be as minimum as possible. To do that, the measures used should pre-figure the end goals of the system they measure— these measures shouldn't surrogate the main end goal of previewing potential startup builders.
In order to modulate the measures to reflect startup building talent, the hackathon should recreate the very conditions of actual startup building i.e. maximize playful scarcity and uncertainty and downplay the importance of experience. Yes, you've read that right: experience is not as important as you think it is— if you are building a would-be unicorn in an uncharted territory, experience is valueless by design.
In the world of startups, there is no formula to be taught. The process of building a successful startup is fundamentally singular and unsystematic and the hackathon culture should reflect that— any form of rentierism should be looked at with a grain of salt and skepticism. If you let participants rent their past projects and/or ideas, you basically turn the hackathon efficiency logic into a deficiency logic— just call it research conference instead. To preserve the telos of hacking, this efficiency logic should inject the environment with entropy, with moderate difficulty— not too easy to avoid cuckoldry, not too hard to avoid learned helplessness— you want psychologically robust, ideally anti-fragile people who have an almost unhealthy appetite for risk, contrarian and religiously committed to the mission— the line between being right and being crazy should be as thin as possible to the point of indistinguishability.
Hacking is seeing the present from the future, not the opposite
Human action is always directed through intentionality— a purposeful pursuit towards some goal given scarce resources with the purpose of enhancing the subjective well-being of human agent. Hacking is a human action that emphasizes non-standardization and scarcity.
Hacking is the process of achieving an end goal with non-standard means, to creatively overcome the (necessary) constraints imposed by scarcity of resources in an environment that is hostile to novelty, with a spirit of playfulness and exploration— it is not the activities that matter themselves, but how they are done.
Here is a take from Richard Stallman:
"What they had in common was mainly love of excellence and programming. They wanted to make their programs that they used be as good as they could. They also wanted to make them do neat things. They wanted to be able to do something in a more exciting way than anyone believed possible and show "Look how wonderful this is. I bet you didn't believe this could be done."
If the outcome of the hacking activities is prospectively predicted beforehand, the spirit of hacking is dead, and it remains dead because you killed it with certainty overdose. This spirit can only be revitalized back to life if uncertainty is introduced into the environment, that’s the playful part, and to believe that everything is impossible until it happens— so make it happen, for where does possibility come from? it comes from happening— happening has to make it, duh. This makes hacking a very retrospective and Bayesian activity.
To hack is to exert serious efforts towards a given goal given scarce resources, and to attain that goal. The essence of hacking is unfamiliarity— the more you defamiliarize the problem, the better. The essence of hacking is not the end-product itself, but the very process of niche-construction mechanism instrumentalized to deal with a complex and uncertain environment— scarcity is the core logic of hacking. This entails that the real hackers— real winners of the hackathon, are those folks who are building ideas that no one is building, placing emphasis on comparative advantage than competitive advantage— competition is (and should be) a mean to an end— solving Moroccan problems and accumulating capital. Competition shouldn't be an end in itself— solving the problem should be more important than winning the prize, because competition is merely a tool for maintaining order— to cede the tool with such teleonomic sovereignty, to treat it as an end goal, is to merely corrupt the tool with misplaced power (that should instead go to accumulation of capital).
Hackathon’s answer on the exploration-exploitation dilemma should be a clear-cut answer: Exploration— each time explores ideas in the possibility space of that problem. The hackathon timescale is relatively short, it thus needs to ensure that most, if not all, of that timescale is solely spent on exploration, not exploitation. There are no actual market dynamics or user feedback to exploit anyway. So why even bother? To make this clearer, just imagine the hackathon as an idea lab or something— the point is to come up with as many differentiable ideas as possible, as many falsifiable hypotheses as possible. The hackathon is an engine for hypotheses, not theories— we don’t have enough time for theories— we can also easily falsify these hypotheses by throwing them to the real-world and test if they truly solve that problem or no.
Given time scarcity, this entails that teams who spent +90% of their time on idea innovation are more of hackers than those who spent most of their time actually building the product. This sounds very counterintuitive and annihilatory, but the hacking value lies in how unsystematic the idea is: an idea with 10x order-of-magnitude better with a lowkey MVP is 10x better than a replicable idea with a very shiny product, especially given the absence of actual user feedback to iterate on the MVP— the idea has at least 80% of the value as a foundation, and this tends to accumulate to give rise to compounded effects— the real measure of team’s success is what they would become a week from the hackathon, a month, a year, or years— these non-linear, compounded effects are the kernel of startup’s later blitzscaling stage yet-to-come— the hackathon better reflects that. Naturally, this also ensures equity of chances— you don't want to have people throwing their past works or projects, that they worked on for weeks, months or years prior, at the hackathon, because the hackathon is not a conference or a forum. Any form of pre-meditation simply devours the spirit of hacking.
Here is something you will never see falsified— teams which initially spent most their energy on the idea’s differentiability often start with very bad MVPs, and their ideas tend to sound very bad, too bad to get stolen or even thought of, in contrast to image-makers which spend most their energy on making their MVPs as shiny and as technical as possible to look impressive, and given the short timescale of the hackathon, the image-makers actually get away with gaming the system, but with enough timescale, the adjacent sequences squeezes in and upside down meeting at the break-even point— demand being conserved induce non-linear effects; burn-rate shifts to earn-rate for the Asperger team, and earn-rate shifts to burn-rate for the Marketing team — the hackathon should keep these exponential effects in mind, because you want to look for zipfian and energy-conserving talent, for last-mover advantages and not first-mover advantages, to contain the fire as to let it glow inexorably— I know this goes contrary to intuition, but please keep patience…This is gambling with nature, and we don’t want to pay the entropy tax, do you ? In that telling, the hackathon jurisdiction should amass robust skepticism towards any fluctuation of energy that conceals a dissipation of energy, any aimlessly floundering kinetic energy that mimics potential energy. The Asperger team doesn’t seek early validation because it doesn’t have energy or time to do so, it is instead busy answering the following questions which take a hellish amount of their time: what’s so different about our idea ? why now ? why does it need to exist ? By genuinely attempting to answer these questions, you forfeit your right to early successful marketing and impression, but you don’t have to bother yourself with that, at least not in an early stage— the hackathon also shouldn’t bother itself with that because its essence is to produce as many ideas with 10x order-of-magnitude as possible, most of which sound too bad to solve that one problem until it happens by compounded effects
The startup world is that of secrets, you want to dig deeper and focus on things that are true, not things that are impressive. There is always something attractive in mimicking a monopoly when you are a competitive firm, and that’s somewhat risky given that the low-hanging fruits of innovation have already been picked— so you either truly dig deeper, or languish in the Plato’s cave.
Other Externalities
In a problem-specific hackathon, it is relatively easier for the jury to compare between ideas and solutions because they compete in the same pool— the sole measure of comparison is how much portion of the problem is solved by each and every idea. This ensures a sweet spot combination between accumulating as much capital as possible on a problem, but also making the ideas selection process as much easy as possible.
A problem-specific hackathon also guarantees that at least a majority of participants are somewhat interested, if not passionate, about that field, sector or ideally that specific problem. Although this is a fairly empirical matter, but adding a little bit of negative discrimination is not as bad as it may initially sounds. This will also ensure that people come to the event with a problem-centric mindset, instead of starting from technical solutions in search of a problem. Take a look at the team formation process, most folks prioritized their tech stack as the sole criterion of team selection while fundamentally downplaying the problem to be solved— technology doesn't solve our problems unless we make it so.
A problem-specific hackathon also ensures equity of chances as a positive externality, especially if the pre-defined problem is too specific to have had previous attempts thrown at it. As suggested in the hacking chapter, the point of the hackathon is playful scarcity— to emphasize fluid intelligence and not crystal intelligence, novelty and not familiarity, uncertainty and not fixedness, singularity and not standardization— any form of formalism simply devours the core essence of hacking.
Boltzmann would like a word
Life is a competition for energy, truer words have never been spoken. Human needs are virtually infinite, always direct towards some end goal, but energy is conserved. This means that energy efficient use is a natural equilibrium for any constrainable agent, and certainly hackathons are constrainable agents. There is a constant scarcity of energy, and we can’t accelerate to the future unless we let the capital gets its own momentum.
I hope this proposal resonates and inspires a rethinking of hackathons as problem-specific ecosystems that generate not only ideas but also actionable, scalable solutions to actual challenges faced by Morocco.