Succeeding with Open Source

Ruby

Philip Arndt

2 talks

Succeeding with Open Source

by Philip Arndt

In the video titled "Succeeding with Open Source," Philip Arndt discusses the importance and benefits of participating in open source projects, particularly within the Ruby community, as part of his presentation at RubyConf AU 2015.

The main theme of Arndt's talk is how engaging in open source has positively impacted his career, coding skills, reputation, and professional opportunities. Key points from his presentation include:

Introduction to Open Source: Arndt begins by sharing his journey in open source, mentioning his experience as a maintainer of popular Ruby gems. He emphasizes that success in open source is not solely financial but can also enhance one's professional presence in the industry.
The Evolution of M Tools to Refinery CMS: Arndt recounts the story of an in-house content management system (CMS) named M Tools, which eventually evolved into Refinery CMS, one of the most widely used open-source CMS for Ruby today. He discusses initial hesitations about open-sourcing valuable company assets and highlights the unexpected advantages that came from it, such as visibility and new client acquisition.
Benefits of Open Sourcing: Arndt identifies three main benefits of open-sourcing Refinery CMS:
- Showcasing Expertise: Open-sourcing demonstrated the company’s expertise to potential clients, helping them attract new business.
- Community Contributions: Other developers extended the project by creating their own enhancements, thus reducing the workload on Arndt’s team and adding value to their clients.
- Validation of Quality: By open-sourcing the CMS, the team reinforced the importance of quality software, gaining client trust and goodwill.
Key Takeaways for Contributors and Maintainers: Arndt stresses the significance of fostering a welcoming environment for contributors, underscoring several lessons learned:
- Investment in contributors is crucial for sustained engagement.
- It’s important to assume good intentions from contributors and respond with patience, especially when receiving potentially critical feedback.
- Simple communication and collaboration tools can lower barriers for new contributors. Arndt mentions the frustrations that can arise with complex git processes, advocating for empathy and assistance toward newcomers.

In conclusion, Arndt’s presentation offers a clear path for individuals looking to succeed in open source involvement, highlighting that the experience can lead to substantial personal and professional growth while cultivating a supportive community around software development.

Overall, the video serves as both an encouragement and a practical guide for Ruby developers eager to engage with open source projects, reinforcing the notion that open source contributes not just to individual careers but also enriches the software development ecosystem as a whole.

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.'

Philip Arndt

2 talks

RubyConf AU 2015