Great pleasure to be here. Can you all hear me at the back? Can you? Yeah, thank you.
Yeah, wow. What was them? Thank you to the organizers and for the staff for inviting
me here. It's a great pleasure to be here. And yeah, if you asked me a year ago, would
I be here? I'd be like, no, because I hadn't actually heard of FOS. Apologies at that point.
If I'd be told that I'll be talking about Rose Garden, which is something I've not
worked on myself for a very long time, not contributed to, I'd be doubly surprised. However,
I think it's important to look back sometimes. And I've called this talk a slumbering, yeah,
Rose Garden a slumbering giant. And I thought, I didn't really think when I was putting this
submission in as well. So I thought a slumbering giant, that made sense to me at the time. Who
knows what slumbering actually means? Okay, I should explain that, because I was thinking
about maybe changing. So slumbering actually means not quite sleeping, but also not quite
awake either. And it's kind of in relation to the fact that Rose Garden has been around
for a very long time. Maybe just as a show of hands as well. How many people have used,
okay, let's start off simply. How many people have used computers to make music? Okay, so
we've got about 20 maybe. That's pretty good. Keep your hand up if you use Linux to make
music. Okay, that's actually more, I think. That's weird. Okay. About the same maybe.
So how many people have heard of Rose Garden? Okay, it's not bad. Not impressed. Okay, good,
good stuff. So Rose Garden started actually longer than 20 years ago. Let me show you.
So this is the kind of current Rose Garden. This is how it looks now. And if you're familiar
with Linux, sorry, with music software, by the way, I've got a pointer. Can you see it?
Yeah, it's cool. I usually just use it to torture cats, but this is the first time I've
actually used it on a presentation. So yeah, if you're unfamiliar with digital audio work
stations, I'll give you a little tour. So we have down here some instruments, and you
can map to those tracks, and they're either MIDI tracks, which is musical instrument,
digital interface tracks, or you can have audio tracks too. And this is how Rose Garden
essentially works. It allows you to compose. It allows you to record into it from a digital
instrument, or from an analog instrument, and then you can edit it on the screen. Just
to go back to the beginning, the talk today as well is going to be about the history of
Rose Garden. It's going to be about how I believe that good engineering practice could
talk, is interesting talk, the last talk from Brian about using the latest tools and technology
to understand how open source software can be better. So as part of this talk, I'm going
to look at how Rose Garden was put together in the first place, and why I believe it's
still around because of the way it was put together, and because of some of the design
decisions that we made during the creation of it. Oh yeah, if I didn't mention, there's
a QR code here. If you want to scan that, you can go to a page where there'll be some
links. I'll also share this at the end. Rose Garden was really a kind of a labour of love.
It was almost an accidental success, but it was kind of done deliberately in a way. That
doesn't really make any sense, but Rose Garden came about originally from a university project.
So it's actually a lot older than 20 years. It's almost 30 years old. In fact, it's over
20 years old. And then it became something of its own thing. So just diving back into
how it looks these days again. So we've got a piano roll editor on one side and a notation
editor on the other. And this was one of the great powers of the original Rose Garden,
as well. It had both notation editing and MIDI editing too. And this is the current Rose
Garden homepage where you can download it and you can see how often it's raced. So up here,
you can see there was a release in December. The current maintainer, Ted, works very hard
on these. And when I'm talking about the engineering processes that go behind it, you'll see towards
the end of the presentation that there's a lot of manual work involved still. So some
of the best practices that we get through our day jobs can actually help us understand
how we can make software like this more maintainable and easier to release. It's not untypical
as well for large and old software products like this to have quite slow release cycles.
And typically, once it's released, it goes into the usual repositories where it can be
created and packaged for download on various different distributions, Linux distributions.
It's been translated into around 20 different languages, including Chinese, Japanese, Italian,
Spanish, Finnish, German loads. And over the last 20 years, it's been downloaded all over
the world, as you can imagine. And this is some stats. So interestingly enough, we're
still on SourceForge. That's down to the developers having a certain way of looking at things.
So SourceForge is the preferred way of looking at things for a lot of the developers because
they've been involved in it for a long time. And perhaps they're a little bit behind the
times. So they like to dig their heels in sometimes when it comes to what is acceptable
in terms of the technology that is being used. So the good part about it is that we have
all the stats from the beginning of time, basically, all the way to today on how many
times it gets downloaded. And this is source packages only, essentially, as well. So it's
not bad. I mean, its height, it was 5,000 source package downloads per month. And even
with the last release, it was still around 2,000. So if you add that into the mix with
all the pre-packaged stuff that happens for the distributions, then it's pretty tidy
amount. So who am I and why am I here? So I worked on Rose Garden between 95 and 2004-2005.
I'm now independent consultant. And I kind of specialized mainly in software delivery
and customer focus. And that means that over the years, as a professional software engineer,
I've learned various techniques which has helped me understand, OK, well, maybe we could
do things slightly better. And I'd like to talk and write about this right now. And this
is how this talk, I suppose, kind of came about because I was thinking, what is the
project that gave me the most pleasure over these years? And when it comes down to it,
undoubtedly Rose Garden was the thing. And some of the takeaways I believe that we can
get from this is to understand how open-source software becomes important and how it stays
important as a social enterprise. So this is really a story about motivation and why
we do things the way we do. And how open-source software becomes something that can take
over our lives as well. So just to expand on that a little bit, I've kind of broke
it down to three areas, which I believe are the core components of how open-source kind
of gets good, how open-source projects become a thing in the first place and how they then
sustain themselves. And it's mainly, spoilers, mainly around the social exercise. We do it
because we kind of want to. We're driven to do it. Of course, we do it as well because
we can't do it by ourselves. So that's number one for me, is the effort that it takes to
build something. So when you look at something like Rose Garden or any other huge open-source
project, you end up with hundreds of thousands of lines of code and lots of contributors
from all over the world doing various different things, either writing code themselves, becoming
different, doing translations, helping out the website with documentation. And this is
a snapshot from the Rose Garden website of the contributors that have been involved over
the years. Secondly, you can't do it without effort, you can't do it without support. This
is a picture of the time that's elapsed between when I stopped working on Rose Garden and
pretty much today. This is my son, Sam. He was one when I took a photo of him and put
him on this poster to kind of be used at one of the sound expos that we did in 2004. And
this is him last year as he graduated from high school. And this was probably the reason
why I stopped contributing to Rose Garden this time because I went off to have a family.
And of course the family is important for support, so they have to keep you going, maintaining
your energy to be able to do stuff. In addition to that, we also see how the working world
comes into play, one second. So after university, I went into, sorry. It's out of the working
world shape, our experience and our perception of what goes on in the open source land. So
after university, basically after Rose Garden first came out, going into engineering and
becoming a person who would actually grow as an engineer and then be able to feed back
into that project. So this is taking, this is the start, basically, of Rose Garden. So
I went to Bartholomew University between 1990 and 1994. Rose Garden started as a university
project by a couple of friends of mine, Chris Canham and Melissa Wilson. And they did it
for a final year of projects at Barth, and it was written for John Fitch, who was one
of the computer science professors there. His idea to come up with a UNIX sequencer and
notation editor. I think it was the combined thing that he came up with together. So Rose
Garden itself was born of a university project in around 1992. And the name is a bit strange.
So Rose Garden, where does that come from? It's actually, thanks to these guys, these
were a band called Bow House, who come out of Northampton in the UK from 1978. And Chris
Canham, one of the lead developers, the originators of Rose Garden, he was a big fan of Bow House
and he had one of the songs called Rose Garden, Funeral of Sores, which is actually a song
by John Kale. And he, being a bit of a wag, thought, it's probably going to be crap, this
notation editor. So we'll call it Rose Garden after Funeral of Scores, haha, Scores Notation,
get it? So yeah, that was the origination of the name. So 1992, it was written on UNIX,
it was written on SGI originally, under Erics, with the Athena widget set. It was a modified
Athena widget set, written in C. And it looked pretty good. I mean, I think Chris did a pretty
good job, actually, despite the fact he thought it would be terrible. This is actually Rose
Garden 1.0, the source code. However, I believe this screenshot comes from Rose Garden 2.1,
which is the first Linux port of that source code. And as you can see, it's got a piano
roll editor, an event editor. It's also got the notation, oops, and it also works together
on the same screen like that. So it was pretty advanced. And it worked via the Erics device,
so it would actually send out to a MIDI device from the SGI, the Silicon Graphics workstation.
That was it, number one. That was done for a final year project. So what happened next?
Well, what happened along the side of that was that we ended up spending a lot of time
mucking around. So in 1992, 1993, I was still at university. Chris and Melissa were peers
of mine, friends of mine too, and we used to hang around in the Spark Labs as they were
called at Barthie University, and we played too much X-Tank. Anyone know X-Tank? Yes,
very good. Too much fun, and too many late nights. And that was the thing about coding
at the time as well. It was a social enterprise. It's exactly the same these days as well.
I look at my son. I say to him, okay, why have you not learned? Okay, so now he's going
to university. He's starting to learn computer science at university. And when I was growing
up, I had a computer. I probably liked some of you here. I started coding because I was
interested in it. He was absolutely zero-interesting coding until he got to university. It's all
been gaming. I've been like, well, why don't you build a website? I was like, no interest,
but yet he goes on to study computer science. Annoyingly, he's really good at it, and he's
picked it up in no time at all. So now I'm getting WhatsApp saying, Dad, what about this
node problem? How do I fix that? Okay, fine. But to be honest, looking back, it's exactly
the same now as it was then, because we just mucked around too. We spent a lot of time
in the Spark Labs playing X-Tank. We spent a lot of time learning command line or learning
about Unix processes, how they work. We learned stuff off each other. So at university, I
learned Unix command lines solely from mucking around. I learned C and X11 from doing some
university courses, some of my minors. But the majority of it was from, yeah, just hanging
out with people, exchanging information. So that was Rose Garden 1. And then we left university.
We went off into the working world as a peer group as well. So I ended up in London, eventually,
as did Chris and Melissa. They were working for the same company, actually. And we ended
up hanging out. And somehow, I don't know quite how this happened, but we got to a point
where Linux was a thing. You know, I think I've got a picture next. Where is it? Okay.
So I've been working for a little bit. I've just skipped ahead. I'll skip back. I've been
working for a little bit. I managed to save a bit of money eventually, and I bought my
first PC and it was one of these Gateway 2000s. Came in a cow box. I can't forget it. And
it was so exciting because I just never had my own PC before. And the first thing I did
with it was buy Slackware 3.0 and put that on it. And that came out of, yeah, workings.
I'll go back to this picture. The working world. And that was really where things started
to kind of fall into place. Because when you're working in a proper company, you have responsibilities.
And that was the one thing that work really taught me. You're not just mucking around
in the Spark Lab anymore. You're not kind of just stay up late to do your coding and
have a lot of fun and then sleep late. You've got to, well, you end up doing that anyway
when you're a young engineer sometimes. But if you're working for a company like this,
like I was, a telecoms company, and we had responsibilities, so we created network management
software and also software for multiplexers. And my first boss, she was great. She sent
me out on a customer visit straight away. She said, okay, get in the car, go up to Sheffield
in Yorkshire in the UK, and go and be on site with Yorkshire Telecom whilst they're upgrading
their multiplexers and they're upgrading the software with our new network management
software. And for something like that, as a young, just out of university graduate engineer,
it was incredible because it finally gave you that connection between all the stuff that
you do, all the hours that you spend on a piece of code and the customer themselves.
Because if one of these cabinets fell out of the network or the upgrade didn't work,
then some would have to be sent out in a van. So the street cabinet to reboot it and then
you have to watch it in the control room to make sure it came back up again. And that
was, yeah, the real kind of visceral connection. So this is the first you might call it a learning
that I had. I didn't even realize it at the time, of course, you don't do. It was the
fact that you need to serve somebody with everything you do. Well, I felt that anyway.
Because sometimes you might just want to write some code for the hell of it, but unless someone
is using it, where's the point? I felt that really, really keenly. So yeah, cow box. Actually,
just to get back to the last one as well. So the cow box arrived. I got a P75, I think
it was 95. So Pentium P75. It wasn't particularly flash. It wasn't top of the range, but I
installed Slackware 3 on it. And then there was a tar ball of the Rose Garden source code
knocking around. And I think Chris and myself knocked it together. It might have been Melissa
as well, knocked it together into the first kind of release on Linux of Rose Garden. And
then just after that, one second. So it was kind of the heyday of music software, really.
Even got very exciting very quickly. So I bought my first PC. I was working. I was working
too hard, but having fun. But after a while, hard work became too much like hard work.
I was on pager duty and back in those days, it was actually a pager as well. And I remember
the first night I was on pager duty. I was lying there in my bed and I put the pager
right next to my head and I was just staring at it for the whole night. I couldn't go to
sleep. I was just so scared in case it went off. What would I do? I had my own hardware
at home. I had my PC. But it was, I'll come to this, it was on a 14.4 modem which I had
to ask someone to buy for me at work. They wouldn't even, otherwise I'd have to drive
into the office. I'd have to have a car. So it was basically, you were trying to offer
support to a global product from a very basic setup whilst being on pager duty. And the
pager duty lasted for a whole week as well. So you'd have a week on and then maybe two
weeks off. And that was really stressful. So between that and working and everything
else and probably parting a little bit too much, I just felt burnt out after a year and
a half of this. So I kind of moved jobs a couple of times. I bumped up my pay a little
bit and I got to a point a couple of years later where I could actually take some time
off. So I thought, oh, God, let's relax. The first thing I did was buy some music software
because it was the thing I wanted to do. So I've been building software and I've been
getting into being an engineer. But what I really wanted to do was make some music and
be a rock star. So seriously. So I bought a load, well, I say bought. I probably ripped.
I definitely ripped a load of stuff and put it onto my Windows PC like Logic Audio, Cubase,
Rebirth and Reason, all these great tools that were available at the time. Digital audio
workstations, which meant they would record audio. You could put plugins into them. They
would make great sounds and also things like Rebirth, which was like a TB808 simulator,
emulator, whatever. Lots of fun. Lots of squelchy fun. So I spent a couple of years understanding
these tools and having fun with them and recording. And what I didn't realize I was doing was
I was learning the domain. And if you kind of look back from where we are now and you've
kind of studied OO, object-oriented design, and you've maybe read Eric Evans' book or
listened to Vaughan Vernon speak about DDD, domain driven design, you understand that
that's what you're doing is you're learning the language, the ubiquitous language of music
software and then you're learning to talk and feel the way that musicians do when they
use this software. So around the same time, so around the same time, we had Rose Garden
2.1 already, but we hadn't moved on since 1992. This was about 1998 at this point. We
did kick around a few ideas. So mainly Chris and myself and also Guillaume, a French developer
who came on board, I think off the back of the 2.1 work. Again, it was a bit hazy. We
started kicking around some ideas. We want to rewrite this thing. How are we going to
do it? So I got this domain knowledge. Chris was an amazing software engineer and still
is to this day and still works in audio software. And me piggybacking on his genius and also
Guillaume's genius was a way to understand how we could build a whole new version of
Rose Garden because it was an itch we wanted to scratch. And we discussed a few things
and technology was quite fluid at the time. So we were like, could we do it in Java? Not
really. There was no sound system or there was a very basic API. To be fair, the Linux
sound system was not particularly advanced at that time. I was just about coming out
but it was mainly OSS before that. So Rose Garden 2.1 just used open sound system, which
was just a device, essentially. So you could, there was no internal routing of media events
or audio. It was all straight out onto the device. Java had the same problem. It was
kind of slow in catching up. It wasn't slow. It was just the fact that it hadn't been written
yet. A lot of these interfaces, there was, I think, a media API for Java, but Java was
never my forte. Didn't like it. Didn't like the stack traces. We also discussed IPC quite
a lot with interfaces communication. We discussed Cobra. Anyone remember Cobra? Yeah. Anyone
forgot Cobra? Yeah. Terrible. Well, the time was very exciting. There was that alien book.
You read it and you thought, what the hell is this? It was really complicated. So it
was too heavyweight. But I think actually Rose Garden 3, the missing number between
1, 2, and where we are now with Rose Garden 4 was kind of IPC, a Cobra-based thing. We
might have even written in Java or something. It was crazy. Anyway, that didn't last very
long. It was back of a fag packet type stuff, as they say in the UK. But we had a few other
ideas. And we thought, well, it wants to be, we want to build it on Linux. It has to be
on Linux. We're both quite pretty proficient in C++. Let's do C++ maybe. Let's build a
nice data model. And also, we saw that Elsa was emergent. Jack, which is the Jack Audio
Connection Kit, is still, I don't think it was invented until a couple years later, until
maybe 2000 or so. But that was also a flexible audio routing system, which is very cool.
And we eventually implemented. But we knew another thing, that the UI was going to be
vital. Having worked on X11 and a thing of a very basic X11 widget set, there were two
very exciting Linux alternatives coming up, JTK and all the various wizards, all the various
parts of it. And KDE based on QT. And the debate probably didn't take that long, but it felt
like it went on forever. But eventually, we decided, I think, as a kind of a three of
us, on taking the most pragmatic attitude, and that was, we're going to go with KDE.
And initially, we decided to go with KDE because it seemed to be slightly more mature. And
I think we all like QT as well. We didn't know QT particularly well at that point. The toolkit
that KDE is built on. So we come to the KDE years. So this was the real start of the
real build of Rose Garden 4, the thing I showed you at the top. So we finally got here. From
what I say here, KDE 3 was released in April 3, 2002. And I think what we'd done between
then is we'd started probably in 2000, and we'd started writing some stuff. And eventually,
we got to a point where we had to kind of go with the major upgrades. And KDE 3 felt,
for the first time, I think, when we were finally kind of getting there. It felt like
it was good. We were using a little bit of, have you ever seen that picture? Yeah, I'll
just stick on here. So we were using a little bit of de-cop, I think it was, which was the
communication interface for Rose Garden. We were running two separate processes, the Rose
Garden sequencer and the Rose Garden itself, Rose Garden GUI, basically. And they communicated
via, well, we were going to use the KDE mechanism. We didn't in the end. I think eventually,
we ended up on a memory map file, which was suitably good for both processes to access
at that time. So yeah, as you've seen, we ended up with a quite a flexible architecture.
So this kind of maps the core. I'm not going to go into the core of the core of Rose Garden,
but I can point out a few things. So there was the two processes, which underlaid it
behind. The GUI communicated with the shared memory map file. The sequencer did actually
all the running of the stuff, the in and the out and the whatever. It was all controlled
via the transport down here. And it had quite a flexible mapping, so that we had the, any
instrument here could be mapped to any of these instruments there. And they could be
a MIDI device or an audio device. And we kind of created an abstraction layer there, which
would allow us to map those as well onto either MIDI devices, which users could create called
device files, which allowed our users to actually get involved with creating specific configurations
for their own setups. So if you had a particular type of keyboard or a MIDI device somewhere
else, then you'd be able to create a device for it and be able to map those sounds to
your Rose Garden setup. Similarly, the segments themselves. So these blobs are all segments
and you could slice those up and they don't have parameters associated with them too.
So there was design obviously going on underneath the covers. And that was from quite an early,
quite an early time as well. I believe that we didn't actively sit down and plan it all,
but we spent a lot of time refactoring. And that was one of the biggest pain points I
think we felt whilst we were working in the early 2000s, was there was all these great
tools available. Coming out of working in industry where you had all the compilers essentially
before then, the end of the 90s or mid to end of the 90s, it was typically you'd have
to buy a compiler. So you had to buy a license for something. You'd have to buy your library.
So the standard template library for C++ wasn't, it was still kind of getting there. You'd
have to buy boost. I think it was or whatever it was called. There were the various things
you had to pay for. GCC and G++ were still getting there as well. G++3 I think came out
around the same time. So the tool set was shifting. There was also the shifting media
layers as well in Linux. So we were talking to people on various main lists basically
about like when is the new version of ALSA coming out? Were the stuff that we can use
to actually get some real-time stuff working on ALSA? So all of these layers underneath
we were waiting for. Plus the tooling was a little bit kind of getting there too. Plus
all of the UI toolkits were also growing. So we were kind of growing alongside all of
this stuff and it made it quite difficult. We didn't have any CI. We had like a couple
of machines. We had some basic source control in Sourceforge which was probably CVS at the
time, not even Subversion at that point, which worked. But typically even with three of us
working on it, there would be breaking changes the whole time. We didn't have any tests per
say. We'd just be downloading the latest bit of source code and building it at some
break. So when you're refactoring our core area, even with three people and you've got
all of these dependencies moving, it makes it very difficult to get anywhere. So we struggled
to be fair. I was working for a couple of years. Well, it probably felt like a couple
of years. It probably wasn't. It was probably more like six months. I did take some time
off and I worked on it full-time in a little basement with multiple computers, with this
CC running on various computers to try and speed up my builds and stuff. And it was a
real struggle, mainly because we were refactoring and breaking stuff, but also because we had
a kind of an unstable base. Still, through much effort and through much time and through
much dedication from not just a core team, a growing team the whole time, but also some
really passionate users who came along quite early and have stuck with us the whole way
through. So we've still got people who have been using it for 20 years who just love it
because they can't think of any other way of working with it, basically. It's brilliant.
They'll compile it and they'll run it on their own kernels, or they'll download it as part
of a package, or they'll have a machine which they haven't touched for years purely because
they want to run Rose Garden. There are other alternatives. Of course, there's plenty of
other alternatives, but what we've done is we kind of found our people, I suppose, through
the way that we'd built it, through the way that we'd gone about building it, maybe,
as well. The thought we put into it and the love, maybe, we've kind of built something
which is stuck around. And as you can see here, it does, this is it doing some audio
and it also plugs into this thing I mentioned called the Jack Audio Connection Kit, which
is a way of routing audio around internally on Linux and various other platforms, too.
So it's actually like an audio bus. Here's a virtual synth as well, which you can route
to it. So it works with virtual synths, external synths, et cetera. So what we saw was an emergent
architecture. As I mentioned, various things. I need to speed up a bit, so I'm going to
go through a little bit faster. I've also mentioned the Rose Garden Studio Concept. So this was
the thing about the device files. And I think this is another powerful feature of Rose Garden,
one that's still used to this day. So we've got over 100 device files, so people have
gone off and they built them for, I don't know, Yamaha synths, for Roland synths for
various different types. And you can just download those and install them into Rose
Garden. And you can map all the set, all the voices basically straight into it. Additionally,
we've got the, as I mentioned, the Jack integration, the support for Ladsper and also DSSI plug-ins,
which are native plug-ins for Linux and other platforms, as well as the VST plug-ins, which
are the standard music, more standardized music plug-ins, audio plug-ins for Windows
and other platforms. Additionally, of course, notation markup and printing using Lilypond
as well. So a very high quality score export from Rose Garden, which has been very much
appreciated by some of our users, too. So with all that rambling, this is one of the
learnings that I found, was that just the architecture itself is difficult because of
various reasons, communication, mainly, but also what do we want to build? Secondly, organization
around that is difficult, too. And we saw that with the refactoring, that we had to
suffer, essentially. Maybe with better tooling or maybe with more stable platforms that we
were building on, it would have been simpler. And in hindsight, it seems almost, yeah, trivial,
but at the time, it felt very difficult. Secondly, this is something which really stuck
a lot in the claw, in the throat, which is everyone has an opinion on UI, everyone. Users,
developers, even developers who don't profess to be UI or UX experts have an opinion because
we all use the software, right? And if you change anything, then you break a workflow.
And that's a difficult lesson to learn. You may be a great coder, but again, it becomes
the social angle between what are we trying to build and how do we keep people happy?
Because you could, and it's even happened on the Rose Garden developer list in the last
couple of days. Ted's released a new version before Christmas, but he's released a patch
version in the last week, and he changed one of the theme setups, so it defaults to something
that no one likes. So there's a little mini uproar going on.
On the flip side, when you do get it right, when you do spend the time getting your architecture
right and you're thinking about your code and your core, then sometimes big features
that you might have thought impossible even a few months ago are almost trivial to implement.
But suddenly, those points, you go, oh, thank God, we got it right, and you actually feel
that that is something that was worth spending the time on. It doesn't happen all the time,
but sometimes it does, and it feels great. And yeah, fourthly, in this little block,
literally all you need is a small number of users, and there needs to be loyal users
to keep you going. So even though you're not getting paid for it, if you've got passionate
users, it can mean everything. Okay. Talking of passionate users, we'd spend
some time in basements and online, of course, building stuff, and we thought, we and Chris
thought it would be a great idea to get out there and start showing it. And around the
same time, 2002 or so, there were Linux expo starting to happen in the UK. So through contacts
of ours, we were involved with Linux user magazine. I wrote for them at some point
together, and we managed to flag a stand at one of the first Linux expos, and this is
us looking all ruddy and young and lovely and wearing branded t-shirts. Look at that.
Made that myself. Fantastic. This is my friend Mike, unfortunately, not with us anymore,
but he was a great inspiration and helped us a lot and encouraged us to get set up.
And this is Chris. And this is our fantastic set up, isn't that? Just stellar. But today,
and yesterday, walking around, looking at people sitting behind desks, exactly, not
better, better desks, to be honest, with much more impressive set ups, it really takes me
back to those days when we were doing the same thing. We had our software, we were excited
about it, and we went out there and showed it to people. So, yeah, we were doing lots
of things, writing, went to trade shows, went to conferences. Well, yeah, not hundreds
of them, a few, a handful. We started approaching vendors, so there were people who were building
music, software, PCs, and we talked to them. Maybe they'd be interested. We talked to Roland.
We talked to Yamaha. We talked to loads of people. We talked to AMD. There's a book.
It's in my bag. There's the one second. So, Michael McIntyre wrote this whole guide, which
was published, The Rose Garden Companion. Yeah, and then we started talking to partners
as well. So, there were people at the same time who were betting their careers and their
livelihoods on Linux being the next big platform. Obviously, everyone thinks this year is the
year of the Linux desktop. But there were still people out there, well, then there were people
out there who wanted to build Linux-based hardware as well. We talked to a creator of
keyboards in Italy. We flew us over, and we talked to him. It was a fantastic couple
of days. We met his family, his mother made us lovely pasta for lunch, and we saw his
workshop where he was building these incredible multimedia platforms and keyboards in his
garage, basically, his garage business. Fantastic. So, yeah, we got out on the road. Also, we
launched a product. This was called Studio to Go. So, Chris and I, we formed a company
and we built a bootable CD, which enables you to basically have an entire studio on
your CD. You could put it into a Windows machine, and you could boot it up and boot it into
Linux, and you'd be ready to go, basically. You could also install it on your Windows
machine, too. This is Chris, the year later. So, from the previous photo, this is a kind
of a level of professionalism hire. We look more relaxed, more kind of in the moment.
Yeah, again, I think more relaxed. And then if we look another year further, this is us,
the kind of the high point of our career with Fervent Software and Studio to Go. This was
at the Sounds Expo in 2004, I believe, yeah. So, we weren't in this by ourselves. There
was an organisation called Linux Audio, as well, which is still around, and in fact,
I looked on the website yesterday, and apparently I'm on the board of directors or something
for, anyway, it's not a company, and I'm not on the board of anything there, but it
was like a kind of an open source collaboration group with a guy called Daniel James, as well,
who also I work with in journalism. He was a big proponent of another Linux audio platform,
which is still being sold, I believe. So, working together, we managed to get to a Sounds
Expo where it was not just Linux stuff, it was also Windows and the rest of the event
is there, too. However, at that point, it was getting clear that we weren't going to
make a living out of it, Chris and I. So, we kind of, with a family coming along, and
that's why I mentioned it at the beginning with a photo of my son, it was like a decision
to say, well, what can we do now? Because we tried a kind of business, didn't make enough
money for us, and we didn't really have the insight into what we should do next. So, we
just said, okay, let's call it quits for the minute. I dropped off from Rose Garden at
that point, but loads of people stepped up. One of the biggest things that they did in
the next section, which is the QT years, was to port it from KDE to QT, which meant basically
ripping out the KDE stuff. Sounds simple enough, but took about a year and a half, which led
everyone to understand that major dependency upgrades are very hard.
One of the good things to look at from the source code of Rose Garden now is that of
the source files that we have, about 1400 C++ files, most of them are pretty small.
So, under 500 lines, that's including comments. So, that's a good sign to healthy code base.
So, I'm skipping now from 2008, 2010, and I'm kind of looking towards what's happened
in the last 10 years, but also the future. So, Ted Felix came on board in 2010, and by
his words, I spoke to him in the last week or two, by his words, he said it suffered
from a lot of stability problems. So, this is, we have a GitHub as well, as well as a
source for, and GitHub is downstream, so it allows us to do some nice visualizations.
So this was around the first bit of work that we did to stabilize the initial Rose Garden.
This was around the studio to go time, lots of work there, and then this was around the
KDE to QT port, so lots of work went in there, too. After this, when Ted came on board,
he said basically he spent a lot of time stabilizing, basically getting rid of bugs and making sure
that there was adequate performance, and doing that, I think, I don't know, it was not unaided
for sure, but focusing on that a lot. And you can see this also represented in the way
that Chris and Gio were very involved here, and Ted was involved later, and this is my
contribution. And also, we see, again, from GitHub, the churn that was going on around
the same time, so studio to go product, QT port, and then stabilization after that.
But if you then look at, I'm just comparing us to Musa, which is another Linux audio work
station as well, and this goes up to 40 on this axis and up to a bit higher on this one.
So in terms of contributions, we're not far off what Musa is doing as well, which is really
encouraging to see. So I would say the product is pretty healthy, it's been stabilized, it's
still being used by lots of people, you don't hear about it a lot, but it's still there.
And I'm going a bit faster now because I need to wrap up, but the number one thing has got
to be people, and that's what I mentioned at the front of this talk. People to do the
work, of course, people to support you whilst you're doing the work, and the expertise that
you build together when you're designing something. So that's why I see Rose Garden
now is still surviving, and still something that we can contribute to.
So top five things. For open source, basically, I would say this as well. So good architecture
and good toolkit choices are super important, and they help with defining your quality and
defining how far you can go with any one thing. And if you're not getting anywhere down a
certain path, then just rip it up and start again, or refactor, or think really hard about
your design. Also, Ted's jumped in with some stuff here. As he's mentioned that stringent
requirements are merging, so making sure that you don't allow anything to merge, and in
fact, recently there's been a fork of Rose Garden because one of the developers has got
a bit annoyed that he's not getting his stuff reviewed, and it's fair enough, everyone's
doing it in their spare time. It's still a labor of love.
Also, I mentioned earlier, refactoring and unit testing, and I did actually run the unit
test code coverage, the other day on Rose Garden, and it's 8%, which is not good. Okay, there
are some challenges with a UI-based, whether with a GUI, but it should be higher than that.
So I imagine one of the things that I might be looking at as I dip my toe back in a little
bit is to maybe write some more tests. So number one, quality. Number two, coding is
social. I mean, that's one of the things that we don't realise is that we think we're going
to OSS, we can just hide maybe online or do some coding by ourselves, but increasingly
it becomes social. It's a different type of sociability maybe to working in an office.
But open source, I believe, is much more social than working in office because working in an
engineering job or software job in an office because you can just focus in on the one
thing that you're doing. You don't have to be maybe told that you need to be more interactive
in a certain way of working, but in OSS, you have to be. There is no question about it.
You've got to be able to defend your ideas and maybe persuade other people to. Also,
related to this as well, it's the social side of the customer engagement. It's the fact
that you do have customers or end users, however you define them, and they will have opinions,
whether you like it or not. So you're putting yourself out there.
Thirdly, and this is something I've come across in the last year or so, this guy called Seth
Godin. He's an American marketing guru and his approach, I really like his approach,
he's got a great podcast called a Kimbo, A-K-I-M-B-O, you should check it out. He writes and he
speaks really well, really pithily on lots of subjects about marketing and he's not like
a slimy kind of marketing dude, whatever kind of feel. It speaks to me as an open source
person. One of the things, one of his key phrases is this, people like us do things
like this and I think that's what it means to connect with your audience, to find your
audience and to keep connecting with your audience at the right level. So yeah, we might spend
some time arguing about how a UI should be or how we should architect this or if we should
reflect on that. However, it's worth it if we connect with each other and we connect
with our customers well at the same time. And also, he talks about audience, importantly,
because you don't need to solve all the problems in the world, all you need to do is solve
a few problems for a few people. Fourthly, use all the tools, so we are just so lucky
these days, we've got all these amazing tools, we've got GitHub, we've got Co-Curve, we've
got Cloud, whatever it is, lots of stuff, you know, Sonar Cloud, etc., all these great
things that we can use, Sonar type. So use them. Use CI, use unit testing, use TDD,
use all of the great engineering advances that we've come up with over the last ten
years to make our code better. And finally, don't take it too seriously. One of the reasons
that I got involved in OSS was that I could do it from, well, we could do it ourselves,
you know, we could put our little imprint on the world or do something fun. And that's
the point, it needs to be fun, it needs to be enjoyable. So when it stops being enjoyable,
don't do it anymore. And that is it. Thank you very much. Any questions?
Are there any questions? Oh, yes, there are. Please raise your hand. Okay.
Hi, thank you. I can't wait to give the software a try when I get back home. I might install
it later. But was there any possibility of you like playing a bit of music, maybe? No
demo today, I should have said that at the top. Thank you. Any other questions? Okay,
thank you very much. A big round of applause.