00:00:00.599
Today, I thought I might actually talk about service-oriented architecture.
00:00:07.559
Hi! So some of you may not recognize me without my vanity sunglasses, which unfortunately, I forgot to bring. But I'm Philip Arndt, sometimes referred to on the internet as 'pa,' or just 'p'.
00:00:18.359
Like Scott, I filled out a form and became a member of Ruby New Zealand. Then, I filled out another form, and people voted. I live in Christchurch, New Zealand, which is a beautiful place with lots of sheep.
00:00:56.520
I've contributed to and maintained a few Ruby gems that everyone here is using, right? Not even 'emo' Ruby? Well, I mean, some people are.
00:01:13.920
Anyway, today I'd like to broach the topic of succeeding with open source. What is success? In this presentation, I'm going to focus mainly on how open source has helped my career's development and leave the ideas like saving the bees to Shan.
00:01:35.200
Once upon a time, in a land far, far away, New Zealand existed a group of well-dressed Rubyists—well, at least on supper day. The rest of the time, we pretty much looked like this. I was working with a company called Resolve Digital, which was my first job with Ruby.
00:01:46.440
We mainly built websites for clients. We liked programming, but not really manually updating anybody's content, so of course, we used an in-house built content management system for all of our sites.
00:02:11.319
This CMS was called 'M Tools.' It was surprisingly difficult to find a screenshot of it, but luckily, Dave came through and got me one. The problems with M Tools were that it was hard to maintain.
00:02:15.239
Bug fixes were really hard to share with other M Tool sites because to reuse it, we actually just cloned the repository again from GitHub and wrote the app directly on top of it. Who hasn't done that?
00:02:22.040
We almost replaced it with Radiant CMS, which was in its early days back around then, but we found that it was just a little bit too complicated for our users, and they were much more easily able to break their site by just putting a tag in the wrong place. M Tools wasn't perfect by any stretch, but I thought that its heart was in the right place; it just needed a little love to be something great.
00:02:50.640
What happened next may shock you: M Tools became Refinery CMS, which totally everyone has used, right? Crickets... Well, it's now the most popular open-source CMS for Ruby by a pretty good margin.
00:03:25.840
You might be wondering, 'Why would we open source a valuable company asset? Wouldn't all our competitors just take it and then undercut us?' But open source is free, so it can't be about the money.
00:03:39.280
With M Tools, it certainly didn't start out that way. We just thought it was kind of cool and wanted to share it with other people. We thought maybe we’d get some value back, but we soon found out that our clients actually liked being sold a stable platform.
00:04:05.680
They really liked popular platforms, and unfortunately, in our society, money is pretty important. So these days, whether to produce or use open source is often a very financial decision.
00:04:29.120
As the internet has made the world feel much smaller, it's important to do good work and sell quality software to our clients. What we found is that some people want to use your work that you've put out there for free, but others just want to hire you based on your work.
00:04:51.440
In Refinery’s case, by open sourcing it, we saw three main benefits. First of all, it showcased our work to prospective clients that we couldn't reach just through simple marketing. It also proved that we are experts in creating user-friendly systems.
00:05:16.560
We placed the company's logo on the project's website, which drove lots of traffic and generated many new clients. Other companies made websites for their customers using Refinery and fixed many of the bugs that sneaked in there. That was free benefit provided to us and free benefit for our clients.
00:05:45.000
It generated goodwill for our clients and proved to them that the open-source model was the way to go rather than some closed-source system. We also opened up an entirely new sphere that we weren't expecting, where people wanted to extend it.
00:06:03.880
People were writing these extensions and open sourcing them, sharing them back with us, and we could show that to future clients, saying, 'Hey, look! Now we can do this!' It was a win for us because we had to fix fewer bugs, a win for our clients because they got new functionality at substantially reduced prices, and a benefit for our contributors because they got to use great software to earn money.
00:06:31.080
But it has to be said, at the beginning of this, I was relatively new to open source, and it felt like diving straight into the deep end of the pool.
00:06:52.640
So what have I learned throughout this? One of the main things I've learned is that I definitely get out what I put in. This applies to dealing with both contributors and maintainers. If I didn't invest enough into the people contributing, then it's not very likely they'll contribute again. And I want that to happen because I don't want to do all the work.
00:07:31.760
I learned that I have to take contributions seriously and help those who want to contribute. This means that when they submit a feature or a patch, the first thing I do is not close it and say I won’t fix or won’t merge it, which may feel familiar from some larger projects that we won’t talk about.
00:08:02.160
This is key because contributors have to overcome a ridiculously large barrier to contribute their patches. Barriers include embarrassment, imposter syndrome, and many others, such as physical and financial constraints involved in spending their time working on your open source.
00:08:38.399
The next thing I learned is that when I write 'perfect' software, receiving a patch to fix something broken can make me upset. The contributor probably didn't want to offend me, and I’ve learned assuming that people are good is critical in open source. Given the many physical and cultural barriers that exist, I have to assume they’re helping me rather than trying to undermine me.
00:09:14.440
This ties back to the best advice I’ve heard from Jason Fried at Basecamp, which is basically to give it 5 minutes. Don't reply straight away. Step back, maybe close the laptop, and think about it. What’s really going on? Are they trying to offend me with their change, or are they just trying to improve things? It's probably the latter.
00:09:52.080
As such, I try not to put complicated roadblocks in the way of contributors; I try to make it easy for them. If there’s a complicated part, I can just do that for them.
00:10:16.320
Many barriers are unnecessary hurdles. A pretty great example of this is 'git rebase.' Who's used it before? Don't we love it when it works the first time? Exactly! Unfortunately, it almost never does.
00:10:33.760
If you've contributed to open source, you've probably seen this before—maybe from me. I apologize! But after years of experience, I like to think I’m pretty good at this by myself, so I can assist new contributors and say, 'Thanks for contributing your patch! Yeah, it doesn’t merge cleanly, but don’t worry; I'll sort that out.'
