Hello and welcome to episode 80 of Linux Downtime, I'm Joe.
I'm Gary.
I'm Marmaleth.
And I'm Andy.
Good to talk to you all again.
And good to talk to you for the first time, Andy.
Hello.
Yeah.
So you emailed us and volunteered yourself as a guest on the show
and said that you do something to do with element or something.
So tell us about who you are.
Well, I've been working for Element for a couple of years
which is the company that does
that establish Matrix and does a lot of the work on Matrix.
I've been trying to get into working open source for my whole career
and this is the first time I've succeeded.
So I have some observations about the differences between different worlds.
Well, yeah, that's actually what I thought we could talk about mostly today.
So how long were you working in software development on proprietary stuff
before you got into open source then?
I guess about 20 years.
It's slightly under 20 years probably.
So working for different companies, I work for a company called Cognos
that makes business analytics stuff and that got bought by IBM.
Wow, that sounds really exciting.
Yeah, it's fascinating.
Then I work for IBM for quite a number of years.
And then I work for a company called OpenMarket
and software that sends spam SMSes.
No, SMSes to you.
Before I managed to find a way to get into open source
which I've been really trying to do.
Well, I've been trying to persuade the companies I work for
that the thing I was doing really should be open source
without a great deal of success.
Right.
Well, I can see why you wanted to get out of that
boring proprietary world.
So now that you do work on open source software,
how is the experience different?
Well, I still work for a company, right?
So there are things that are the same about that.
Like you still need to find a way to make money.
But I think something that's quite different element is
almost every conversation, including the conversations
about making money.
They have some kind of ethical dimension to them.
And how are we, in some sense,
is what we're going to do right?
That doesn't mean we always make wonderful,
ethically sound decisions.
But that's always in the conversation.
Whereas in the proprietary world,
it's just how can we make money?
And there's not really a conversation
about the ethical aspects of it.
Or if there is a discussion, it's a very short one.
Yeah, I mean, certainly within IBM, for example,
they're entirely structured around,
are you going to make money from this?
And the whole way the company operates its year is around,
am I going to get budget for this from the kind of decision-making
group?
I have to kind of sell it to them and then not me.
But someone high up has to sell this stuff to them
and then get the funding for it.
So it's very, very focused.
And it's been really interesting watching the Red Hat stuff
and thinking, oh, right.
Okay, that's that process kicking in.
And this is the result of it.
I mean, that can't just be IBM, though.
That must be most companies of that size operate like that.
I think IBM are just more conscious about it
and more open about it, at least internally.
Or just maybe even better at it.
So apart from the questions about ethics,
what else is different?
I would say another thing that I've noticed
and I really wanted, part of why I wanted to get into open sources,
because you're working in public.
And I think that one of the motives for getting involved
with open source generally is a kind of desire
to show off.
So you get to show off all day if you're working in public.
You know, everything I'm doing is on GitHub
and people can see what I'm doing.
But it's not just showing off.
It's also I think it's a really good accountability thing there.
You tend to do things a little bit better,
right slightly better code if you know people are watching.
So that's quite a nice satisfying thing about it.
Yeah, like you hear these stories about companies
not wanting to open source proprietary stuff
because the current is just horrible.
Absolutely.
I have definitely had those conversations multiple times.
Yeah.
I never really bought into that though,
because as a developer,
we all know that we're going to make mistakes every day
and we're going to get better over time.
And sometimes the only way to get there
is by somebody to review your code.
So I understand where they're coming from
because they're worried about their name brand recognition
and reputation and stuff.
But it's like just throw it out there,
get it fixed and get it done.
Absolutely.
And lots of open source code is terrible, right?
Right.
Open source definitely suffers from bad code too,
just to be clear.
Yeah, yeah.
But I think we, at various times people were worried
about like reputation damage from,
this is so awful.
We don't want anyone to see it.
Yeah, but like at the same time,
it's like if you're going to do open source,
just do open source, right?
Like there's the whole thing about like when
Mozilla originally open sourced the browser
and they wanted to make sure there's no bugs.
It's like just get it out there.
People are going to find other bugs
and fix them anyways.
It doesn't matter.
And then they were so ashamed that they just rewrote
the whole thing from scratch.
Right.
I don't know where there was any better.
Exactly.
And if the community thinks your code is so horrible,
they can contribute patches to fix it.
In theory, yeah.
I mean, if it's horrible enough, no one does, right?
Mm-hmm.
Yeah. How is Pigeon going, Gary?
To be clear, you're the one that brought it up this time.
Not me.
Not me.
We're actually doing a lot better.
Thank you very much.
But yeah, no.
Historically, we, what I like to describe is
Pigeon was developed by a lot of people learning how to program
and they did the best that they could at the time.
Mm-hmm.
So designs aren't always sound and stuff like that.
Not to say that I'm making perfectly sound design decisions now,
but they hope they're better.
Actually, that leads me on to something else
that is a different working open source company.
We have outside contributions,
which are like widely varying quality.
So that's a really interesting and cool part of it.
Although, I think something that's really difficult about it is that we
are trying to be really focused on getting where we need to go
so that Matrix isn't as terrible as everyone thinks it is.
And sometimes outside contributions are like
just not relevant to the direction we're trying to go.
And so trying to deal with that without being a horrible person
or a horrible company is a little bit,
it's sad sometimes that you're turning away stuff
where people have worked really hard, but it doesn't quite fit.
Yeah, we struggle with that a bit, especially when somebody
doesn't know the longer term plan.
So they give you a patch for something that you're going to rewrite
in like two months.
And it's just something you've got to kind of struggle with and deal with
and be like, you know, sure, this is cool,
but this isn't the direction we want to go kind of thing.
But if you're interested, here's what we're looking at.
If you want to update or work on that kind of thing,
you know, to try to keep them involved and not just be like,
no, sorry, we're not going to take it.
Sure, do you just reply with a bunch of expletives
like Toraz used to do?
There's also, there's a time investment required for any
of that interaction, but especially if you're going to help
someone refocus their effort, that's a significant amount of time
from you.
You sort of get into mentoring at that point.
Like if the code isn't totally up to scratch
or totally in the direction you want to go,
then you have to decide presumably whether you're going to
invest that time to mentor the person, to get it to where
you want it to be as a project.
Absolutely.
Definitely mentoring and that would be really satisfying
a call if that was the main thing.
But there's other stuff as well.
Like we had a contribution recently.
A couple of years ago we started changing our coding standards
to make sure that there's always testing,
really good testing for new bits of code that are written.
We had a contribution the other day for a bit of code
that is basically not tested and it's terrible.
And the person, the contributor didn't want to write test for it
because it was going to be really hard.
And so then the question is,
well, do we take that contribution even though it might break
everything because we don't know whether it works or do we
help them with the testing?
Where do we find the time to invest in mentoring through that
or just doing the work of writing the test
because they can't be bothered?
It's a really difficult decision.
Yeah, I think that's one of those things you always
have to kind of look at.
For example, I just opened a poll request for Pigeon last night
where I was like, I'm not writing unit tests for this
because the unit tests are going to be five times as much code
as this change.
And that's something we need to fix.
And just us doing unit tests, like you said,
you just started doing it as well or recently.
And that's something that's new for us too.
But like this unit test, we would have spent more time reviewing
the unit tests and reviewing the actual code.
And the code was very straightforward.
So it's like, we'll try to catch and review when it's easier
to write the unit test.
We'll come back and do it.
Hopefully.
I'm a massive test driven development advocate
and I have been through a lot of my career.
So I'm trying to bring this into our team.
It was already coming, but I'm trying to bring it.
But that means that for the stuff work we're doing,
we do put in all the extra effort for all of that testing.
But then asking that of someone who's doing this for fun
in this bear time, it becomes difficult.
I totally understand.
We're in a similar spot too, right?
So it's like, you know, we'll do our best review
and then maybe we'll come around the right unit test
if they're going to be really problematic or something.
But again, like you mentioned before,
the whole issue comes down to timelines and stuff like that
and does this contribution fit into that?
Is there a time to come back and do those unit tests
that kind of stuff?
You know, it's a balancing act.
I think a huge difference for me between working on open source
in my spare time, which is what I was doing
between the rest of my career and working in a company,
is that one of the things I loved about work on open source
was that I got to choose, this is going to take me ages
because I'm going to write really good tests for it.
And those decisions are, you know, more,
they have more commercial meaning now
and then you have to make compromises.
Okay, this episode is sponsored by Factor.
With the busy fall season already in swing,
you might be looking for wholesome, convenient meals
for jam-packed days.
Factor can help you fuel up fast with chef-prepared,
dietician-approved ready-to-eat meals delivered straight to your door.
You'll save time, eat well and stay on track
with your healthy lifestyle.
Too busy this fall to cook but want to make sure you're eating well?
With Factor, skip the extra trip to the grocery store
and the chopping, prepping and cleaning up too.
While still getting the flavour and nutritional quality you need.
Factor's fresh, never-frozen meals are ready in just two minutes
so all you have to do is heat them up and enjoy.
Level up with gourmet plus options prepared to perfection
by chefs and ready-to-eat in record time.
Treat yourself to upscale meals with premium ingredients
like broccolini, leeks, truffle butter and asparagus.
Gary tried Factor and said he loved the variety of delicious meals
found it super convenient and was happy to see
how recyclable the packaging is.
So support the show and go to FactorMeeals.com
slash LDT50 and use code LDT50 to get 50% off.
That's code LDT50 at FactorMeeals.com slash LDT50 to get 50% off.
Quick bit of admin then.
First of all, thank you everyone who supports us with PayPal and Patreon.
We really do appreciate that.
If you want to join those people you can go to linuxdowntime.com slash support
and remember that for various amounts of Patreon you can get
an advert free RSS feed of either just this show
or all the shows in the late night linux family.
And if you want to get in contact with us you can email
showatlinuxdowntime.com.
You mentioned the being public about your code and your work generally.
Was it not a nice aspect of just kind of working the 9 to 5 and 9 to 6 whatever
and just being able to just clock off and just go and be with your family and friends
and just not have it constantly be there.
With an open source project there's almost an expectation that you will be
not necessarily on call all the time but you'll be around,
because this is on the internet.
It's a 24-7 operation.
There's definitely the risk of getting into an internet argument.
And then that would definitely stress me out to have a lung at Turk.
Other than that, I keep reasonable boundaries around my work even though
it's an open source project.
So I don't feel the pressure of that too much.
Having said that my boss got into an internet argument just the other day
and it was very stressful for him.
So you can't definitely can't happen.
Have you had to be very intentional and mindful about setting those boundaries
for yourself or were they relatively easy to put in place and maintain?
I am very intentional about it and I think I need to be in order to.
I also go to the office three days a week which is pretty rare for an open source
developer probably so that helps me a lot.
But yeah, I have basically a time of day where I stop and don't go back.
So that helps me.
I was going to ask you about working from home then.
Have you always been able to have a hybrid approach or have you mostly
been in offices throughout your career?
I got a weird relationship with working from home.
I really don't like it.
So I'm answering this question from the other way around maybe from a lot of people.
Yeah.
So most of my career I've worked in an office and part of why I don't like working
from home is because one of the really depressing workplaces that I worked in.
One of the things about it that was so depressing was that people started to stay
away because there was the opportunity to work from home.
So people just stopped bothering to turn up and for me that was kind of symbolic
of just how awful it was to be there.
But at the good times in my career when I've been in an office with like a whole team
and having stand-up meetings where we're actually standing up and we can collaborate
and sit next to each other and figure stuff out or work right stuff on a white board
and understand what the right thing to do is.
I really love doing that.
So it's really nice for me that element has an office that I can get to and go to.
But it's also a compromise for me that a lot of the people who work for element are not
in that office or around the world including most of the people that I write code with.
So I have to interact with them through chat and through GitHub and stuff
and I don't find that as good as face-to-face interactions.
So I do miss that a little bit.
But I suppose I'm not a developer.
So you know, what I do here, well if we were all sitting in a room together
this would be a better episode.
There's no doubt in my mind.
But we are geographically distributed.
I presume that you are in the south of England.
Yeah.
Yeah. So we probably could have got together but then it would have been weird
to have two people remote or whatever.
But surely the advantages of being able to work with people all around the world
outweighs the disadvantages of not being together.
Yeah. I mean, I think it does, right?
So even just the fact that you can employ people that you don't have to worry about where they are.
So you get to choose from more people or whatever.
Or there's more opportunity for people to think you're cool and want to work for you.
So yeah, that's cool.
It doesn't change the fact that like you said it like this would be a better episode
if we were sitting in the same room.
I think we've write better code and I'd have a lot more fun if I was writing it in the same room as people.
So we have to try and recreate that a bit.
Like find ways of making it feel a bit more like you're in the same room.
But it's hard.
Well, I've heard of people having like enforced fun time on video calls or whatever way.
It's like no work talk or whatever.
Like we're going to have half an hour of talk about whatever on a Friday afternoon or something like that.
Do you do stuff like that?
I've done it in the past and I've had it work okay.
And actually we're doing it in our team at the moment that we have every week.
We have a bit of time where we...
I can enforce rule that there's no work talk but there's no agenda and we sort of try and get to know each other a bit.
And probably some of my colleagues think that that's the waste of time or not the best use of their time.
But for me it's like incredibly valuable.
I like need human interaction.
It's good for me.
Yeah, I think there's a personality type that just wants to just get the work done
and doesn't necessarily appreciate the sort of social aspects of it.
And as far as what you were trying to say is like that is sort of essential really
because if you just only worry about the code and are just totally concentrating on that,
then you kind of miss out on the ability to interact with each other.
And I mean it's again like relating it to the shows.
Before we started recording we had a bit of banter and I told you about my hectic couple of days that I've had.
Just a sort of light in the mode really and make it a bit easier to talk to each other.
And I suppose if you're not interacting with each other, apart from pure business,
you don't kind of build up the chemistry I suppose.
Absolutely.
I think there's two aspects to it.
Like one is just as a human being, you spend a lot of time at work.
It's good for humans to spend time with humans.
But I also think in terms of the work, one of the things that is potentially a real problem in open source work
is that there's this kind of pretend that it's all about the code and the code is so expressive
that you can almost communicate just through the code.
And you don't actually end up then with like a shared vision of what style the code should be in
or where the product is going or whatever.
So yeah, I really think that human interaction is a huge part of being a developer,
which maybe sounds surprising.
I don't think so.
I've worked at quite a few places where we'd have like Friday afternoon,
like goof off time or whatever, and like a lot of people would like just go home.
And it's like it's one thing if you have something to do kind of thing or whatever,
but like you lose that community bonding kind of thing,
like you're describing when you don't do that kind of stuff.
And I think that the community bonding and getting to know each other's stuff
helps as you're describing to have a better vision and stuff like that,
because you know, you can better understand where somebody's coming from,
whether they're coming up with ideas and how things should go forward and stuff like that.
And when you don't do any of that, it's just like everybody's just,
you know, kind of defending their own points and thinks they're right
and they're not willing to concede at all or, you know,
view things from other people's point of view and stuff like that.
Definitely.
During COVID, when everyone was boasting about how like we're fully remote now
and no one has to come to the office, I did wonder whether in a few years
there's going to be this sort of radical new idea of a startup that's like,
we do this amazing thing of like going to the same place and working together.
But you argue that the hybrid approach is probably best then.
As an individual, it works for me that I get,
I leave the house and that makes me feel better about myself and I walk a bit
which otherwise I would move at all.
But yeah, I think as a company working on open source,
it would be odd not to be able to hire people who ever wants to work on it right.
So I can't really see any other choice.
It makes a lot of sense to me too.
I think I'm really lucky that I've got an office to go to.
I've actually got the same opinion, but for different reasons.
I do prefer having an office I can go to,
even if that's just a co-working space.
It doesn't necessarily have to be with the same people I'm working with,
like the same people I'm developing code with.
Because in my mind, mixing work and play at home is a bad idea
that results in me procrastinating and not being productive or getting anything done.
But the mental switch of going into a professional environment does a lot
for helping me focus on things personally.
But what if you just type Paypal like I do?
Then working for my was definitely an option.
Exactly.
That's why hybrid is probably best.
There's another aspect too about working from home too
that a lot of people overlook.
That's that you lose track of time.
If you're at the office, you're like, oh, it's almost quit in time.
It's almost quit in time.
But if you're at home, you don't think about the time so much.
So all of a sudden, you're like, oh, I just worked an hour later than I normally
would have if I was in the office kind of thing.
I think it's a guilt thing as well, which is that I tend to feel like,
if I go to the toilet when I'm working from home, I'm like, oh no, I'm wasting time.
I'm not working.
If I go into the office, it doesn't matter what I'm doing.
If I sit and chat with someone all day, that's like, yeah, I did a day of work today.
Exactly.
It's just that completely different mindset when you're actually in the office.
It's been about two years since you switched to working on open source.
Do you think that you are ultimately happier as a result of that?
I'm really happy that I get to work on open source.
I've always wanted to.
It does deliver.
I feel like I'm doing something useful instead of just something that is going to be thrown away
or even just could get lost if the company went under or something like that.
I'm definitely really happy and satisfied that I'm doing that.
I'm also adapting to the world that I find myself in.
As you might have been able to tell, I'm into interacting with other people.
Open source can attract some people who are not really interacting with other people.
My role in our team is like a tech lead.
I see that as someone who gets people to interact and mentors, people and all that stuff.
Programmers are often people who don't want to interact much with other people anyway.
It's not like it's a new thing to me, but I think that the open source world has maybe got even more of that kind of sense.
That's definitely pretty challenging.
If I was completely stuck at home, there might not be a decent trade-off for me,
but with that aspect of it as well.
The fact that I get to do something that in some sense lasts forever or is useful to the world
is a huge reward for me and also having real fun working with my colleagues.
Well, it's been great talking to you, Andy. Thanks for joining us.
Any websites or accounts you want to plug for people to find you or find out what you've been up to.
I'm on Mastodon. I'm at Andy Bailem at Mastodon.Social.
If you don't know how to spell Bailem, maybe there could be a link in the show notes or something.
Yeah, yeah, I'll put a link in that way.
I'll say live stream weekly at 2pm UK time, me coding some rust matrix-y stuff
so you can find out on AndyBailem.uk.to.
Those are probably the best ways to find me.
Find me on Mastodon and all the other things that I do you can find from there.
All right, well, if you send me some links, I'll stick them in the show notes.
We'll do.
Right, well, we better get out of here then. We'll be back in a couple of weeks,
but until then, I've been Joe.
I've been Gary.
I've been Amal.
And I've been Andy.
See you later.
Thanks for watching.
Have a nice day.
See you later.
Bye.