Hey, well, once again, welcome to your next talk.
We have here Pierre Reeves, Eves, and Raphael, presenting material 20 years and counting.
So thank you very much and take it away.
Hi, hello, can everybody hear me fine?
Yep, cool.
So we are Pierre-Vanafel.
We work at a small company called Oktoberz, we're specialized in version control, and
specifically in Mercurio, a version control software that is 20 years old and we're going
to talk about its journey and why we're still here.
And why we're here today talking about it.
So first we're going to start with an interactive slide.
Get your hand up, please.
Everyone.
Yeah, thank you.
Everybody raise your hand.
Keep your hand up.
If you knew that Mercurio existed before coming to this talk, yeah, pretty much.
If you've ever used it before, okay, fewer people, if you are using it today.
Yep, some people are.
If you think the project is active, more people raising their hands again, nice.
Okay, so we thought that it might go something like this.
I think the blue E-lips was kind of maybe overconfident in its size, but generally I think
that a lot of people have heard about HG, this is kind of a self-selecting audience, but
if you go around most people have heard about Mercurio at some point, but the bull that's
still used Mercurio and know that its active is actually quite a small minority now.
So how Mercurio is usually portrait is, it's a distributed version control system that's
very old, it lost to get 10 years ago, and it's written in Python and it's slow.
It has 95% market share, Mercurio has 1%.
That's the usual framing of it.
So why talk about it, why am I here, why are we here?
We keep having the same conversations over and over again at every event and every conference,
every person we bump into in the hallway, and we have to say that we are paid full-time
to work on it, have been since 2013 for Piav and 2019 for myself.
We are not the only ones to be full-time paid and we have volunteer contributors.
We are still doing a lot of things, and we want to talk about it because it is, as I said,
still active, still innovative, and still influential.
So let's give an example.
I can run an AG status that takes 100 milliseconds to complete for 1 million files on disk.
No other version control system can achieve those speeds, especially without ionotify
and within a single process.
That means that this is significantly faster than Git, at least in its current form,
and faster than actually using ionotify as well, for those of you who know FS Manager
all of that, it is faster than using ionotify, and it is definitely faster than ionotify when it breaks.
Mercurile is still influential.
Two years ago Scott Chakon of Git Butler and GitHub fame gave a talk about Git and the recent
advances recent at the time of Git, and he talked about six different points, which we will not get into,
but three of those with the check marks came from Mercurile or the Mercurile community.
Having a commit graph to speed up operations, the fastest money to think I was just talking about
was first introduced in Mercurile, and the ability to check out this smaller subsets of your
entire repo was a Mercurile thing.
The previous talk, I don't know if anybody stayed over from the last talk, but if you did,
thanks, yeah, and so just to talk before Patrick talked about a bunch of stuff, and two of those
are directly from Mercurile heritage. The logic of the promises not in their implementation,
but the practice of having large files that are transparent to version control has been around
for 10 years in Mercurile, and the Git history command and the absorb concept and having one command
to manipulate your history has also been there for 10 years. Now, at this point.
So, how did we get here? It's 2026. We have about 45 minutes left.
Recapping 20 years would take about two minutes per year, 30 seconds per version,
and 15 milliseconds per commit. Thankfully, we are not going to dive into every single detail,
and we have a more structured approach to this presentation, and I will head it over to Chive.
Okay, so before going into what Mercurile is today, let's get about where Mercurile comes from,
and from the dawn of time, and by that, I mean January 1st, 1970, people have been trying
to version control their code, and at that time, for a while, we add a new tool about every decade
that improves over the other one, and the field improves slowly like that,
neutral replacing the other. However, something different happens in the 2000s, where
internet, encourage collaboration and things like that, and a lot of new tools arrive. Like,
we have new arch, darks, monotones, actually all-gid, but our fossil, probably a lot of other tools.
If your tool is not there, and it's still alive, please come make it up first,
then next year, to explain why. Let's zoom a bit on the material and get things.
People often don't realize how close the project are. If look at what they do and what they
come from, they where release the same month at a couple of weeks about in April 2005,
they were developed for versioning the Linux kernel, they were developed by canal developers,
and they took inspiration from a previous version control called monotone, and
their main data schema is basically a Mackel graph using shawan to identify content. There
is, of course, a lot of difference in the implementation, but there is also very much common things.
There is, at the conceptual level, there is only one big difference that we will get into later
but overall, there is a lot of equivalence between the two. It's also a very good time
for version control because you have a lot of tools, they all try different ideas, they exchange
ideas, like it's a small example, where material is giving is interesting feature that
is going to be used, it is interesting feature that material is going to be implemented,
and also tool that didn't add as much success, like darks, still do a lot of interesting
innovation regarding patches, partial commits, partial application, this kind of thing.
And like material, as advantage at the time and at the green user base, at about the same
base as git, it usually pick because at a nicer UI, it adds more feature like copy tracing,
it was also much more portable than git, because it's Python, it could run efficient,
like without much we work on Mac on Windows, and still nowadays, we have add people using
material on plan 9 or OpenVMS, and things like that, like very strange platform, because
it much more possible, it's kind of still today. It had a peripheral extension system that
helped people to do more things, it had early editing, story editing, and then more advanced,
story editing, last-family link came early, there were multiple iterations of that, and it had
overall a safer UI with a philosophy of we want to prevent the user to do mistake instead of
helping the user to undo the mistake later, and Benchof adventure show. So the two projects
started the same time with a lot of thing in common, and for a while they grow together in
an adoption, they are like small player in a wider field, dominated by other stuff, but at some point
git started to grow significantly faster, and Mac, you all start to stagnate and slowly
reduce its user base. There is a lot of reasons why it might add going this way, like it's not
a simple black and white answer, but one key element in there is the introduction of GitHub.
It is a comparison of Google Trend between GitHub and BitBicket, BitBicket being a fraud,
supporting MacRail, and you see that they are both starting in 2008, and GitHub immediately
started to pick up, and faster and faster and faster, and compared to GitHub, BitBicket is basically
flat, until about 2012, which is the moment they introduce git support. So with this, we see that
MacRail will definitely last the battle to MacRail, and was kind of on the trajectory to be like
the other two, like, better or dark, to less users. However, it didn't happen that way, and why.
In the 2010s, more or more people were doing MonobiPos. You have one source repository, where
you put all your source code. And especially, there are two companies that join the MacRail community
to under the MonobiPos, and they are Facebook and Google. And because they joined the project,
a lot of things happen in MacRail at the time, that didn't really happen elsewhere.
I'm not going to cover them in details, but we add a lot of new features that landed at that time.
Tell them then you might recognize because they are getting now in other stuff, but a lot of things
happen at the time. So why did these people pick MacRail instead of Git to deal with the MonobiPos?
Git was different, it's a leader, it's kind of weird to pick a small pair like MacRail. There is,
first they tried. There is email thread you can check, where Facebook go on the Git mailing list,
and say, oh, we are trying to scale Git at that scale, and we have troubles. Do you want like
millions of dollars of engineer's time to speed up your project? And the answer was kind of,
no, I mean, you can check this right. And there was other argument of why MacRail was a good pick
to do this. And one of them, the two single one is about the Git API.
So aside from the, what you just said, the human reasons, the philosophical divergence between
what Git was trying to do and what Facebook and Google were trying to do, there was also,
there's also a difference in fundamental differences in the model of Git and MacRail,
and Git's API kind of pates it themselves into a corner. So what is Git's stable API?
You might have heard Git presents these layers as I have the personal layer, which is the user
facing stuff. You have plumbing, which is the more lower level data handling layer. You
have the binary files that actually live on your disk. This is the API that is presented in the,
in the history of Git. And in practice, this is what happened. You had all of these different tools
that didn't really talk to the CLI or did it partially. And directly, and directly just looked
into the binary files. So your API became the binary file. If you're writing as it is
H prompt or if you're a lib Git to or GitHub site or whatever, I mean GitHub site is slightly different,
but that's kind of the same point, which is that they are all looking at some way in one way or
another looking at the binary files on disk. The previous talk went into a detail as to how they're
trying to change that being a problem and having a library nowadays. But this was definitely the
status 10 years ago and is still the case now. Having this structure has some advantages. It's
simple. The Git structure, the initial Git structure is quite simple. It's actually quite brilliant.
It's very easy to access. And it helps growing tooling quite fast. For example, if you want to build
an IDE, if you want some, some graphing tool, a GUI or like a ZSH prompt, for example, or whatever,
a shell prompt. This is quite easy. You could just plug in read whatever data you need and be done with it.
So it helps foster an urgent environment of experimentation in that sense. However, it is very hard to
change. I think I don't need to get into detail too much as to why, but it is quite hard to change.
Whenever everybody looks at the need to greet the details, whenever you change any detail,
everything breaks. So there's also the aspect of it being simple, doesn't mean that it's right.
And especially it doesn't mean that it will keep being right. Git might have been the right answer
to the problem that it was trying to solve in 2005, but the world keeps changing and evolving
and the scales are not the same, etc. And so it being simple is a good thing, but it's not enough.
And this is kind of what we were saying. If you want to change everything, if you want to change
anything, you need to convert the whole ecosystem first and lockstep before changing anything.
One example of this particular stack problem and binary phases in API problem was Microsoft in 2017.
They were trying to scale their large Git repo and they tried to look at what was the performance
problem and the performance problem was the access to the .Git directories. And so what did they do?
They implemented a virtual phase system because that's the only way you can do it.
If your interface is the file system, then the only way you can change the interface
without significant community efforts is by doing a virtual phase system. Another example is the
Reftable thing, which is instead of having a bunch of all of your Git Refts stored as single files
in a folder. It's a binary packed format. It was decided in 2013. It was first implemented in 2017 in
J. Git and then became part of canonical Git only in 2024, which means that you have a 10-year
span between the start of the project and it's becoming a reality for everyone.
That doesn't mean that Microsoft hasn't had this fair share of stuff that has lagured over the years,
but this is kind of a good example of how there's an immense inertia to change.
In contrast, the Microsoft stable API is much higher. Remember the layers I was showing earlier,
Mercurals API, the official one, and the one that most projects have ever been plugged into,
is the CLI or the server, the server being the wire protocol, talking about clone push pull,
that kind of stuff. Some things plug into the logic or the data access code, but they are
extensions that are forewarn that everything can break at every cycle and often does, which means
that they have usually been more tightly coupled with the upstream project, meaning that
everything moves together and encouraged to be thought of as a whole project.
This layer was very useful for all the companies and the contributors trying to create
new workflows and new ways of doing version control because you could have, you could change,
repout everything from underneath the user without them realizing which unlock scaling capabilities
and many different features. Because it turns out that some distributed version control systems
are more distributed than others, so I'll let PI talk. So another aspect that is more subtle
and that didn't really explain a bit the scaling aspect, but it also explained why
there has been so much innovation in terms of user interface and workflow within the Mercurals space,
is as to do with the concept of our Mercural modelized data. And it's a complex topic and I don't
want to turn this into a full computer science lecture, so I'm going to take a small example
to try to make that clear. The main difference when the Mercural start between Git and Mercural
is the Bernchick model in terms of concept. They both have a graph, like you have commits,
they have parents, you do things. So they both have run to the very same way, like actual
topical branch, but there is difference on how you modellize it in the UX and how you deal with
it when you exchange. In Git, a branch is a label that you put on a commit that is going to move.
So on the left you have the Git version where you have the main branch that is unaccommit and you
have the shrub branch that is unaccommit and how you define your shrub branch. In Mercural, the branch
information is within every commit. It's a property of the commit. You make a commit on the different
branch or you make a commit on the shrub branch. And from that state, the state of the graph,
you can compute where the edge of shrub is and where the edge of default is, but it's a property
that you that emerged from that and not a label that is explicit. So when you get a new ed, for example,
when you pull from somewhere, in Git you have to create a new branch with a label with a conversion
that say, oh, this is actually kind of the same thing. Well, in Mercurial, it kind of just happened.
You pull a new chance with the same label. So if you look at the graph, you see there is two
add-on-through because that is the fact that there is two add-on-through. A recent health after that
is kind of pretty much the same. Like you can do merges and in Git you move the label in Mercurial,
you just appears to only have one ed remaining. You can manage them back into another branch
and think like that. There is a very useful way to do branching in Mercurial,
some are persistence, some are not persistent, I'm not going to get into that now to focus on the
core differences. But the important part is that you just, you have a simple model that can
express any kind of complexity in your branch, like how many branches you have and how many merges and
things like that. So this is not something you would actually see, but this is no more complex
at that model level and at the conceptual level. This weird branch with the turn of ed and turn of
merges is no more complicated to express than the usual two add-sings. And so the way to see that
is that Mercurial has a global state where you action, everybody sees the same thing,
was while Git has more or for local state where the branch has a local value. And the way to see
it is when you add the two add in if we look at that branching slide. When you do this
synchronization, that is the previous one. When you use this synchronization, that as the two the
true branch, in Git, this is the time where you get to branch. Like you pull something locally
and a new branch is created and now you have to add. In Mercurial, you add the two adds all along,
like you already have the two adds that exist when the two people do the commit on their machine.
And when you synchronize yourself, you discover like someone discovered it as two adds,
but they were here all along. Getting back here. So we have something that is more global and
shared in Mercurial. It's not just necessarily better or worse, but it's different. And especially,
it means that the branch in Mercurial are just that attitude exchange the same way that every other
data. While in Git, you have to have specific solution. Like you have the remote naming,
so that the branch, I have a specific name, you have a solution for tracking, you have a solution
for false push and this kind of thing. You have to have specific solution for a specific problem
while in Mercurial that just basically emerge. It gives you a model that is more flexible that
propagates simpler. And this apply for pretty much every other concept in Mercurial. Like we have
the face concept that prevents you to be white stuff that you not be bewwritten, the same like
it's global in propagates. We have the same four tags. There is a bunch of problem with the
tag model, but the propagation is not really one of them. Like it's as the same property. And
pretty much every thing else in Mercurial, stick to that model. So the global model of the data is
the CRDT, CRDT is done from config free replication data structure, which means you can
you can propagate the tree. The Mercurial data model, model in inevitable state. The fact that you
can have to add at some point is something that will happen because you do distributed development.
It's not something we invented. It's just we model something that exists. And it's a valid state
in the model. It's not something you have to fix right away. You can keep doing other stuff. You can
ignore this to it for our law you want. You can ever exchange them with someone. Like if I
need to merge something and I don't know how to merge it. I can send it to Raphael. It will
merge it and I will get the merge. And there is no problem like that. It's valid state. You can
exchange and propagate. It means you have a single unified concept too. Like we don't care how you
get to add. Maybe you get to add because you pulled something or maybe you got to add because
you imported the bundle or imported an email or because you created themselves. All the way
all the different ways in the same state. You can solve it different ways from the same state.
You have something unified that really limit the complexity when you start to combine this concept
together because they converge to the same thing. And that unlocks a lot of options in terms of
workflow and operation. You can do your own scaling and things like that. A good example of that
is the way Maxwell do history with writing. In Macriel you have an evolution history for the
transit which means that whenever you do a history with writing operation like an end-end or
rebate or something, we explicitly tracked what happened with new data in the repo. You can see
that as the history of the history. That history of history is a CRDT. So it has all the property
we talked about before. It's easy to exchange. The state that it represents, you just compute
state because it's like which sunset are there, which sunset are alive, what kind of problem you have
when you start to avoid the distributed setting. We can express them because they exist and
they are valid state. So we can automatically be fixing issue and we can do again like
exchanging things with other people, propagate data and things like that. And this create a kind of
even for stag default flow. Because when you do a command in any tool, you need to move from
the stable state to a stable state. And because we have model that are much more expressive,
we can have finer state that get in get when you do rebates dash i, you need to move from
a linear branch with one add to a linear branch with another add. While in Macreal, you can have
a lot of intermediate state that have valid representation. We can do that locally, locally and
globally. You can express a lot more state also when you collaborate with other people in this
suited way. And that get as faster to win growth in that area. People can play with it
a lot more common, we will work flow and sing like that. An example of that that you might have
sing quickly is like rebates and push. They use something like use something where when you push a
chance it is going to be rebates server side and then serve back to you. And they don't have to
invent a specific solution for that. They can just build over all the things that already
exist that just represent that operation happen. It's no different from your rebates locally
or your collect release. All the things converge to the same thing. I would like we could talk
about this much longer but there is all of it to be covered. Let's switch gears a little bit
and go maybe away from the technical aspects of this and more about what happens when
giant corporations get into your open source project and start contributing.
There are very obvious upsides that I want to underline. This talk needs to talk about the
problems that doesn't mean that we didn't enjoy the upsides. There are more contributor in general,
more contributing, more funding for CI and for infrastructure and for sprint hosting which means
that people's hotels can be paid for them and we can exchange for travel, etc. And also quite
importantly the project becomes more credible. When you hear, oh, make your old powers, the
Google, the UI or whatever. Then it's people think that it's quite important. It gives way to the
project. There are many upsides. I don't think anybody is really interested in releasing all of the
upsides. Again, we're not forgetting them. But there are of course many downsides. You have a
big problem of sovereignty of how your project can manage itself. One thing that can be subtle
is that you have contributor drain. So in a usual open source project that is lucky enough to
have contributors because that's not most of them. You have people from all over the world and
all over different profiles. You have the weekend warrior and you have someone who is in a small
company and you have all of those different profiles. And when a very large company comes in, they
have large problems. They have a lot of money. And so what they do is they approach people from other
companies. They hire people from the community which gives a boost of productivity and a boost in
in focus, which is nice. But also what happens is that your contributor base becomes all of your
ex kind of moving to giant baskets. And mid-sized companies have no consultants left for them.
So your problems are spaced out between the few people that are here because they enjoy the sport
and the people that are fixing their companies' problems. So that leads to a general loss of
organizational skills as a project. For example, when I joined the project in 2019, which was near
the kind of the end of that era, we still had post-lending CI, meaning that changes were put into
the project before they passed through any form of rigorous testing. Maybe it was testing on someone's
machine who knows. But it was usually like we caught break it after it was landed. We had no first
class forged to speak of. We had ways of exchanging patches and doing code review, but it was not
material was not a first class citizen of any of those those projects. And on a more
more organizational scale, we lost our ability to do hosting and sponsoring pipeline in general
of how you get money into the project and how you distribute it kind of got lost in all of this.
Another way of looking at it is the product versus toolkit dichotomy.
So a product is something that is plug and play. In general, you can buy it, you can download it,
you can install it, you can whatever. And then you maybe tweak a bunch of config knobs and then it works.
A toolkit needs some assembly. A way of seeing it is a material became a toolbox for larger companies
to have a version control system and build theirs on top of it. And so the project started not
being as ready to use outside of these environments and needed more configuration, maybe even
some infrastructure. And let me tell you, you cannot just APT install the infrastructure from Google.
Some companies were better at this than others. I took Google as an example, but they were actually
quite good at upstreaming their changes and working with us as long as they were still using
material. Some companies were not as good. This kind of moves to the works for me,
probably works on my machine works for me thing. When you contribute something upstream in
material, for example, and Google had everything in their infrastructure is so controlled that
they actually don't really care about hashes. When you think about a committee, you think about
it's hashes and you know that you can identify the exact tree that is under this hashes and you know
exactly what that is byte provide. They don't really care about that. And so sometimes they implemented
features that kind of didn't make sense if the hashes were unstable. It only made sense because
they didn't care about hashes, for example. And sometimes other things were upstreamed with no real
server implementations. You only had the client code, but the part that actually made it work,
the server side was only on their machine and not in the project. And this is kind of the
whole point of the incentive mismatch. People that work in large companies usually try to optimize
for internal impact. What they want to do is they're hired to do a job and they want to fix
an issue quickly. They have their managers breathing down their necks. And what they need to do
is optimize for how much impact can I create within say this six months cycle.
Something that is good for the company is not always good for the project and vice versa. So you
have friction there. You have something. It's not that everything was bad or anything, but it
introduces friction and the incentives are not very much aligned. You can have multiple companies
that fail to synchronize on efforts that are actually quite common. We had a use case in
Macurall that was that the narrow feature and the sparse feature, one of them by Google, one of them
by Facebook, were kind of trying to do a similar thing. Like it was in a different scope, but a bunch
of the concepts were very similar. And it was almost refactored together, but not really. And now
it's kind of in a half states where nothing is really done correctly because each company had
different incentives and didn't want to go through the work of making it a maintainable upstream.
Because not many people get promoted by maintaining software. In general, it's more about
features and speed and stuff like this. Your project can have a different deadline in general.
We have a release cycle. It doesn't always line up with needs of any company, so that also
introduces friction and possibly burn out for the maintainers. That's not great and you finish with
have done features. So this is the kind of the end of the 2010s. We're moving into the 2020s.
This is the end of the era. The tool itself, Macurall has withered the get storm. We're still
around. We're still doing a bunch of stuff and we're still innovating and everything.
But the project was dying. Macurall has a sovereign entity as something that can govern itself
was dying. Then for many different reasons, some of them, the friction that I was talking about,
some of them being external factors, Facebook, forks, internally, Macurall and started something that
is now mononoki and sapping. And Google has slowly started to pivot to JJ and you can see
kind of a downtrend in their involvement. JJ, Jiu-Jitsu, was created at first as an experiment
by Martin who has worked on Macurall for seven years. He was a Macurall developer for a good
while and this first contributor to Jiu-Jitsu is still a Macurall contributor. So this is very much
interesting. This, which means that we are moving to the new wave of the down.
As you might have noticed, there is some movement in the Russian control field.
One of the things we have to keep in mind here is that the Russian control is not the source
problem. Like, get to arrive 20 years ago, but it was not the final answer to everything. There
is a lot of use cases that are not well-covered. Could be, for example, a game developer that
are not completely satisfied with what happens or the AI people are trying to fashion models and
like that. There is also too much friction from non-technical people. Like, the program
solved by soft control is useful for non-developers and we still don't really have a good progression
of seeing like that. Also, the world we live in keeps changing. In the sense of
20 years ago, when we started, we didn't have the AI, like AI is something that happened two years ago.
AI is going to change the way people develop and therefore are going to change the way people use
or control. A bunch of things also change like cloud computing, weathering things really 20 years ago
and it changed the way people are going to deploy. There is a bunch of things that means that
Russian control is a moving target and Russian control also change the field of computing
and therefore move the target itself. Good example of ways not solve is like, people still use
material but people still use SVN. Probably more people still use SVN that people still use
material and they don't use SVN because they are stuck on it. They use SVN because SVN
solved some of their problem better than get and material or any other tool to do.
And scaling is also inevitable which is part of why it's a constant ill-willed problem.
The amount of short-scored we store everywhere just grow. The size of the amount of
code we've write just grow and so you have more and more problem that you need to solve and
something fun is that the thing we usually use to solve getting problem does aren't really scale.
Like if you do content-adracing these ashes, therefore you have look-up stable and like the
bigger of the air of the legs they are performing. A good example is Inotifying. Like using Inotifying
two speed-up stages is a great idea except that you have a limit of the amount of file you can follow
with Inotifying. And the more you need Inotifying the more file you are and at some point it doesn't
really work like if you have mini-walking computers and work if you have a lot of values and work
and just kind of think that there is a bunch of problems that we can't solve now but it's that are
harder to solve later. But we mentioned a new wave of things so maybe there is a new up
of solving more problem. Let's go back to the timeline we have before. We notice that only
a few projects survive the 2000s but there was a very long time between like 10-15 years
between and actually 20 years now but between the time where all the things happen in 2005
and the time where all the things happen now except for pure rule that happen cannot be
middle of that, pure rule spun from darks and pure rule bring more things to the table.
Especially they do more work on the patch theory and they introduce a nice definition for
what is the conflict that is actually a CRDT so that very interesting because you can keep
AVDVSS that is a CRDT. Sampling is a frock from SL from Facebook and they walk more on like
the lazyness, the scaling and they they you've been could use some issue from SDN like
directory level history tracking and things like that. Due to also play with conflict tracking
and they also we you like you a lot of work on the stack-diff workflow and things like that and
it's not just the new tool like get as been more active recently and solving more problem
we're introducing ID doing the NLs where and a lot of things are happening. The tooling
feel like people from game it bit beckler and other stuff a lot of things are happening so it's
kind of exciting time where people are going to share from each other again and new things a new
creation are going to happen which is pretty nice and material play the part in that in the sense
of sapling it's like a direct thought of material it's we use a lot of the get-based lot of the
concepts and some of the UX. Due to it's actually build by macro developers like the creator
was a macro developers the main developers is also a from a macro developers that we use a lot
of the user experience concept from Microsoft and try to pod them to get and get it and I mean
under get that structure and and get itself as a lot of things it gain now that are
inspired more or less directly by macro you are like the coming graph that speed up history
a traversal operation that's something like as for a long time the FS literature we mentioned like
I notify things for us is something learning material in 2013 the walk around the
year experience like absorb and things like that things that directly comes from the innovation
that happened in material in the 2010s but that thing that happened in material in the 2010s so
now that the big company left and and the thing they did are slowly trickling to other
company is material like still relevant until life and actually yes so we still have
multiple full-time job funded like there is a two of us and there is a few other people that
kind of other full-time job depend on material we have a modern thought which is a 24
of get-lamp so we can do like more just stuff but modern workflow when seeing like that and even if we
still have about one percent of users one percent of users is still a lot of people and so
it's not like nobody use it they're far less like you're not likely to meet randomly
material users compared to meeting get users but there is still a lot of people that can
company and sing like that and we still do a lot of innovation both in performance and in
future and things like that for example last year I gave a liking talk on how material
is able to show the diff between between two version of a sunset through rebays like in your
ring the change in what is based on rebays you can check my liking talk to learn more about it
and we also do more things in scaling and think like that like we are still innovative and one way
we innovate is because we have a good cut-based that is fast we have good concept like CRDT
that are very powerful and also we work with researcher in research lab to have like better
algorithm that are actually new and unique like with you academic paper about oh this
program investment control actually you could solve it better this way and that allowed to
move to to keep the pace with the smaller team in a smaller use case and we still have a lot
of uniqueness like the the fact that we do fully distributed history of writing is still unique to
Macreal a lot of that like some part of that got moved into due to due to and also stuff but
they didn't preserve the CRDT property that allowed to do a lot of things and so we still have
some specific stuff and we also have a more approach more focus on being generally useful
into that being tied to a large company needs and seeing like that a good example of that is that
we have an approach that feels natural to us but in practice it don't to be quite unusual
which is we try to solve the demo case first in the sense of some time when you have a problem
in a specific situation you could just walk around the problem but if you actually solve the
core of the problem it means you solve the core of the problem in more places and it means you are
more universally useful for more you are user in in more case one example of that is the
way Macreal scale we did kind of some scaling walk in the past year so we took a lot of like
it's a good example we have people that have repo with like tens of millions of sense it
millions of files and we still have a very fast status and we don't have a very fast status that
cheating or taking shortcuts for all their specific use case like this is the same status code
that weren't as for small people and for big repo and we get that things we can have very
efficient action of putting revision or crowding as a graph and we don't do anything special to
leverage the fact that it's centralized or leverage the fact that they have some specific
infrastructure or some specific shape like we just make exchanging data faster and it makes
their use case faster and every other use case faster and so instead of solving individual
problem or indie field people by adding more codes for for specific special case we can keep
code base and algorithm that are just efficient for everybody and solve more problem
for a more people because they do that with like stock Macreal they don't have anything special
type to their infrastructure like it's they basically they mostly just run Macreal and it just fast
and we give these numbers but we still have a lot of of bedrooms like there is a lot of
things we know are stupidly slow there is a bunch of bite and code that is slow
algorithms that are slow that has to be true that is slow so if with a not that good code base
and not that good solution we have this kind of of performance
we there is a lot of room to keep with this approach of being general
and there is a lot of challenge to solve regarding scale
but yeah let me finish up we're not there yet unfortunately we still have bad default
UX because it came from 2005 we still have many unfinished features that we're trying to get
over the line we are still not shipping rust by default meaning that we have plenty of stuff that
we are doing that is pushing the boundaries that people cannot use without going through
extra steps individually this is like the product versus toolkit stuff
do you really have the fastest status in the world if nobody runs it?
so let's conclude why why do we work on Macreal still?
we have happy users first of all which is nice we have funding still for an
open source project that's pretty good we have a good toolkit that is sometimes best in class
in different aspect we have a technological edge in certain areas and we have a conceptual edge
in some other areas it is still universally useful we are not working at a company making a
lot more money that we could then we're currently making and we're not working on other software
because we think this is universally useful and that can be used for by everybody we're always
moving quickly all of the stuff that we said we haven't really lost pace that much and we're
still experimenting and helping advancing the field so it's next keep up the good work
doing scaling the UX improvements actually ship it so that people can use it
like it's actually a problem and we we can graduate to fixing it last year with terrible
now it's better next year it will be great hopefully staying community focused meaning
improving contributor experience our CI the tooling we have a sprint coming in London
there's we're thinking about a new user experience so that we're not bound to our old one
as much first class get interaction we know that the world runs on get so we have plans to make
that work as well modernizing modernizing the UX in general that's what I just said having
it a new way of presenting Macro to the to the world so what's in it for you if any of you
still use Macro which we know you do because you raise your hand come talk to us please that would
me very nice we can only help you if we know who you are if the progress is too slow join us
come help out if you're interested get in touch we are a consulting company and we will like
having your board otherwise you can wait 5 to 10 years and the stuff that we do will trickle
down to your favorite tool you can get in touch at those links we have a sprint in London at
those dates we have a BFF to talk to other like if you want to keep this conversation going
at 3 PM today and we have two presentations tomorrow one in the rest of room and one in the
software performance room thank you all for coming and yeah that was it