Armin Ronacher's Thoughts and Writingshttp://lucumr.pocoo.org/feed.atom2024-02-26T00:00:00ZArmin Ronacher's personal blog about programming, games and random thoughts that come to his mind.WerkzeugAustria: A Fearful Country In Need Of A Visionhttp://lucumr.pocoo.org/2024/2/26/austria-needs-a-vision2024-02-26T00:00:00ZArmin Ronacher<p>This will be a slightly different post. It has to do with the country I
am living in with my family: Austria. More importantly it has to do with
some some observations and of mine about how this country functions.</p>
<p>There is a rather famous quote about Vienna: “If the world once ends, I'll
move to Vienna, because that's where everything happens fifty years
later”. It has been attributed to Gustav Mahler who lived at the tail end
of the 19th century. It might also have been said by anyone else or
about a different city. Yet as a description of Vienna is highly
accurate — even today — and it in many ways describes the culture here.
While Austrians might argue that Vienna really does not represent the
country, the fundamentals of that mentality are inherent to Austria's
culture. Austria is a very conservative country that chooses to disregard
progress for as long as it can get away with. It's not always stuck in
the past. There are definitely exceptions to the rule but in many ways
this conservatism is the backdrop to every day decision making. The way I
like to portray what is happening here is that there is a strong desire
for “stability” and fear of the unknown. Austrians prefer to miss out on
a fad over adopting something too early.</p>
<p>While a country is defined by its borders, the culture is defined by it's
population. So we need to define what an “Austrian” is. That turns out to be
rather complex and this complexity matters a lot. Austria is a country of
9.1 Million people. Let's take a news article from a few days ago: “4,9
Million Austrians travelled for vacation in 2023” according to Statistics
Austria. When you read a statistic like that, you can extrapolate that
this refers to residents in Austria. Austria has almost 20% foreigners;
in Vienna that number is 35%. Those foreigners are divided into EU
citizens, refugees (and those applying and waiting to be processed) and
other third country nationals. They have vastly different permissions and
rights. It's comparatively easy to get a visa or work permit on paper
(called “Aufenthaltstitel”) but it can involves a lot of bureaucracy to
actually get one. Even as a dependent of a EU citizen it can take months
to get your permit processed, particularly in Vienna despite the fact that
EU law requires this to take effect immediately. The MA35 authority in
Vienna responsible for permits is well known for lack of service quality.</p>
<p>Citizenship on the other hand is shockingly restrictive even ignoring
bureaucracy. You need to earn well above the national mean to be entitled
to it, the minimum waiting time is 10 years (can be shortened to 6 years
in many cases) and you need to have certificates that demonstrate that you
can speak German on B1 level or higher. Simplifications for children are
almost non existing. You also cannot be abroad for more than 20% of the
time which sometimes is an issue for business travellers. It also
requires you to renounce other citizenships when you want to become
Austrian. This leads to the other definition of “Austrian”: someone with
Austrian citizenship. Austria has some of the lowest naturalization rates
in the EU. Except it also has a citizenship through the backdoor. If you
are a descendent of a holocaust victim, you are entitled citizenship
through a special process which does not require renouncing nor does it
require residence. Unsurprisingly this has lead to the number of people
applying for citizenship this way being around half of the granted
citizenships since this law has been introduced.</p>
<p>Austria is a country that needs permits for everything and in some cases
these permits are bizarre. Case in point: to operate a monetized YouTube
channel you need to register with KommAustria. To register with
KommAustria you need to be an Austrian, EU citizen or registered refugee.
As a third country national (Russian, US citizen, Canadian etc.) there is
only a way to operate an illegal YouTube channel and just assume nobody
will mind (as many do). There are a lot of these weird rules, and many
have to do with residence status. Austria accepts a lot of refugees every
single year. While they are waiting for their status to be processed,
they cannot be employed but are given money by the government. Due to how
the law is structured, even if you want to sponsor such an applicant for a
visa, you cannot. There is literally no process. Because the refugee
system takes years and years at times, it means there are people who go to
school, learn the language and have no legal status. Ultimately Austria
ends up deporting a lot of asylum seekers who did not get their status
granted. Yet many of them companies would be happy to have as employees.</p>
<p>It's not just YouTube channels that need permits. Did I mention that
there are permits everywhere? If you want to sell SaaS software, you need
to apply for a permit and that's a rather simple one anyone can get. But
don't you dare to try to become a tailor or confectioner. For the
privilege of operating your own tailor business or pâtisserie you need to
be a master in tailoring or confectioneries. I'm not a tailor, so no clue
how long that takes, but the regular path to becoming a master is a three
year apprenticeship that ends in an exam. So if you are an Ukrainian
refugee who can tailor, even if you have the right to work, good luck
becoming a tailor. You can already guess where all of this is going: it's
the breeding ground of small scale corruption and problematic work
situations. It's not too infrequent that you see people being registered
as a business manager for the purposes of providing permits that itself is
not really working for that business. Once you have a business, the rules
in which you can operate it are also limited. Mandatory time keeping for
employees, maximum opening times for stores, all kinds of limits for what
endeavours are possible with the business license. Even if you are
entirely alone in your store, you cannot open it whenever you want. Even
if the store is exclusively operated by robots, it would not be allowed to
open on a Sunday and not for more than 72 hours a week. Some things are
completely unavailable to foreigners unless they are EU citizens or
refugees. Can't be a policemen, can't operate a restaurant (you need a
middleman), can't have a chimney sweep business (someone please explain
this one to me).</p>
<p>What else do you need permits for? Well one of new things that has been
thrown in recently has been the packaging directive of the European Union.
A sender of a package has to “license” the packaging to send it to an end
user. The license fee then goes to local waste management. So far, so
good. Unfortunately in the case of Austria you need to go to a notary to
register your “Representatives for packaging and single-use plastic
products”. You can take an educated guess how many foreign companies want
to jump through these hoops. Some sellers refuse to sell to Austria (it's
a small country after all), others pay for excessive fees from third
parties that can provide such services. Established local sellers are
happy and supportive, after all less competition from other countries.</p>
<p>Taxation is very much the same story. High income taxes, income dependent
social security contributions, value added tax etc. All these things
drive up the cost of doing business and encourages a healthy shadow economy.</p>
<p>Alongside all of this sits a political system in which politicians see
themselves as kings that give out gifts to the population. Rather than
lowering taxes, they rather give out all kinds of subsidies.</p>
<p>You might be able to see a pattern here. This conservatism is in a way
really just protectionism. Which is a valid way of live, but all of this
really prevents innovation, and it also as a lot of unintended side
effects. Quality of life in Austria might be great, but I am pretty sure
that the country as a whole greatly eats into it's existing capital to
retain that. While Austria might want to pretend like the world is not
changing, the reality is that it has no control of what happens elsewhere.
There are lots of countries in need of entrepreneurs, that are more
welcoming to people. It's also aging and businesses know that immigration
is absolutely vital to the functioning of the country.</p>
<p>All in all it really feels like Austria is a country containing a
population that is afraid. Afraid of new things, afraid of the unknown.
As the collective organism that it represents it's deeply suspicious.
This is not just politics, it's the natural culture. Even foreigners who
move to the country over time assimilate to this line of thinking. Those
who made it through the layers and layers of bureaucracy will start to
defend it. After all, once you invested that time and money it also helps
you against competition.</p>
<p>Austria today takes part in a much more connected world. It's embedded in
a free trade union, it's depending on international products and
immigration. I find it ironic that Austria has a ton of human capital,
it's still a very attractive destination for immigrants, yet it throws
away so much potential. It got dealt an amazing hand but it's just to
afraid of playing it.</p>
<p>Clearly Austria will not become a libertarian wonderland and it should not
be. There is no appetite for large scale deregulation and that is
absolutely okay. But there is a version of this country that stays true
to its actual values and can achieve better outcomes. Maybe one day we
will see a political landscape that is just a bit more courageous.</p>
Rye Grows With UVhttp://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv2024-02-15T00:00:00ZArmin Ronacher<p>Two weeks ago I asked the question again about <a class="reference external" href="/2024/2/4/rye-a-vision/">What Rye should be</a>. There has been one thing that I have not
publicly shared before and that is that ever since Rye exists I have also
been talking to <a class="reference external" href="https://twitter.com/charliermarsh/">Charlie Marsh</a>
about Python packaging and Python tooling. It turns out that we had some
shared ideas of what an ideal Python tooling landscape would look like.
That has lead to some very interesting back and forths. To make a
potentially very long story short: Together with Astral's release of
<a class="reference external" href="https://github.com/astral-sh/uv">uv</a> they will <a class="reference external" href="https://astral.sh/blog/uv">take stewardship of Rye</a>. For the details read on.</p>
<p>For me Rye is an exciting test bed of what Python tooling can be. I have
been using this test bed to run a of experiments over the last year. I
learned a lot about what is missing in the ecosystem by building it and
where the challenges are. What I enjoyed the most of working on it so far
has been the feedback from various people on it. I wanted to explore what
a “cargo for Python” is like and it's becoming ever more evident what that
might look like. At the same time from the very start I was very clear in
<a class="reference external" href="https://github.com/mitsuhiko/rye/discussions/6">questioning its existence</a>.</p>
<p>Since we were talking I was able to run an experiment which has been to
put in Astral's uv as replacement for <cite>pip-tools</cite>. If you are not
familiar with it yet: uv today is a drop-in replacement for
<cite>pip-tools</cite> and <cite>venv</cite>. The why is pretty clear: it's much faster than
<cite>pip-tools</cite>. Instead of taking 5 seconds to sync a virtualenv, it's
almost instant. It's hard to overstate how impactful this is in terms of
developer experience.</p>
<p>For entirely unrelated reasons Rye today already picks some of Astral's tools
to power other functionality. If you invoke <cite>rye fmt</cite> and <cite>rye check</cite> it
behind the scenes uses Astral's <cite>ruff</cite> to do so. They are fast,
sufficiently oppinonated and they do not require installing them into the
virtualenv of the project. They are quickly becoming the obvious choice
if you are used to excellent tooling from other ecosystems. So as it
stands, three things that Rye does are either already picking Astral
tools, or will soon default to doing so.</p>
<p>This led to a few conversations if it would make sense for Astral to
continue the work on Rye and build it out into that “cargo for Python”.
I'm very much convinced that there should be such a tool and that is
something Charlie from Astral shares. Where we landed is a plan that
looks like the following:</p>
<p>Rye will continue to be a test bed for what Python tooling can be. We
will move the project under Astral's stewardship with the desire to use it
to further explore what a good UX can be and we will be quite liberal in
trying different things. For instance now that the package installation
process is blazing fast, I really want to see if we can remove the need of
calling <cite>sync</cite> manually. There are also a lot of questions remaining
like how to make the most of the <a class="reference external" href="https://github.com/indygreg/python-build-standalone/issues">indygreg builds</a> or what
lock files should look like in a Python world. I also want to go deep on
exploring a multi-version Python import system.</p>
<p>Rye will turn into a blessed breeding ground of different things. As the
user experience becomes more obvious uv itself will turn from what
it is today — low level plumbing — into that higher level tool with a
clear migration path of folks using <cite>rye</cite> to that new <cite>uv</cite>.</p>
<p>To try Rye on top of uv today <a class="reference external" href="https://rye-up.com/guide/installation/">install</a> or update to the latest
version and enable the experimental uv support:</p>
<div class="highlight"><pre><span></span><span class="gp">$ </span>rye config --set-bool behavior.use-uv<span class="o">=</span><span class="nb">true</span>
</pre></div>
<p>To learn more about uv and rye head over to GitHub:</p>
<ul class="simple">
<li><a class="reference external" href="https://github.com/astral-sh/uv">astral-sh/uv</a></li>
<li><a class="reference external" href="https://github.com/mitsuhiko/rye">mitsuhiko/rye</a></li>
</ul>
<p>You might have some more questions about this so I compiled a basic FAQ:</p>
<dl class="docutils">
<dt><strong>Why not make Rye the cargo for Python?</strong></dt>
<dd>This in many ways might look like the obvious question. The answer is
quite simple: Rye as it exists today is unlikely to be the final
solution. For a start code wise it's pretty brittle coming from it
cobbling together various tools. It's a duck-taped solution that was
built to sketch up what can be, for my very own uses. It is however
incredibly useful to play and explore possible solutions.</dd>
<dt><strong>Will Rye retired for uv?</strong></dt>
<dd>Not today, but the desire is that these tools eventually converge into
one.</dd>
<dt><strong>Will you continue to contribute and maintain Rye?</strong></dt>
<dd>Short answer: yes. Long answer is that me contributing to my own tool
has been a pretty spotty thing over the last year. There was in fact
almost a multi month hiatus where the only changes to Rye were bumping
Python versions and fixing minor issues and that not because it was
perfect. The reason more was that I realized that Rye runs into
fundamental issues that are really gnarly to resolve which can be
quite frustrating to attack as a side project. So I want to continue
to be involved in one way or another, but this is a project much
larger than me and I do not have the motivation to give it enough of
that push myself.</dd>
<dt><strong>Will I join Astral?</strong></dt>
<dd>No :-)</dd>
<dt><strong>Is there a song about Python packaging?</strong></dt>
<dd><p class="first">Thanks to AI there is.</p>
<div class="last"><audio controls
src="http://mitsuhiko.pocoo.org/pep8-vs-packaging.mp3"></audio></div></dd>
</dl>
Rye: A Vision Continuedhttp://lucumr.pocoo.org/2024/2/4/rye-a-vision2024-02-04T00:00:00ZArmin Ronacher<p>In April of last year I released <a class="reference external" href="https://rye-up.com/">Rye</a> to the public.
Rye, both then and now, represents my very personal vision of what an improved
Python packaging and project management solution can look like.
Essentially, it's a comprehensive user experience, designed so that the
only tool a Python programmer would need to interface with is Rye itself
and it gets you from zero to one in a minute. It is capable of
bootstrapping Python by automatically downloading different Python
versions, it creates virtualenvs, it manages dependencies, and lints and
formats. Initially developed for my own use, I decided to release it to
the public, and the feedback has been overwhelmingly positive.</p>
<p>When I introduced it, I initiated a discussion thread titled <a class="reference external" href="https://github.com/mitsuhiko/rye/discussions/6">“Should Rye
Exist”</a> referencing the
well known <a class="reference external" href="https://xkcd.com/927/">XKCD #929</a> which humorously comments
on the proliferation of competing standards. I did not feel well throwing
yet another Python packaging tool into the ring.</p>
<p>Yet it exists now and has user. This standard issue however I think is
helped a bit by the fact that Rye doesn't actually do any of these things
itself. It wraps established tools:</p>
<ul class="simple">
<li><strong>Downloading Python</strong>: it provides an automated way to get access to
the amazing <a class="reference external" href="https://github.com/indygreg/python-build-standalone/">Indygreg Python Builds</a>
as well as the PyPy binary distributions.</li>
<li><strong>Linting and Formatting</strong>: it bundles <a class="reference external" href="https://github.com/astral-sh/ruff">ruff</a>
and makes it available with <cite>rye lint</cite> and <cite>rye fmt</cite>.</li>
<li><strong>Managing Virtualenvs</strong>: it uses the well established <a class="reference external" href="https://virtualenv.pypa.io/en/latest/">virtualenv</a> library under the hood.</li>
<li><strong>Building Wheels</strong>: it delegates that work largely to <a class="reference external" href="https://pypi.org/project/build/">build</a>.</li>
<li><strong>Publishing</strong>: its publish command uses <a class="reference external" href="https://pypi.org/project/twine/">twine</a> to accomplish this task.</li>
<li><strong>Locking and Dependency Installation:</strong> is today implemented by
using <a class="reference external" href="https://pypi.org/project/unearth/">unearth</a> and
<a class="reference external" href="https://github.com/jazzband/pip-tools/">pip-tools</a>.</li>
</ul>
<p>As you can see, Rye is not revolutionary and it's not intended to be. Rye
itself doesn't do all that much as it delegates all the core functionality
to other tools in the ecosystem. Rye packages these tools together in a
user-friendly manner, significantly reducing the cognitive load for
developers. This convenience eliminates the need to learn about various
tools, read extensive documentation, and integrate these components
independently. Rye lets you get from no Python on a computer to a fully
functioning Python project in under a minute with linting, formatting and
everything in place. It is sufficiently opinionated that many important
decisions are made for you. For instance it starts you out with using
<cite>pyproject.toml</cite> and picks a wheel build system for you. It also picks
the linter and formatter, and the preferred Python distribution and
decides on a build tool.</p>
<div class="section" id="defaults-matter">
<h2>Defaults Matter</h2>
<p>Rye is designed to select the best tools for the job — it picks winners.
Why does it do that? This approach is inspired by my admiration for the
developer experience in the Rust ecosystem, particularly the seamless
integration of <cite>rustup</cite> and <cite>cargo</cite>. Their functionality made me long for
a similar experience within the Python community. Crucially the way this
works in the Rust world does not mean that <cite>cargo</cite> does everything. When
you run <cite>cargo build</cite> it invokes <cite>rustc</cite>, when you run <cite>cargo doc</cite> it runs
<cite>rustdoc</cite>. When you invoke <cite>cargo clippy</cite> it runs <cite>clippy</cite> for you and so
worth. Cargo is a manager that delegates the important work to bespoke
tools that are improved by sometimes entirely different teams. This also
means that tools can be swapped out if they are found to be not the right
choice any more. The experience in the Rust world also showed me that
excellent Windows support is just a must have. That's why Rye is not just
a great experience on macOS and Linux, it's also excellent on Windows.</p>
<p>I am convinced that the Python community is deserving of an excellent
developer experience, and Rye, as it stands today, offers a promising
beginning. My belief is supported by evidence gathered from conducting
in-person user interviews and demos, where Rye was well received. In
fact, every individual who I was able to give a guided tour of Rye was
impressed by how swiftly one could start working with Python. Because it
was demonstrably designed to avoid interference with any pre-existing
Python configurations, Rye allows for a smooth and gradual integration and
the emotional barrier of picking it up even for people who use other tools
was shown to be low.</p>
<p>That said, Rye is a one person project and it does not address the
fundamental challenges of some of the issues we have in the Python
ecosystem. It does not solve multi version dependencies, it does not
offer better performance for the installation of dependencies. It does
not help with distributing executables for end user applications or
anything like this. However I am getting multiple signals that the time
is right for a tool like Rye to not just exist, but also to rally a larger
number of the Python community embrace some of these standardization
ideas.</p>
</div>
<div class="section" id="what-s-next">
<h2>What's Next?</h2>
<p><a class="reference external" href="https://github.com/Kwpolska">Chris Warrick</a> recently <a class="reference external" href="https://chriswarrick.com/blog/2024/01/15/python-packaging-one-year-later/">wrote a blog post</a>
where he looked back at the last year of Python packaging that made the
rounds on Twitter. It laments a bit that we did not make much of a
progress in packaging and it also talks a bit about Rye and correctly
points out that Rye does not have enough contributors (basically just me).
That's not a healthy setup.</p>
<p>I still don't really know if Rye <em>should</em> exist. It has not yet become
established and there are plenty of rough edges. I personally really
enjoy using it but at the same time every time I use it, I get reminded
that it would stop existing if I did not invest time into it which in some
sense is what keeps me going on it.</p>
<p>However I would love to see the community converge to a Rye like solution,
no matter where it comes from.</p>
</div>
<div class="section" id="learn-more">
<h2>Learn More</h2>
<p>Did I spark your interest? I would really appreciate it if you give it a
try and give feedback:</p>
<div style="text-align: center">
<p><em>a 16 minute introduction to Rye</em>
<iframe width="782" height="441" style="display: block; margin: 0 auto;" src="https://www.youtube.com/embed/q99TYA7LnuA" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</div><ul class="simple">
<li><a class="reference external" href="https://rye-up.com/">Project Website</a></li>
<li><a class="reference external" href="https://rye-up.com/guide/">User Guide and Documentation</a></li>
<li><a class="reference external" href="https://github.com/mitsuhiko/rye">GitHub Project</a></li>
<li><a class="reference external" href="https://github.com/mitsuhiko/rye/discussions">Discussion Forums</a></li>
<li><a class="reference external" href="https://discord.gg/drbkcdtSbg">Discord</a></li>
</ul>
</div>
The Life and Death of Open Source Companieshttp://lucumr.pocoo.org/2023/12/25/life-and-death-of-open-source2023-12-25T00:00:00ZArmin Ronacher<p>You likely know that I've contributed <a class="reference external" href="/projects">significantly to the Open Source community</a>, that I work <a class="reference external" href="https://sentry.io/welcome/">for an Open Source Company</a>, that we got <a class="reference external" href="https://news.ycombinator.com/item?id=36971490">shit for calling ourselves
Open Source</a> and that we
subsequently created <a class="reference external" href="https://fsl.software/">a new license</a> to address
at least some of these concerns. I also shared <a class="reference external" href="/2023/11/19/cathedral-and-bazaaar-licensing/">my personal thoughts</a> on that license recently
which unfortunately promptly <a class="reference external" href="https://news.ycombinator.com/item?id=38331173">attracted a bunch more negative comments</a> for that. That
introduction might make me sound a tad bitter, so let's talk about
something else.</p>
<p>This Christmas I <a class="reference external" href="https://twitter.com/mitsuhiko/status/1738930820998369593">received a 3D printer</a> and I love
it for two reasons. Firstly, it was an unexpected gift from my wonderful
wife, who chose it. She organized me a brand new <a class="reference external" href="https://bambulab.com/en/a1">Bambu Lab A1</a> 3D printer. It has been a few years since
I toyed around with 3D printing and it was mostly in the context of other
people assembling printers. That's because even though I love toying
around with software, I cannot say the same for hardware. This printer,
however, is remarkably easy to set up and use, significantly boosting my
enjoyment in this hobby. For this purchase she had to balance my love for
Open Source with user friendly technology and I think given the good
experience, she chose well.</p>
<p>The printer comes with a brief guide for the initial setup. In about 15
minutes of removing some screws and mounting some components we were off
to the races. The cloud account appears optional but after scanning a QR
code I could operate it from my phone too. It's quick, it's super plug and
play and it just feels like an incredibly well put together product.</p>
<p>Since I've had to leave the printer at home over the holidays, I've been
engaging in related activities like reading up, creating models, and
exploring the slicer software. Emotions surrounding this printer are
<em>charged</em>. If you step into the wrong parts of the internet you find a
lot of hate. Some of it might be warranted, but others just feels
incredibly out of proportion. I've noticed a fair amount of controversy
surrounding the printer online, largely centered on its Chinese origins,
its optional cloud service, and its impact on the Open Source 3D printing
community. I won't talk much about the China part <a class="footnote-reference" href="#footnote-1" id="footnote-reference-1">[1]</a> here, but I do
want to talk about the cloud and license aspect.</p>
<p>The reason I even write about this printer is the licensing situation and
a bit of a rant about Open Source communities. Here is what I believe is
currently happening, and I'm saying this as a person that knew next to
nothing until a few days ago about 3D printing: Bambu Labs is making some
other players in that space reconsider Open Source.</p>
<p>Bambu entered the industry in a very different way than anyone else
before. They offer a user friendly experience at a very attractive price
point (lower than some of the competition). They also added built-in
cloud service stuff and with a really good quality. But it's a space
dominated by Open Source hardware and software. And they don't really do
that. Bambu seems to add new people into the 3D printing community who
don't care (or not as much) about Open Source. Yet Bambu heavily relied
on Open Source software to put them on the map.</p>
<p>If you open their Bambu Studio, you can see that it's built on top of
<a class="reference external" href="https://github.com/prusa3d/PrusaSlicer">PrusaSlicer</a> and
<a class="reference external" href="https://github.com/supermerill/SuperSlicer">SuperSlicer</a>, both of
which are Open Source. As both of those are licensed under AGPL (which is
a very viral license), <a class="reference external" href="https://github.com/bambulab/BambuStudio">so is Bambu Studio</a>. But none of the firmware or
hardware designs of the Bambu printer are. In fact, Bambu apparently is
also loading itself up with patents over in China, so they probably don't
care about Open Source much at all. If I were Prusa (which in many ways
was the user friendly, dominant player before) I wouldn't be very happy.</p>
<p>So let's discuss Prusa: The Bambu A1 competes with Prusa's MK4 model
but is signficantly cheaper, faster and does more. For the price of one
Prusa MK4 with shipping I could buy three Bambu A1 printers or two Bambu
A2 printers plus the AMS addon which adds multi-color printing. There is
absolutely no reason to buy a Prusa MK4 today unless you want to support
Open Source or a European company (Prusa is from Czechia).</p>
<p>I was able tell that Prusa is reconsidering their Open Source approach and
that with a few days as a member of this community because people are
<a class="reference external" href="https://www.reddit.com/r/prusa3d/comments/10g6fgv/prusa_giving_up_on_its_open_source_roots/">complaining</a>
(the MK4 design is no longer Open Source and the firmware apparently no
longer developed in the open <a class="footnote-reference" href="#footnote-2" id="footnote-reference-2">[2]</a>). Prusa is not hiding that they are
reconsidering their ways thanks to a blog post by their founder about how
they are <a class="reference external" href="https://blog.prusa3d.com/the-state-of-open-source-in-3d-printing-in-2023_76659/">reconsidering their Open Source ways</a>:</p>
<blockquote>
<p>[…] things we’ve been doing at Prusa Research for over ten years were
only possible thanks to the great <strong>3D printing community</strong> and
<strong>open-source philosophy</strong>. However, the new printers and software
releases have made me think again about the current state of open
source in the 3D printing world. How sustainable it is, how our
competitors deal with it, what it brings to the community, and what
troubles us as developers. Consider this article as a <strong>call for
discussion</strong> – as a kick-off that will (hopefully) open up a new
perspective on the connection between open-source licensing, consumer
hardware, and software development.</p>
<p>[…]</p>
<p>The open-source movement relies on the fact that <strong>everyone involved
plays by the same rules</strong>.</p>
<p class="attribution">—Josef Průša in <a class="reference external" href="https://blog.prusa3d.com/the-state-of-open-source-in-3d-printing-in-2023_76659/">The state of open-source in 3D printing in 2023</a></p>
</blockquote>
<p>I strongly recommend reading that entire post, because it captures quite
well the challenging situation that Open Source companies are in. My take
on this is very much the same as for our own situation at Sentry: building
a true Open Source company is hard. Under the OSI definition of Open
Source you are put at a massive disadvantage as you are prevented from
putting protections in place that shield you from other competitors in
that place that chose not to play by the same rules but can leverage your
source.</p>
<p>Historically the GPL has provided some protections here, but in all
reality in the modern world it doesn't. That's because distribution is
really no longer the defining element. Yes, Bambu Studio has to be AGPL
licensed because so is what it's built on, but in many ways that's just the
enabler for a proprietary system that they have in place. They have
reaped years of benefits from this, benefiting from the work of others.
Some paid, but also from many who contributed for free.</p>
<p>Here is what I think would be a negative outcome: if this situation forces
companies like Prusa to abandon their Open Source practices.</p>
<p>However, I believe this situation reaffirms my belief that licenses like
our <a class="reference external" href="https://fsl.software/">FSL</a> (TL;DR: it includes a two-year
commercial non-compete period, after which it transitions to either MIT or
Apache 2, depending on the choice) are a viable alternative, even though
they are not considered Open Source by today's definition. Because one
thing is absolutely clear to me: Bambu carries inherent risk for me as a
user. They manufacture the parts and provide the firmware.</p>
<p>If they go out of business, owning their device becomes much riskier than
owning printers from the Open Source community. For an end-user, having an
Open Source license is a far stronger proposition. That's why I find the
comparison of the FSL to a “source available” or even “proprietary”
license somewhat insulting. A hypothetical FSL-inspired license for Open
Source hardware would grant a hardware company a limited-time non-compete
advantage over other players in the space, while giving users and the
community the assurance that they hold the keys after two years.</p>
<p>The world around us is changing, and so must we as the Open Source
community. Software distribution is no longer the main focus, with much
emphasis now on services. The situation also changes for successful Open
Source hardware communities. Their innovations are slowly reaching more
users, many of whom do not value Open Source as much. In some ways, the
protections in Open Source that worked in a commercial context are no
longer effective.</p>
<p>What Bambu has done — and which I believe will be appreciated in the long
term — is to make their products more accessible to a broader audience. They
introduced 3D printing to people who were previously unwilling to invest
the time. This means there's more potential for profit for everyone
involved, but it also means that it will be harder for Open Source to
compete, especially if Open Source entities don't get a grip of their user
experience and business models. As a user, I wish I could have the Bambu
experience with an Open Source-like model, where the risk is managed over
the long term, while allowing the companies that create these products to
pay their employees and continue innovating.</p>
<table class="docutils footnote" frame="void" id="footnote-1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>If you do care about my opinion here: I have no business with China.
In some ways if I were to have to worry about something from a
government, I care the least about China. The US and my own one can
cause a lot more problems to me. If I were to never be able to go to
China again, very little in my life would change.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="footnote-2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-2">[2]</a></td><td>An earlier version of this blog post stated that the Firmware is no
longer Open Source. That is actually incorrect and what is no longer
open is the controller design.</td></tr>
</tbody>
</table>
Untyped Python: The Python That Washttp://lucumr.pocoo.org/2023/12/1/the-python-that-was2023-12-01T00:00:00ZArmin Ronacher<p>A lot has been said about Python typing. If you have been following me on
Twitter (or you have the dubious pleasure of working with me), you
probably know my skepticism towards Python typing. This stems from the
syntax's complexity, the sluggishness of mypy, the overall cumbersome
nature of its implementation and awkwardness of interactions with it. I
won't dwell on these details today, instead I want to take you on a little
journey back to my early experiences with Python. Why? Because I believe
the conflict between the intrinsic philosophy of Python and the concept of
typing is fundamental and profound, but also not new.</p>
<p>The concept of typed programming languages predates 2015 by a long
stretch. They were not invented now. Debates over the necessity of
typing are not a recent phenomenon at all. When you wanted to start a new
software project, particularly something that resembles a web service you
always had a choice of programming language. Back in 2004 when I started
diving into programming, there were plenty of languages to chose. The
conventional choice was not Python, the obvious choice was not even PHP rather
Java. Java was the go-to for serious web application projects, given its
typing system and enterprise-grade features. PHP was for toys, Python
was nowhere to be found. PHP was popular, but in my circles it was always
seen as an entirely ridiculous concept and the idea that someone would
build a business on it even more so. I remember in my first year of
University the prevalent opinion was that the real world runs on .NET,
Java and C++. PHP was ridiculed, Python and Ruby did not appear in
conversations and JavaScript on the server was non existent.</p>
<p>Yet here I was, I built stuff in PHP and Python. My choice wasn't driven
by an aversion to static typing out of laziness but by the exceptional
developer experience these languages offered, to a large part because of
the lack of types. There was a stellar developer experience. Yes it did
not have intellisense, but all the changes that I did appear on the web
instantly. I recall directly modifying live websites via FTP in real time.
Later editing web sites straight from vim on the production server.
Was it terrible and terrifying? Absolutely. But damn it was productive.
I learned a lot from that. They taught me valuable lessons about trade-offs.
It was not just me that learned that, an entire generation of developers in
those languages learned that our biggest weakness (it not being typed, and
i wasn't compiled) was also our biggest strength. It required a bit of
restraint and it required a slightly different way of programming, but it
was incredibly productive.</p>
<p>There was the world of XPath, there was the world of DTDs, there was the
world of SOAP and WSDL. There was the world where the inherent complexity
of the system was so great, that you absolutely required an IDE, code
generation and compile time tooling. In contrast there was my world. My
world had me sitting with Vim, CVS and SVN and a basic Linux box and I was
able to build things that I was incredibly proud of. I eventually swapped
PHP for Python because it had better trade offs for me. But I will never
not recognize what PHP gave me: I learned from it that not everything has
to be pretty, it has to solve problems. And it did.</p>
<p>But in the same way with PHP, the total surface area between me and the
Python language runtime was tiny. The code I wrote, was transformed by
the interpreter into bytecode instructions (which you could even look at!)
and evaluated by a tiny loop in the interpreter. The interpreter was Open
Source, it was easy to read, and most importantly I was able to poke
around in it. Not only was I able to learn more about computers this way,
it also made it incredibly easy for me to understand what exactly was
going on. Without doubt I was able to understand everything between the
code that I wrote, and the code that ran end to end.</p>
<p>Yes, there was no static type checking and intellisense was basically non
existing. Companies like Microsoft did not even think that Python was a
language yet. But screw it, we were productive! Not only that, we build
large software projects. We knew were the tradeoffs were. We had runtime
errors flying left and right in production because bad types were passed,
but we also had the tools to work with it! I distinctly remember how
blown away a colleague from the .NET world was when I showed him some of
the tools I had. That after I deployed bad code and it blew up in
someone's face, I got an email that not only shows a perfectly readable
stack trace, but also a line of source code for the frames. He was even
more blown away when I showed him that I had a module that allowed me to
attach remotely to the running interpreter and execute Python code on the
fly to debug it. The developer experience was built around there being
very few layers in the onion.</p>
<p>But hear me out: all the arguments against dynamic languages and dynamic
typing systems were already there! Nothing new has been invented, nothing
really has changed. We all knew that there was value in typing, and we
also all collectively said: screw it. We don't need this, we do duck
typing. Let's play this to our advantage.</p>
<p>Here is what has changed: we no longer trust developers as much and we are
re-introducing the complexity that we were fighting. Modern Python can at
times be impossible to comprehend for a developer. In a way in some areas we
are creating the new Java. We became the people we originally displaced.
Just that when we are not careful we are on a path to the world's worst
Java. We put typing on a language that does not support it, our
interpreter is slow, it has a GIL. We need to be careful not to forget
that our roots are somewhere else. We should not collectively throw away
the benefits we had.</p>
<p>The winds changed, that's undeniable. Other languages have shown that
types add value in new and exciting ways. When I had the arguments with
folks about Python vs Java typing originally, Java did not even have
generics. JavaScript was fighting against its reputation of being an
insufferable toy. TypeScript was years away from being created. While
nothing new has been invented, some things were popularized. Abstract
data types are no longer a toy for researchers. .NET started mixing
static and dynamic typing, TypeScript later popularized adding types to
languages originally created without them. There are also many more
developers in our community who are less likely to understand what made
those languages appealing in the first place.</p>
<p>So, where does this leave us? Is this a grumpy me complaining about times
gone and how types are ruining everything? Hardly. There's undeniable
utility in typing, and there is an element that could lead to greater
overall productivity. Yet, the inherent trade-offs remain unchanged, and
opting for or against typing should be a choice free from stigma. The
core principles of this decision have not altered: types add value and
they add cost.</p>
<hr class="docutils" />
<p><strong>Post script:</strong> Python is in a spot now where the time spent for me
typing it, does not pay dividends. TypeScript on the other hand tilts
more towards productivity for me. Python could very well reach that
point. I will revisit this.</p>
Bundleless: Not Doing Things Makes You Fasthttp://lucumr.pocoo.org/2023/11/30/not-doing-things-makes-you-fast2023-11-30T00:00:00ZArmin Ronacher<p>I recently <a class="reference external" href="https://twitter.com/rauchg/status/1729596031434698774">came across a tweet</a> and one
statement in it really triggered me: the claim that a bundleless dev
server does not work. The idea here being that you cannot avoid bundling
during development for performance reasons. This challenges the code
concept and premise of <a class="reference external" href="https://vitejs.dev/">vite</a>'s design. Its
dev server primarily operates by serving individual files post-initial
transpiling.</p>
<p>There's some belief that bundleless development isn't feasible, especially
for projects with thousands of modules, due to potential performance
issues. However, I contend that this thinking overlooks the benefits of
a bundleless approach.</p>
<p>There is obviously some truth to it having issues. If you have thousands
of modules, that can take a while to load and on contrast if most of those
are bundled up into a single file, that will take less time to load.</p>
<p>I believe this to be the wrong way to think of this issue. Consider
Python as an illustrative example: Python loads each module as needed from
the file system, without bundling numerous modules into larger files. This
approach has a downside: in large applications, the startup time can
become impractically long due to excessive code execution during import.</p>
<p>The solution isn't to increase bundling but to reduce overall code
execution, particularly at startup. By optimizing module structure,
minimizing cross-dependencies, and adopting lazy loading, you can
significantly decrease load times and enable hot reloading of components.
Don't forget that in addition to all the bytes you're not loading, you're
also not parsing or executing code. You become faster by not doing all of
this.</p>
<p>The objective for developers, both end-users and framework creators,
should be to make bundleless development viable and at least in principle
preferred. This means structuring applications to minimize initial load
requirements, thereby enhancing iteration speeds. With a focus on doing
less, the elimination of the bundling step becomes an attainable and
beneficial goal. This is also one of the larger lessons I took from
creating Flask: the many side effects of decorators and imports are a major
frustration for large scale apps.</p>
<p>Then once that has been accomplished, bundleless does away with the last
bit of now not important part: the bundling step which has a lot of other
benefits on its own.</p>
<p>Of course, there are nuances. For instance, rarely changing third-party
libraries with hundreds of internal modules will still benefit from bundling.
Tools like Vite do address this need by optimizing this case.</p>
<p>Therefore, when embarking on a new project or framework, prioritize lazy
loading and effective import management from the outset. Avoid circular
dependencies and carefully manage code isolation. This initial effort in
organizing your code will pay dividends as your project expands, making
future development faster and more efficient.</p>
<p>Future you will be happy — and bundleless as evidenced by vite, with the
right project setup works.</p>
FSL: A License For the Bazaar, Not the Cathedralhttp://lucumr.pocoo.org/2023/11/19/cathedral-and-bazaaar-licensing2023-11-19T00:00:00ZArmin Ronacher<p>Sentry relicensed under a new license, called the <a class="reference external" href="https://fsl.software/">Functional Source
License (FSL)</a>. Like the BUSL it replaces,
It's not an Open Source license by the OSI definition, but it comes with
an irrevocable grant: after two years it turns into an Apache 2.0 licensed
artifact (or MIT for the alternative form). It's the response to a lot of
feedback we have received about our previous use of the <a class="reference external" href="https://spdx.org/licenses/BUSL-1.1.html">BUSL</a>. You can read all about
the switch to FSL
in the <a class="reference external" href="https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/">Announcement Blog Post</a>. (You can also find my original thoughts on <a class="reference external" href="/2019/11/4/open-source-and-saas/">the use
of the BUSL here</a>.)</p>
<p>I believe this license to be closer to Open Source than what we had
before.</p>
<p>When I started Open Source development, there was a very famous essay
by Eric S. Raymond called “The Cathedral and the Bazaar”. It describes
the bazaar style development model that Linux propagated at the time.
Patches were passed around freely on a mailing list, source was always
available even between releases. This is how Raymond described the
two development models:</p>
<blockquote>
<p>I believed that the most important software (operating systems and
really large tools like the Emacs programming editor) needed to be built
like cathedrals, carefully crafted by individual wizards or small bands
of mages working in splendid isolation, with no beta to be released
before its time.</p>
<p>Linus Torvalds's style of development—release early and often, delegate
everything you can, be open to the point of promiscuity—came as a
surprise. No quiet, reverent cathedral-building here—rather, the Linux
community seemed to resemble a great babbling bazaar of differing agendas
and approaches (aptly symbolized by the Linux archive sites, who'd take
submissions from anyone) out of which a coherent and stable system could
seemingly emerge only by a succession of miracles.</p>
<p class="attribution">—Eric Steven Raymond, <a class="reference external" href="http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html">The Cathedral and the Bazaar</a>.</p>
</blockquote>
<p>Today the Cathedral approach in Open Source is very uncommon. The Linux
project has not only promoted building in the open, Linus himself has
doubled down on that development model by creating git. Today we build in
the open. Open Source projects are on GitHub, everything happens there.
That's the model I know, it's the model all my Open Source projects use,
it's the model Sentry uses. We build in the open.</p>
<p>There is a second change that gradually happened over the last 20 years:
SaaS. Software licenses really regulate the distribution of source code
and binaries, but they don't have a lever over what happens with the
software once you have it in your hands. That causes a new challenge
which is commonly described as the <a class="reference external" href="https://en.wikipedia.org/wiki/Free-rider_problem">Free-rider problem</a> in economics as an
example of a market failure:</p>
<blockquote>
In the social sciences, the free-rider problem is a type of market
failure that occurs when those who benefit from resources, public
goods and common pool resources do not pay for them or under-pay.
Examples of such goods are public roads or public libraries or
services or other goods of a communal nature.</blockquote>
<p>Open Source software is such a common good. Historically, the licensing
focus was on redistribution. There were not a lot of possibilities for
others to take it and monetize it. With the advent of services, the
situation has changed. Now anyone can take an Open Source project and
host it as a service and there is an appetite to pay for such services.
There is only one Open Source license that tried to address this part, and
that's the AGPL which comes with its own challenges. This risk
disincentives further Open Source development of projects which could be
abused this way.</p>
<p>If you were to follow the Cathedral development model and you only release
software once every two years to the world under an OSI license, that
would technically be Open Source software. But as a user you would need
to wait for two years and if someone were to change their mind, you have
no legal leverage to actually receive that code.</p>
<p>The FSL improves on this for the ones that subscribe to the idea of the
Bazaar development model: it's out there in the open, but it has an
exclusivity period for the original authors to enable them to
commercialize it for a limited but rolling period of two years. You also
do not need to take our word for it, the license already gives you the
right, you just need to wait. After that waiting period, it turns into
a 100% OSI approved licensed artifact. It also enables contributions
by the community for the latest version and not old source code.</p>
<p>Personally I am obviously a strong advocate for that model. I think it's
incredibly close to what Open Source is all about, with some modest
protections. The FSL permits limitless forking after a two-year
exclusivity period, and also allows unrestricted internal use of the
product and contributions long before that. For instance, if regulatory
constraints prevent using the SaaS version of a product like Sentry,
self-hosting is a viable and legal alternative under the FSL. This license
also ensures the availability of the product in any circumstance and
specifically mentions the use of FSL-licensed products alongside software
development services.</p>
<p>The FSL ensures that software can outlast the commercial entity that
enables its development. It guarantees that the software will always stay
functional and available. There cannot be a limbo where the rights holder
prevents the flourishing of a fork out of lack of interest or fear.</p>
<p>To me the FSL's unique characteristics raise questions about its nature.
Its intent, language, and practical impact arguably make it more robust
and exciting than any other source-available license today. The two-year
exclusivity period is ambitious. But one thing is clear: until its
expiration, the license does not qualify as Open Source. While I
recognize the sensitivity around the term “Open Source”, I assert that the
FSL's approach is more closely aligned with Open Source ideals than mere
source availability. I consider it an “Eventually Open Source” license,
though perhaps a more fitting term needs to be found.</p>
<p>I see how incredibly strong many feel about the BUSL and now the FSL. In
the mind of many folks, this license is a betrayal of the Open Source
spirit. I understand the historic context and efforts that went into
making Open Source and Free Software what it is today. We're all standing
of the shoulders of the giants that created those licenses and defended
them in courts. But take this parting thought: we regarded the Cathedral
development model as both Free Software and Open Source. In that model in
between releases only selected people had access and control to the
source. Where forks were limited to starting with the public tarballs of
some software that only appeared at irregular intervals. Maybe if one
considers that development model, the FSL doesn't look quite as foreign
and restrictive.</p>
Post Covid Remote Work Doesn't Work As Wellhttp://lucumr.pocoo.org/2023/11/1/remote-before-and-after-covid2023-11-01T00:00:00ZArmin Ronacher<p><em>This year I decided that I want to share my most important learnings about
engineering, teams and quite frankly personal mental health. My hope is that
those who want to learn from me find it useful.</em></p>
<p>You can't make it 15 minutes on Twitter or elsewhere, without running into
a post about a botched return to work implementation. You also can't make
it for very long to hear about the San Francisco doom loop. These two
topics relate in a quite deep way to me personally. This post is a
reflection of working at Sentry for almost 10 years, a company primarily
headquartered in San Francisco and how it is to work for it from a
distance before and after Covid.</p>
<div class="section" id="cities-are-magic">
<h2>Cities are Magic</h2>
<p>I'm a being that thrives in cities. In fact, I'm genuinely amazed every
day how humans have managed to form societies where cities can
function. But not only function, but function really well. They are
quite remarkable because they greatly benefit of economies of scale. You can
provide services in cities that would otherwise not be possible economically,
because there are not enough people around that otherwise are in need of
that service. As a friend of mine once described: cities are like small
social experiments. Each city uniquely nurtures specific communities, each
with their own values and ideas. Since forever I have been a software
developer (amateur or otherwise), there was really only one city heralded as
the city of technology: San Francisco. It has a profound impact on many of
us, even if we don't live there.</p>
<p>It's not the city I want to live in, in many ways it's running the kind of
social experiment with outcomes I'm not attracted to, but without doubt
that experiment has an impact far beyond its borders. I'm in many ways a
beneficiary of its existence.</p>
</div>
<div class="section" id="solitude">
<h2>Solitude</h2>
<p>Where cities shine is collaboration and meeting like-minded folks. Where I
grew up, I was the only programmer in a tiny town. If you want to talk
with others about your problems, the internet really was the only place.
I took advantage of the opportunities that IRC, bulletin boards and
mailing lists gave me. It allowed me to meet people that were otherwise
outside of my reach.</p>
<p>My theory on what makes a successful company or project is collaboration
and some shared, deeply rooted values. In some ways we sometimes do not
quite know what our values are, we just “get them”. We get them because
when we talk to each other we get subtle hints about being on the same
page about a topic. Alongside that there is shared excitement about
subtle, small details or things one could build. This kind of shared
understanding can exist in a purely virtual form, but that can take years
to foster. Finding like-minded people through the internet is what
brought me to where I am today. Yet in many ways as I grew older I also
realize how much harder this is. Compare this to meeting people in person.
A day in person with another human being can replace a week of async online
collaboration and a month of chipping away at a problem in isolation.</p>
<p>When I started working on / at Sentry, I already knew enough about <a class="reference external" href="https://cra.mr/">David</a> that I knew we're on the same page. On the other
hand, I also knew that San Francisco wouldn't be the place for me. So if
I wanted to work on Sentry, I also <em>had to work hard</em> to make remote work.
The way I went into remote work for Sentry I was determined to figure out
how to make the situation beneficial for everyone involved.</p>
</div>
<div class="section" id="making-remote-work">
<h2>Making Remote Work</h2>
<p>In early Sentry days I felt a lot of pressure on myself to make my remote
work situation successful. And I loved that. It forced me to work
towards finding the advantages in that situation. Initially this
primarily meant better time zone coverage, but it also meant that I took
customer calls in the early Sentry days to connect with European
prospects. I managed to compensate for my remoteness in other ways. I
also intentionally shifted my days to be closer to my US colleagues and
eventually hired more folks around me.</p>
<p>Today there is an engineering office for Sentry in Vienna where I live.
It's not a huge office, but I'm very proud of the accomplishments of the
people working there. Vienna isn't a city known for its developer
community, in fact it's probably not known for that much to begin with.
So in many ways having an office here was a gamble. In a similar way to
how I tried to find reasons for why my remote situation at Sentry works, I
also approached the office in the same manner. What's the social
experiment that Vienna is running, that aligns with the needs and desires
for our company? Given that Vienna isn't an engineering hub, the talent
pool is more restricted compared to San Francisco. On the other hand it
also means that you can create an environment that focuses on retaining
engineers. Vienna is a great city that enables pleasant commuting, is
comparatively cheap, very international and great for cities. There is a
genuine reason to work here. But the point is: both my own work situation
as well as the office I approached with a certain level of anxiety that
made me work for it.</p>
</div>
<div class="section" id="covid-broke-the-system">
<h2>Covid Broke The System</h2>
<p>And then Covid came.</p>
<p>And quite frankly with Covid a lot changed in fascinating ways. I will
admit that I completely underestimated the impact that a Covid imposed
remote work environment would have on us. And not just us, but quite a
few folks around me as well. How was this possible? How could remote
work, something I have been practicing for years all the sudden not work?
How could this be so bad for a few months during Covid?</p>
<p>With the power of hindsight I think the biggest difference between before
and after covid remote work, was how we all went into it and how much more
extreme it was. I spent quite a bit of time talking with others who have
made remote work and it comes down to the same: it's very intentional, and
it involves understanding how to deal with the downsides. Covid remote
work was nothing like this.</p>
<p>"With the onset of Covid, many individuals who previously had little
experience with remote work suddenly found themselves working from home.
Unlike earlier remote work scenarios where individuals made significant
efforts to adapt, the pandemic brought about a shift in expectations.
Folks rightfully began to demand better support for remote work from us.
And it wasn't just us, I have heard similar stories from lots of others.
In some situations people moved quite far outside the cities where
they worked during Covid. In some cases that was unavoidable. When you
have your partner and your kids at home 24/7, you might need a change in
place. But even after things normalized, the offices were much more
reclusive than before. The dynamics completely changed. There were fewer
people in the office and collaboration between teams from different
offices decreased.</p>
<p>This year, I engaged in numerous conversations with various individuals
about the challenges posed by remote work and Covid. Probably not
entirely surprisingly, very few mentioned any positive impact of Covid
on work culture. Even more concerning is the negative perception of remote
work in some areas. This has led to unexpected and stringent return-to-office
policies, affecting even those who were originally working remotely prior
to Covid as collateral damage.</p>
<p>One of the changes with Covid remote is that people work from home that
previously were in the office. This even includes myself. This in
practice easily ends up as a net negative unless you compensate in in some
other way. We miss out on non-verbal communication, spontaneous hallway
chats that can lead to resolution of current issues, and the casual office
banter.</p>
</div>
<div class="section" id="fixing-it-with-intention">
<h2>Fixing It With Intention</h2>
<p>I don't think we can go back to pre-covid life, the world has changed.
What I think we can do, is be more intentional about how we go into this
hybrid work situation. I believe the biggest improvement from where we
are to where we can be is reflecting actively on the downsides that remote
works gives us. I <strong>love</strong> remote work, it gave me the ability to work
with great people over the years which would otherwise be impossible for
me to work with. Yet as you have seen, I'm painfully aware of the downsides
that it brings. These downsides just need to be more directly addressed
and I believe that sort of addressing only in parts comes from company
and engineering management, it needs to come from everybody.</p>
<p>If you have a remote work force, one needs to find natural opportunities for people
to meet face-to-face. Even if it's just annual get-togethers of managers.
it's not the catered breakfast or office event that fixes this, it's
the getting together with intention, the fostering meaningful
interactions. Our hackweeks, for instance, have spurred incredible
collaboration far more than any catered breakfast ever did. A focused
six-week sprint with a clear but ambitious goal not only enhances
engagement but also naturally encourages in-person meetings. I've found
that our off-site meetings, which ironically felt like on-site for many,
with a clear objective, have rejuvenated team morale more than any other
initiative.</p>
<p>If you're an employee seeking remote work, it might be beneficial to adopt
a pre-Covid mindset and present a compelling case for it. The most
desirable companies are likely the ones that uphold rigorous standards for
remote work going forward. Ensure you have a valid and convincing
rationale for your remote work request.</p>
</div>
<div class="section" id="scale-and-encounters-by-chance">
<h2>Scale and Encounters by Chance</h2>
<p>If you are a small company, remote is almost natural. You have
established trust, everybody knows everyone and it doesn't matter that
much how you work. The office banter might as well be the one slack
channel. But that just doesn't scale. That tightly coupled model stops
scaling really, really quick. Today there is not one slack channel that
has everybody at Sentry in. And it's not just that.</p>
<p>There is a lot a physical space gives you at scale: you see people's
happiness and frustrations. You see their motivation or lack thereof.
Working in a larger office is a shared experience. Everybody feeds off
each other. We turn from individuals into a shared body. Sometimes good
things happen, sometimes bad things happen. Sometimes people run into
each other not just for work reasons but also because they undergo some
other shared concern. We live in times of war and a climate crisis, and
many of us have friends and families who are affected. You might not
want to necessarily have these conversations at the work place, but you
will see the despair in your fellow coworkers when you grab a coffee. You
can reach out, you can talk, you can support. The best emoji game will
not replace that kind of encounter.</p>
</div>
EuroRust 2023 Reflections: What's a Conference For?http://lucumr.pocoo.org/2023/10/14/eurorust-whats-a-conference2023-10-14T00:00:00ZArmin Ronacher<p>I very rarely write recaps of conferences but this time around I could not
resist. This is for a lot of reasons. To kick things off, quite a bit of
what was on my mind relates quite directly to a perception of a general
negativity in the Rust community that I share. Most specifically <a class="reference external" href="https://blog.adamchalmers.com/rustconf-2023-recap/">this quote
by Adam Chalmer</a>:</p>
<blockquote>
Rustconf definitely felt sadder and downbeat than my previous visit. […]
I felt like this year's conference was <em>defensive</em> and maybe somewhat
<em>depressed</em>. I wanted to give the spirit of Rust a hug and tell it,
"hey, I know you've had a tough year".</blockquote>
<p>Not only did this get me thinking, I also <a class="reference external" href="https://twitter.com/mitsuhiko/status/1663559716180758537">had a lot of reflection to do</a> about myself
and Rust this year. In case you are not familar, I posted a regretful
tweet in response to the <a class="reference external" href="https://fasterthanli.me/articles/the-rustconf-keynote-fiasco-explained">keynote fiasco</a>.</p>
<p>Those reflections let me come to the conclusion for myself that
the following three things would be good for us as a Rust community:</p>
<ul class="simple">
<li>Rust conferences need more purposefulness</li>
<li>Online discourse is toxic and we need to meet in person</li>
<li>The Rust Project needs an All-Hands</li>
</ul>
<p>Let me elaborate.</p>
<div class="section" id="rust-conferences-and-purposefulness">
<h2>Rust Conferences and Purposefulness</h2>
<p>I have several critiques of Python, but I must admit that the Python
community has excelled in certain areas over the years, and one of those
is their conferences. How good Python conferences are is often only
apparent once you go to other events that don't quite meet the same standards.</p>
<p>One aspect where Python shines, and which I believe is somewhat lacking in
the Rust conference landscape, is the clarity and purpose. When you
attend a PyCon, you can anticipate a particular style of conference, and
if you happen to attend <em>the PyCon</em>, you're guaranteed a well-defined and
cohesive conference experience. You know what the PyCon conference is and
what you get to expect.</p>
<p>Rust has a few conferences these days but it's not clear who the target
audience of that conference is. Here is my current interpretation of what
the conferences are for:</p>
<ul class="simple">
<li>RustConf: It's the Rust conference of the Rust project where we get to
hear the thoughts of the Rust project and nerdy things.</li>
<li>Rust Nation: a classic conference for users of Rust.</li>
<li>EuroRust: a blend of RustConf and Rust Nation maybe?</li>
<li>RustFest: a former travelling conference for Rust users?</li>
</ul>
<p>I confess that I'm uncertain if my interpretation is entirely accurate.
From both the perspective of a potential speaker and an attendee, the lack
of clarity about the purpose of these conferences leaves me hesitant.
This also comes up when pitching or preparing a talk. At EuroRust this
lack of clarity was at least in parts apparent by the somewhat random
collection of talk topics.</p>
<p>In my personal opinion, I believe Rust should consider two distinct styles
of conferences: one that deliberately fosters connections between language
developers and the core community, and another aimed at language users.
These two conference styles would quite likely feature different types of
content and cater to different audiences.</p>
<p>I initially perceived RustConf as a platform for major language
announcements, much like Apple's WWDC just for the Rust project. However,
I've come to understand that this perception is somewhat subjective and
not universally shared. It's essential to establish a clear identity for
the conference and communicate its purpose effectively.</p>
<p>Personally, I contemplated attending RustConf this year, but the
conference's location in Albuquerque (which is really inconvenient for me
to go to) and the lack of a clear conference identity made it less
appealing to me.</p>
<p>My fondest memories of Python conferences are the sprints, are the
“Birds of a Feather” sessions, the hallway track, connecting to people
eye-to-eye. The latter being particularly important. <a class="reference external" href="https://lukasz.langa.pl/">Łukasz Langa</a> described me this year as “more nuanced in
person [than online]”. I believe this to be true to all of us. I don't
even remeber having a bad experience with someone in person, even if I had
massive disagreements on Twitter or an issue tracker.</p>
<p>I think it should be the task of a conference to enable this. EuroRust
2023 could have done better in enabling attendees to network and connect
with each other. Here are some of my thoughts for a better hallway track
experience:</p>
<ul class="simple">
<li><strong>Double sided badges:</strong> the badges were single-sided, and the lanyards
made it easy for tags to flip over. It was incredibly hard to read,
especially for people like myself who have a hard time matching faces in
real life to online identities. This is also feedback I heard from
others. So, next time around, make sure they are always visible.</li>
<li><strong>Badge addons:</strong> just seeing the badge is not enough because it's
really hard to spot people. PyCon has these awesome extra stickers that
you can hang underneath your badge to augment it. The basics are
somewhat obvious (no pictures, what are my pronouns) but the really
useful ones are great conversation starters. Am I a maintainer? Am I a
core dev? Am I a sponsor? Am I a speaker?</li>
<li><strong>Better hallway layout:</strong> The layout of the conference venue, in addition
to the badge-related challenges, significantly hindered the ease of
spotting and engaging with fellow attendees. The absence of clearly
designated spaces for mingling and initiating conversations was really
making things difficult. I've noted how other conferences have successfully
implemented specific areas, such as topic tables, to bring together people
with various interests. Even a spacious, open area like the one at the
Berlin conference last year provided a more effective setup for fostering
connections and discussions. Consider reevaluating the layout to
encourage more meaningful interactions among attendees.</li>
</ul>
</div>
<div class="section" id="toxic-discourse">
<h2>Toxic Discourse</h2>
<p>I had a great experience at the conference. I had good conversations,
meaningful discussions, and did not feel any animosity. Among the people I
talked to, there was a widely shared recognition that the sentiment and vibe
in the community is unnecessarily bleak. This is not something we can fix
overnight. Much of this negativity comes from Twitter, Mastodon, issue
trackers, and other online environments. We can be quick to write a
hurtful or snarky remark that lend themselves to misinterpretation.</p>
<p>Growing communities make mistakes, many of us have made missteps. In many
of those cases however that is out of our failings and not bad intentions.
As mentioned earlier hallways tracks are a great way to meet people. They
are also an amazing way to find out that people are much nicer in real
world than their Twitter profile might make you believe.</p>
<p>We also in some ways are victims of our own success. We are too large of
a community to be able to come to a consensus on everything. But we can
respect each other, in particular when we are of different opinions.</p>
<p>This leads me to the most important aspect:</p>
</div>
<div class="section" id="the-rust-project-needs-an-all-hands">
<h2>The Rust Project Needs an All-Hands</h2>
<p>EuroRust's partial failure is the shared failure of RustConf. The people
that go to those conferences are geographically split, and some of the
folks that did the most for the Rust project are not going at all. This
is not good.</p>
<p>The combination of the “graduation” of Rust out of Mozilla, the pandemic
and just a lot of churn in the Rust project has left a void. I wish that
a goal of the Rust Foundation would be to help finance regular get-togethers
of the core Rust project (and maybe former influential members), key players
in the community. The best solutions for problems are found when a group
of people meet in person with a goal and desire to hash things out.</p>
</div>
<div class="section" id="things-are-okay">
<h2>Things are Okay</h2>
<p>Rust has never been so successful and it never has been as enjoyable as
today. It's a great language, there are amazing people in the community.
More and more people are using the project and many communities are
looking up to the developer experience that we enjoy.</p>
<p>The conference was great, I had a good time. It's a really good starting
point for even better conferences going forward.</p>
</div>
Lessons from a Pessimist: Make Your Pessimism Productivehttp://lucumr.pocoo.org/2023/3/20/lessons-from-a-pessimist2023-03-20T00:00:00ZArmin Ronacher<p><em>This year I decided that I want to share my most important learnings about
engineering, teams and quite frankly personal mental health. My hope is that
those who want to learn from me find it useful.</em></p>
<p>I consider myself a functional and pragmatic pessimist. I tend to err on the
side of anticipating the worst outcome most of the time. This mindset often
leads me to assume that things are more difficult than they actually are, but it
also highlights potential pitfalls along the way. In some ways, this is a
coping mechanism, but it also aids in problem-solving and sets my expectations
low, frequently resulting in pleasant surprises.</p>
<p>However, in recent years, I've more and more encountered a different kind of
pessimism in others that I deem destructive. This type of pessimism sees no
good in the world and renders people feeling powerless. I thought it might be
worthwhile to share why I am not entirely consumed by gloom.</p>
<p>Destructive pessimism involves either wanting or expecting things to fail. At
first glance, the aspect of not expecting success may appear similar to how I
operate, but there's a subtle distinction. I generally anticipate that things
will be challenging but still achievable, and when it matters, I want them to
succeed. An extreme example of destructive pessimism on the other hand is
expecting climate change to end the world and assuming society will do nothing
to prevent it.</p>
<p>Whatever I personally do, I want it to be successful. I don't search for reasons
why something won't work; instead, I focus on how to make it work while addressing
or avoiding the issues I see along the way. That does not make me an optimist,
that just makes me someone who wants to get stuff done and someone who strives for
positive outcomes. On the other hand optimism to me is expecting to succeed
against all odds, something I do not do. I fully expect that there will be
failure along the way. (I also love venting about stuff I don't like even if it's
not at all productive).</p>
<p>Many individuals in today's economy worry about their retirement and harbor a
general negative sentiment about nearly everything, from the unfairness of the
labor market and increasing poverty to climate change and more. Believe it or
not, I share much of this negative sentiment, but I've learned never to let such
thoughts govern my life. Dwelling on negativity regarding your employer, job
prospects, government, economy, or environment — especially when it's difficult
to influence these aspects — leads to nothing but unhappiness and depression.</p>
<p>Our times are marked by a number of transformative events. A recent
conversation about AI I had with some folks I think is quite illustrative about
how you can be a pessimist yet still be excited and forward looking. What's
happening with AI at the moment makes a lot of people deeply uncomfortable. On
the one hand some think that their job is at risk, others are trying to fight
that future out of fear by attacking the foundations of it from all kinds of
different angles. This fight comes from copyright law, various moral aspects
as well as downplaying the status-quo capabilities of AI. All of these things
are absolutely worth considering! You might remember from a <a class="reference external" href="/2023/2/17/the-killing-ai/">recent blog post
about AI</a> that I myself posted something here
that outlines some of the potential issues with AI. Nevertheless, AI will
continue to advance, and being afraid of it is simply unproductive. Rather than
becoming despondent about AI, my pessimistic side assumes that things can go
wrong and acts accordingly, all while giving the technology a fair chance.</p>
<p>I am absolutely convinced that it's important to recognize the difference
between a pragmatic form of pessimism and destructive pessimism. And as
cheesy as it sounds, try to surround yourself with supportive individuals
who can help you maintain a positive outlook and try to be that person for
others. You don't have to be an optimist for wanting to succeed!</p>