The panel discusses open source projects.

 

Hey everybody and welcome to episode 88 of the iPhreaks Show. This week on our panel we have Andrew Madsen.

Hi, from Salt Lake City.

Jaim Zuber.

Hello! From Minneapolis.

We got some guy in here named Pete Hodgson.

Hello from Pleasanton, California.

I’m Charles Max Wood from DevChat.TV and this week, we’re going to be talking about open source. This is something that Andrew brought up. Talk about creating it, maintaining it, contributing to it, etc. Do you want to give us a little bit of background, Andrew? On why you_

51]

Yeah. So, I have two open source projects that I picked and talked about. I think we did an entire episode about one of them. One’s MIKMIDI and that’s an Objective-C library for doing MIDI on OS10 and iOS. It’s a wrapper for CoreMIDI but it also adds a lot of functionality on top of that. And then I also have an open source Mac library called ORSSerialPort that makes using serial ports on the Mac much easier. And lately, those projects have started getting to where they’re popular enough that I get a pretty steady stream of people using them and I get email from people and questions on stack overflow and issues on GitHub and that kind of thing. So, they’ve become more of a real thing that I’m actually maintaining. And I’m just learning a lot about how – what it takes to maintain an open source project. Because in some ways it’s like maintaining an app. You have to do tech support for people that are using it. People want new features and you either have to figure out how to add them or get try to get contributions from people, manage those contributions. I just thought it would be interesting to talk about and learn from each other about some of these issues. I think I’m getting a lot out of these projects; they’re fulfilling in the same way that working on an app is. It’s cool to get to work on stuff that other people find useful and interesting and helpful. And the collaboration with people who know more than you or know different things than you is also pretty valuable because I’ve learned stuff from people who have contributed. So that’s my background.

I’m curious. Did these projects start out as personal things that you decided to open source or did you start out with the idea of “I need this library and so I’m going to create an open source library that does it”?

In both cases, I did not start out thinking “I’m going to create an open source library”. For ORSSerialPort, I actually wrote it just for myself. I actually wrote it to replace an existing open source project that somebody else wrote that I was using because I just wanted to address some of the deficiencies and things I didn’t like about that project. I wrote it, was using it; I actually didn’t even really consider releasing it as open source until probably a year after I wrote it, but decided that other people might find this useful. So, cleaned it up a little and released it.

With MIKMIDI, there was a little bit more of a – at the very beginning, I thought, “this is going to be really good candidate for being a separate library even if we just share it between our own apps”. But really right when I started, I thought this would be fun to release as open source. So, that was basically open source from the beginning even though that wasn’t truly my motivation.

Anyway, in both cases, they definitely started out as things that I needed for projects I was working on and I would not have written them otherwise.

Gotcha. So, I’m wondering really quickly: when you decided to make them open source? Did you change anything on them or did you just open source them as a zeroed up whatever beta release? How did you make the transition into open source because, as you said, people expect a certain level of stability and support?

Yeah. That’s actually a really good question. No, I did not just release them just exactly as they already existed in my own projects. And some people do that. You can find lots of open source projects where somebody wrote something, they realized it was cool (they wrote it for themselves) and they just dumped the code on GitHub.

I’ve done that.

I’m not saying that’s bad because I think that’s a perfectly cool thing to do. But if you’re trying to make something that people are actually going to use, that’s going to get some level of popularity and contributions back, I don’t think you’re likely going to be successful that way because people want documentation. It’s really the biggest thing. So, the really the very first thing I did was I decided I wanted to have everything be a hundred percent documented the same way it would be if it were an Apple framework or an API. And so that was the big thing is to document everything.

if you’re going to release something as open source, it needs to be stand-alone. It can’t be all tangled up with the specifics of your app or it’s just not going to be useful to other people, unless they’re writing the exact same app of kind of app as you are.

And some of that I was already thinking of when I created them because I like to write certain parts of my – I think that’s good code design in general. Just to have separation of concerns. And so if you’ve done things well in the beginning a lot of times you can take a whole piece and open source it and it’s useful on its own.

Jaim, have you written much open source software?

I have not; I use it. Generally, I get to the point where I’m creating something and occasionally I have my [inaudible 06:21] something and make some changes but I’m not committing that much. I

generally do client work and convincing them to pay me to give back to the open source generally doesn’t go too well. But then that’s a question. So, Andrew, MIKMIDI, that’s based on work that you’ve been doing at your day job. How did those conversations go?

Yeah, that’s a – MIKMIDI was entirely something for a closed source app that we’re working on at work. And the conversation went really well. I brought it up to – well, we’re a really small company, small team – but I brought it up to my boss and said I’m writing this media library; it’s making our work way easier for what we were doing in Flow (which is the app that it’s for), and I think it would be good open source and really he was very open to it and he said, “Yeah! I think that would be really cool.” There were some discussion of the fact that Mixed In Key uses a few open source libraries that other people have written in. We’d like to contribute back to the community that we have benefited from. So it didn’t take a lot of convincing. There was certainly the idea that if there’s anything that’s “secret sauce”-ish – something that makes our app competitive – we don’t want to necessarily just give that away. But that’s not how the library is. There are many things that we do that we wouldn’t want to give away. We think they’re pretty innovative but those are implemented at a higher level on top of MIKMIDI. So, it went really well. The only difficulty is that it’s hard now to say – if I’m working on something else for work, to say, “well I’d like to spend the day on maintaining MIKMIDI”, just to maintain it. Not for us but for the open source project. Then, meh.” That doesn’t really go over as well in terms of spending the development money on things like that so I basically work on it on my spare time now.

It’s definitely valuable [inaudible 08:07] for companies that understand open source. Even if you’re spending some time working on a project and give it to other people, that can come back as goodwill, getting your name out there as a cool company to work for. So companies do benefit from a lot of people working on open source projects.

Yeah, we thought of that. And another thing is we’ve gotten contributions from people that have turned out to be useful for us. They’ve improved things for us in some sense. Certainly the bulk of the work has been by me and other colleagues at Mixed In Key but we have gotten – I don’t want to call it free work – but we’ve basically gotten free work from other people that improve what we’ve started with.

So you sell to your CFO as, “This is a way we get other people to work for us for free!”

Right! I don’t think the numbers really work out but something like that. And that actually brings up a point. There are a lot of big companies that have employees that they pay to work on open source. I think WebKit and Apple is a good example where many of the contributors – probably most of the contributors to WebKit and other projects like that are employed by big companies and they’re being paid to work on stuff that’s released to everybody.

What’s your experience been working on open source, Pete?

I guess I’ve had a couple of things that – so, I’ve had maybe a similar experience to Andrew where we built a tool as part of some project work and then we decided it would be a useful thing to share it to the community so we wanted to open source it. We had the extra complexity that we were trying to persuade the client to open source code we’ve built for them, rather than it being code that we own, and then just have to persuade my company. Well, I don’ have persuade ThoughtWorks because we’re big fans of open source. I have to persuade my client to give away the code that they paid for us to write for them. We just – more of a tricky conversation maybe but they were very open to it luckily for us. So we open sourced this testing tool called “Frank”, which is fairly popular. It’s used by quite a few different companies which is very satisfying for me. Yeah, for me the interesting thing about – well one other interesting side effect of open sourcing is that need to – it actually motivates you to do better of writing code. It’s kind of like code review or peer programming. Like it – knowing that other people are going to be possibly looking at this code in GitHub or wherever then definitely motivates you to do a better job of tidying up the loose ends and not taking any shortcuts. That’s one thing I’ve observed as people tend to do a better job with code that’s – even if there’s portions of their application that’s open source and portions of the application that’s not, I think that the stuff that’s open source tends to have a slightly better quality than the stuffs that’s just used for internal use.

I think you’re completely right, Pete. MIKMIDI, for us, has been a good example of that. We started out being used in the one app we were developing at the time but it is now used in actually four of our apps. And it worked out really really well because we had done the work to make it really modular and stand-alone.

There’s a model that quite a few clients that I talk to use or experimented with using, is this idea of internal open source. So, even if they’re not quite ready to put their stuff out there on GitHub – they treat their internal software or tools or libraries that could be shared by different teams – they treat it as an internal open source community and they – other people on other teams – they do all the stuff you do with open source, which is actually mostly not about coding. It’s about building community and documentation and all of the boring people stuff. They do the same thing for their internal open source assets so they’ll – if some team has built some library that they think other teams should be using, then they’ll write up a really compelling web page telling you why it’s so cool and they’ll go and give their notes to people and they’ll try to get more people using their tool. And then, once other teams start using their tool, then they’ll start, hopefully, contributing back; so you get that same benefit that you get with external open source where you spread the load of developing code and you get some of the same side effects. People tend to write – the internal quality is a little bit better if it’s something that people perceive as a shared resource. And the fact that you have to generalize stuff to be used in different contexts forces you to make it more modular and have nicer APIs and nicer abstractions. That’s what I’ve noticed. So you can do it even if you’re not willing; or even if you can’t persuade your company to open source your stuff in the big open source way, you can still do it internally. Particularly, that works if you’re in a really big company where there’s an internal community that could take advantage of sharing some libraries.

Yeah, that’s a good point. The client I’m working with now has a number of libraries in a similar situation where it was developed to scratch our own itch, but was also going to be shared by three or four apps plus any more that may come down the line. So you do similar things and you make them so it’s more modular, like you said. One thing that concerns me is a tradeoff where you write one thing to scratch your particular itch. It’s nice and simple, and all of a sudden you’re thinking about, “How can we do this differently? How can someone else use this?” And you get to the situation where you’re trying to create a butter knife and you end up with a Swiss army knife with saws and nail clippers and all sorts of weird things. How do you balance that?

That’s a really good point. I was actually thinking the same thing. There is definitely a tradeoff there where if you’ve got a tool that’s custom designed for your hand, you can make it a more general purpose tool and other people can use it, but you’re probably going to lose some of the ergonomics or some of the simplicity of something that was built solely for the single use case.

I completely agree. And I think the thing here is that if you’re going to call an open source project yours, maybe it’s just me personally but I feel a lot of ownership over it – sort of what I feel over an app – and I have opinions about the way things should be done, what should be included what it should be left out, that kind of thing. But you still have to decide upfront what that’s going to look like. Particularly, if you’re getting external contributions, there are sometimes hard decisions to be made about whether you’re going to accept the contribution, or you get a contribution and you’re like, “Well, this is not really the way I want to architect this.” How do you tell them “I want to do this a different way”? A lot of it is social and managerial.

I definitely observed that same thing with my open source thing where there’s one or two questions that come up that come up every six months or so on the mailing list because it’s something that seems like a good idea. And I just pretty much philosophically disagree with this idea. And so, I got pretty good politely saying, “I’m so excited that these people are using my projects and it’s great that they’re thinking of new use cases and blah-blah-blah. However, I don’t think this is a good idea for these reasons blah-blah-blah” and just reiterating it over and over again. At first, I was really nervous – I had some sleepless nights almost of like “Maybe I’m wrong. Maybe this person is right. I don’t want to turn away a contributor because I don’t have that many.” But the longer I’ve been – there’s certain things – almost when it is more philosophical than a technical debate, it’s easier because it’s just like, “Well, you know, you could be right, I could be right. When it comes down to it, philosophically, I think this is the better way to do things and fair enough. If you don’t agree with that, then we can agree to disagree.”

if only there was some type of feature that allows you to take an open source project and make it your own.

You mean like forking on GitHub?

Fork? Wow!

That’s a good name for it, huh!

I’ve actually – just in the last few – in the last week or so, I had somebody contribute – well contribute is a weird word because he basically sent me a big code dump of everything he had done.

[laughing] You got to love those.

In his fork or serial for it and it was a lot of code. I mean there was enough where I would have to wait until 2.0 or 3.0 to do any of that stuff. But there was some stuff in there that was good. And then there was other stuff that I thought, “Well, no, I don’t want to do this.” And some stuff that I thought “Well, I’d do this a different way.” And I’m balancing this, “Well I do want to include some of this stuff” with “I don’t want to include this other stuff, but I don’t want to offend the guy”, because I

liked the contributions and also there’s this danger if an open source project gets forked too much, you end up with Linux, basically, where there are a million distros and–

What a failure, right.

Well, not that Linux is a failure but it’s certainly hard to dive into and figure out which distribution am I supposed to use or whatever.

No, definitely.

02]

I don’t want there to be – in other words, I don’t want there to be four versions of my library that are all subtly different and this one. This guy’s got this one and this – I think Sparkle’s an example of that. Sparkle’s and open source project for automatic updating on the Mac. And it’s very widely used, but the guy who originally wrote it has not maintained it for years and there’s been this explosion of forks and there’s not really any one official one. And it’s pretty hard to–

I think that’s – the thing that you – I think you hit on the real reason these things happen in almost cases that I can think of is not normally this philosophical difference– but sometimes it is a big philosophical difference. But most of the time, those projects where there’s seven competing latest versions, it’s normally the maintainer lost interest or whatever and didn’t have a clean hand off to a successor. That’s where it gets really annoying. GitX is another example of that where there’s four or five different competing heirs to the throne. There’s this power vacuum and everyone is struggling. Or maybe I’m being overly dramatic about it. But there’s no clear canonical source. I think that most of the time, whoever is the creator of the library and therefore, the maintainer or whoever they passed “maintainorship” unto, is pretty easy for people to know that that’s the canonical thing as long as they’re responding to the community. And responding to the community by saying, “No, we’re not going to do this. It’s a bad idea” still counts as indicating that the project is alive and has a direction and that’s what people want. I don’t think it’s actually that common for fork in the pre-GitHub term – sense of the term fork like actually a competing alternative. That doesn’t happen that often and normally when it does, it’s a big – publicly – like a big name kind of thing like Node.js or whatever. It’s not normally – the average open source projects I don’t think goes through that quite often. [crosstalk 19:03] Just because the communities aren’t that big really. For there to be a schism, you need to have people on either side of the schism. Normally, what it is is everyone is on one side and one dude is like, “Well, I’m going to make my own version.” And nine times out of ten, they do for two weeks and they get bored and go off and do something else.

And speaking of the Node.js or – I’ve seen other libraries where they effectively forked. And what happens is there’s usually some kind of differentiating factor in the name. So Node.js, the recent fork is io.js. So they changed the name. There’s not as much confusion. It’s like, “You can use one, you can use the other, you can use them both.” And so, yeah, I think you’re spot on there. I do want to go back to contributing a little bit, though, before we talk about forking. Are there things in contributions that make you more likely to accept a pull request or something? Andrew?

Yeah, absolutely. So the example I gave is this guy who gave me a code dump. When I say a code dump, he literally just attached the source files with his changes. There was no repo involved. I can’t manually merge in your fixes for ten different things from a single file, that’s just not practical. So, I actually added a document to the repo saying that if you want to contribute, you really ought to, first, identify the issue that you’re going to fix and it should not be “I’m going to do ten different things all at once”. It should be one thing – one bug you want to fix, one feature you want to add; and then do a pull request because the workflow for – that GitHub enforces for contributions actually works really well: you fork the repo that you want to contribute to to your own account, you make your changes and commit them as well structured commits.

On a branch.

Yeah, on a branch. Well actually, if you fork the repo, you don’t have to do it on a separate branch, right?

Yeah. The reason that I say “on a branch” is because what a lot of people do when they’re new to contributing to open source is they’ll do, let’s say, two commits and then they’ll send you a pull request on master; and then they’ll work on something on master; and then it all starts tacky because that pull request isn’t a snapshot in time, it’s a pointer to the branch.

Oh right!

Yeah. I wanted to point it out because I see a lot of first time contributors on GitHub do – not intentionally because it’s not very intuitive at all, but it catches a lot of people.

So that’s a good point, Pete. You definitely want to make sure that the pull request – and this includes the issue Pete just brought up – but it should only include your changes in support of whatever feature or bug you’re implementing – bug fix you’re implementing. So you do that and you submit a pull request. And then, the typical workflow is maybe the maintainer of the project, they may have some comments or some feedback or some things they’d like to see done differently on the pull request and they’ll comment on it. And at that point, you can make further changes until they’re happy with it and the maintainer will accept – merge – your pull request into the main Repo. And it’s really that making it easy collaborate and making it easy to comment on and discuss and also view the changes that you’ve made that makes it much easier for a maintainer to really accept your contribution. Because as a maintainer, I’m not going to pull in changes if I can’t test them and really get a good idea of exactly what’s been done, review the code. Particularly, I want them separated out so that I can easily deal with them one chunk at a time.

One other thing I want to add to that real quick is that I’ve got a few open source libraries out there. Most of them are small things. They wrap around an API that hasn’t changed in years so I don’t do a lot of maintenance on them; but when I get pull requests – the other thing is if the changes, especially from commit to commit, are really small, then it makes it really easy for me to see what changed and so then I can identify whether or not you did just what you needed to get just that feature in or whether or not there’s some other stuff in there that maybe I don’t need or want.

Yes, I just like to – I mean a lot of it perhaps is you learn if you ran a code with your organization where you want small focused commits that describe what you’re doing and tell a story of the work. The same stuff applies with your contribution in open source particularly if you’re contributing to a popular project. Because the smaller the project, the more likely the person who gets the contribution is going to be like, “Oh wow! This is awesome. I’m going to spend – I’m willing to spend two hours figuring out what you’ve done and giving you critique.” But if you’re trying to contribute to CocoaPods or some popular library then you need to make it easy for the person taking that contribution and you need tests in there so they don’t have to manually test your code. They can look at what Travis or some other CR thing is doing – that kind of stuff. They want you to add documentation because surprisingly enough, there’s not an army of people waiting to document the contribution that you just made.

I think, Andrew, the point that you made about – I think what you were hinting at is that first pull request is the start of the conversation is a really big one. Because some people, particularly when they’re first starting, they feel like, “I want to do this work but I don’t really know if I should – I want to add this feature, I want to fix what I think is this bug but I don’t really know whether I should or not.” The advice I’ve heard people give and I agree with is just do it. Just do the work assuming it’s not a 20-hour endeavor. If it’s a couple of hours of you working on the code, do the work and you’re probably not going to do it the way that the maintainer wants. But if that’s the start of the conversation, it’s a much better conversation because the maintainer of that project knows that you’re serious because you’ve actually put the time in rather than you just saying, “You know what? This would be cool if we had this thing.” You’d get a lot more attention from a maintainer if they’re busy and a concrete implementation. Although if it’s your first time contributing, it probably won’t be quite the way that the maintainer wants it to be done. It’s a really good concrete thing to have a conversation about and talk through the right ways to do it.

20]

There’s a problem with the big blob things, too, is that it takes a lot of time to go through it. And open source maintainers usually are doing it in their spare time. If you want to get submitted and it’s going to take them six hours to go through all the changes that you made – whether or not they’re going to keep it all is a separate issue – it makes it hard for them to accept a pull request of that magnitude. So if you can keep it so it’s something they can review in a half hour and decide whether to keep it or give you feedback, then it makes it a lot easier to get those changes in there.

Yeah, absolutely.

Yeah, small focus is the way to go. With git being ubiquitous, there’s no excuse to not be able to do it because it’s very easy to – I wouldn’t say easy. Once you learn how to do it, it’s a simple process to take a big commit and chop down into small things that someone can look at their diff and go “Oh! Okay, that’s cool!” and accept it.

This goes back to what we started talking about at the very beginning. But speaking about preparing your code for open source release, another thing that I’ve found is just really important is to make it so that somebody who’s brand new – and a lot of times the people who are using your open source library (they’re not going to know that much about whatever problem it is you solved because if they did, they wouldn’t be using your open source library, right? They would’ve already written it themselves). So, make it easy for new people to get started. Like good documentation that tells people exactly how to install the thing or add the framework to their project or whatever and start using it is pretty important. And I think the same goes for contributing; I think if you want contributions, make it easy for people to contribute. Tell them what you expect ahead of time. Keep a good nicely maintained list of issues on GitHub so I someone wants to contribute just for the sake of contributing not because they found a problem themselves but because they think it would be a cool thing to do, they can go find some pretty simple bug and get started on it. And the barrier to entry is pretty low.

Big plus one on that.

Yeah.

I think part of that as well is in that kind of contribution – normally there’s a contributing text file in the directory that tells you what to do as a contributor. Good projects will have really nice instructions on what your workflow would be as a developer rather than as a user of the library or whatever. And obviously, those are actually quite different use cases. So, they’ll walk you through how to stand up the thing in some test mode or whatever and explain what kind of tests you should do beforehand and maybe they’ll talk through coding conventions; they’ll explain some of the philosophical ideas so that even though you’re really in to meta programming – the maintainer doesn’t like you to do meta programming so please don’t do that. All that kind of stuff is super helpful for lowering the barrier to contributions.

Right, and on GitHub, if you add a contributing – I think it’s contributing.md – a mark down file called contributing. It’s just like the read me. GitHub actually looks for that and then if you click on the pull – if somebody clicks on the pull request button on your repo, I think also the new issue button – there’s actually a little header on the page that says, “before you contribute, you should read this” and links them to that. That’s all built in and really – it does two things. It helps people get started contributing but it will also will, hopefully, raise the quality of the contributions that you get as the maintainer.

That’s cool. I always wondered how that worked. I always wondered why these magical projects have like a special piece of GitHub UI that I haven’t seen everywhere.

Yup. It’s not magic. I just figured that out a week ago but it’s pretty cool.

So, one thing that I’m wondering about, most of my open source contributions are in the web space – in the Ruby space. Does the contribution experience or whatever change when we’re talking about iOS or Mac or Coco?

I’m not a Ruby programmer so maybe, I don’t know. But I think fundamentally, probably, no.

Having worked in lots of different worlds, I think it’s pretty similar. The big difference that I see is you’re less likely to have any kind of CI on any kind of Continuous Integration on a Objective-C project or a Swift project than you are on a Ruby project for example or even a Java project, which is frustrating as a first time contributor because I’m always really nervous that I’m doing something really stupid and tests help with telling me that I’m being stupid. That’s one difference and I think and I guess the mechanics of CocoaPods is assuming that you’re contributing to a library that uses CocoaPods.

The mechanics of contributing – I don’t know. I’ve always found that quite fiddly. The running like a local version of the CocoaPods they’re testing the work as you’re going. I’ve always find that clunky but actually it’s clunky. The equivalent in RubyGems is also clunky so maybe it is pretty slow.

I do agree with you on that, Pete. If you’re using CocoaPods, it’s a little bit tricky. I mean, there’s plenty of information out there about how to do it but if you’ve never done it before…

25]

It’s one of those things that, after you’ve done it a few times, I imagine it becomes second nature but the first few times, it’s just very head scratchy like “Wait, am I supposed to check this out or do I change–”

“Where does this podspec go? What do I do here?”

Yeah exactly. That actually brings up something I wanted to raise which is that for iOS and Mac projects, in particular. I don’t really use CocoaPods personally, but I support CocoaPods in my open source projects and I feel like I get some good benefits out of that. One is that there are a lot of people who use CocoaPods and they can just install my library really easily with their CocoaPods workflow. But also, you get listed on CocoaPods.org. So, I think a lot of people go there when they want to try to find a library. So, if you’re on there, it improves discoverability.

And then the other big one is the CocoaDocs.org, which is the documentation counterpart to CocoaPods.org. And you get this nicely formatted appledoc generated html documentation for your project, assuming you’ve put in your documentation comments the right way. And it’s on a website that somebody else hosts. It automatically gets scanned for updates and all that. I just link people to CocoaDocs.org if they want to see documentation and it’s available in Dash without me having to do anything. Dash is a Mac app for viewing documentation. So there are actually a lot of benefits to supporting CocoaPods in your open source project on iOS or Mac. I’ve also recently started supporting Carthage, which was super easy. It’s easier than CocoaPods but that’s another discussion.

So what’s involved with supporting Carthage?

To support Carthage, you just need an Xcode project somewhere in your open source repo that builds a framework. That’s all. Carthage looks – will find that project and build the framework. I mean I’m sure there’s ways you could fool it and it’s still a new project but I had no problem at all. I

just created a folder called framework project and put an Xcode project in there that just builds the framework and Carthage automatically saw it. It was worth to do it. It was very simple.

Very cool. What other methods are there distributing, getting things to Kapow and end user’s applications?

You download the zipfile and then you drag it into Xcode and then you record a gif showing how to drag it into Xcode and then you put that gif in the read me.

I knew somebody was going to say that.

Well, I think Pete’s joking but at the same time, I do–

58]

I mean that used to be literally – I remember before CocoaPods like read me files that were like showing visual step-by-step of how to get that set up into Xcode right? That was the norm for a long time.

But, I do think it’s probably good to also realize that not everybody is going to use CocaoPods or something like that because we don’t have a standard dependency. CocoaPods is the closest we have but we don’t have a standard dependency management system for iOS. Things like adding a framework project now that we have frameworks on iOS – we’ve had them on Mac forever – but that’s pretty helpful because somebody can download your repo, open up the project and hit build and then they just get this framework that they can drag into their project and it’s pretty simple. I mean, obviously, you’re missing a lot of functionality that a real dependency manager gives you but the barrier to entry is low. You don’t have to install any new tools, etc.

With the testing – Frank, which is the testing tool that I open sourced – me and my team open sourced – wow! Almost five years ago now. CocoaPods wasn’t around and there was a Ruby component to it anyway so what we ended up doing was building – there’s a way to build a framework for iOS. There’s actually a static library but it looks like a framework as far as Xcode is concerned. And we would distribute that as a download and then you can just drag that framework into your Xcode project and it would just work without you actually having to include any source code or anything or change your build settings or anything like that. We did that for a while and eventually, we got to the point where I actually scripted modifying someone’s Xcode project for them using a couple of Ruby Gems. I actually go into your project, insert the framework in the right place. Massive amount of compiler flags. It’s not a fun thing to do. I don’t recommend it.

Wow!

That’s interesting because it reminded me of something that I never tried. GitHub supports binary races I think where you can upload a binary. So I think in theory you could upload when you do new formal release that’s tagged and everything you could upload a framework that’s binary and people don’t even have to compile the code if they don’t want to.

We did that for a while and then eventually what I discovered was like 90% of the questions and the problems that I had was – the people in the community had was getting started and figuring out how to – where to download it from and where to download it to so I eventually ended up automating that. But it did – it made me realize that – wow! Let’s say two people this week have posted on the mailing list asking about this. That probably means that 20 people tried it and just failed and just said, “Screw this. I’m going to go and use something else instead.”

So for me, that was like – the bigger point there is as a maintainer of the library, I would spend way more time focusing on the onboarding experience for a new user than I would on the actual functionality because I want – I believe in the value of the thing I’m building and I want more people to get that value. And most of the time, the thing that’s stopping them from using the thing isn’t the functionality. It’s that barrier to entry of getting set up with the project so the easier you – the more compelling you can make their onboarding experience, the more likely it is that someone’s going to use your tool and get value out of using it. And then I would get more starts on GitHub and my ego swells so that’s good for me too.

How many points in life are GitHub stars worth?

Well they get like this – have you guys ever seen Coderwall? It was popular for a while and they died of. There was this Coderwall thing where you would get badges for different things that you did on GitHub. There was like a badge that you could get for a thousand stars on GitHub and I coveted that badge quite shamefully.

Did you get it?

Yeah. Eventually. It took me a few years.

I don’t have a thousand star badge.

I have the advantage that this was back in the day when the only way you could indicate interest in a project was to star it. Now, there’s like – GitHub has the watching and the starring. And so, I think maybe, nowadays, I would have a hard time reaching – getting my ego swell that way.

17]

Yeah, exactly! There’s like I want to see this think – I’m skeptical. I just – let’s see how this thing works out.

Well, I’m about to completely show that I’m a hypocrite. Don’t get too caught up in stars. It’s not really exactly a popularity contest. At the same time, I check my stars and I get a lot of email from people that are using the library and have questions about it or whatever and they’re not in the starred list and it’s obviously some – probably pretty small subset of people who think your library valuable but think to star and then again – I’m sure there are people who run across it and they’re like “This might be cool!” and they star it but they’re never going to use it. It’s sort of meaningless – a fake Internet points number.

I was obviously being a little bit facetious with the ego thing but it is actually – it is pretty relevant right because I – most people are doing open source not because they’re being paid for it. They’re doing it in their spare time. That they’re going over and above their normal coding life and build something for other people as well as themselves. And the flip side for that is very – I can say for me personally – it’s super satisfying just to find out that somebody is using this thing I built. And then when you get someone send and email saying, “Hey, thanks! This is a cool tool.” It’s like the best email you receive that week.

Oh, yeah! Absolutely!

And I think getting some visitors, that is actually really helpful in motivating you to keep putting in those extra hours and to deal with the really boring, crappy parts of maintaining open source like, I don’t know, like writing documentation and replying to stupid questions on the mailing list or all the stuff that’s thankless. You get fuel for that by seeing that people actually using that thing that you built and getting value out of it.

I actually ask in my read me. I say, “I want to hear about cool stuff that you’re using this in.” – both of these projects that we’ve talking about. And I get cool emails. I remember one of the very first emails I got when I released ORSSerialPort from a guy who was using it to build a kegerator for the office with a – I don’t know exactly what he was doing. He had a Mac app to control the kegerator that he was building with an Arduino. A guy that’s using it for the Pinewood derby timing system he’s for his local Boy Scout troop. And I’m kind of lucky–

That’s awesome!

My project’s a nerd friendly thing like that but yeah it’s pretty fulfilling to see the stuff that you had some small hand in making possible.

Yeah, I wish the project had some use for the kegerator. We could play like the beer barrel bowl or something.

How do you know if you have a good candidate for an open source project? If you‘ve written some code, how do you identify that this piece would make a really handy open source library?

I think that the answer to that question is actually in many ways similar to the way you know that you have a good idea for an app. It may be that there are already open source libraries out there that sort of do or sort of tackling the same problem but you don’t exactly like the way they’re done or you see deficiencies. I think for a lot of open source projects, these deficiencies may of even be technical so much as they are a lot of these things that we’ve just been talking about that they’re not well maintained, they’re documented, they’re not being actively contributed to. So there’s that. And there’s also certainly the case though where you just write something and then, “Well that was cool and useful and I’m just going to see what happens.” I don’t think you need to be overly concerned with whether it’s going to be popular or not if you’re doing it mostly for fun.

57]

Yeah there’s nothing wrong with just doing something, throwing it out there. This might be useful. We’ll see.

I think it depends to an extent whether you want to just throw it out there, put it other in case someone wants to use it; if you want people to use it – if you feel like this is something that other people would find valuable I want people to use it. Because in the former case of just “I’ve built this thing and I think maybe someone could make use of it. I’ll put it on GitHub.” That’s pretty low. That’s – you don’t really need to answer that question of will people use it. You just it up there and see if people use it or not. You just stick your license on it and you’re done.

37] being like an app is really good. Like it is like a product that you’re marketing to people and you need to look at the market and see if people – see if there’s a product market fit and all that stuff. And if you’re serious about wanting people to use it, then you do need to treat it as a marketing asset. Write good documentation and figure out how to engage with your users on Stack overflow and Twitter and all that – all that kind of stuff. It sounds really stupid but I actually think it’s what makes open source successful.

30], I could imagine which one is going to become popular.

Yeah, exactly right. I think this marketing (marketing’s a funny work because you’re not selling) but this marketing of your open source projects, it’s really quite similar in many ways to doing the same with an app. You have tech support you have to do, you have new features you have to add, people who report bugs. It’s very similar.

Yeah, one other thing that I’ve noticed as far as choosing an open source project in the first place is just if I’ve written a code in one place and then I wish I had it at the end of the project then I start looking at extracting from the one so I could use it everywhere. I was going to ask about an open source app because I’ve seen those in the past. Where somebody has written an entire iOS app and they open source the thing so you can go find the entire source on GitHub. How is the conversation different on those do you think?

So I – that’s actually a really interesting question. I’ve seen these too. I think the motivation in it is most often going to completely different from a library because with a library, people download your library to use it in their own app that is probably completely different than what you used it for. You can’t really do that with a whole app right?

Unless I can think of some – I guess you could think of some specific niches where maybe you release an app for dentist office or something and the goal is the dentist’s office developer can download it and change a few things and have a custom version of it or whatever. I don’t know if that’s ever really been done successfully but you can imagine it. But a lot of times, those open source apps are – the motivation is to get people contribute but even more is to release it as a teaching tool. It’s where people can go to look at how things should be done.

Or it’s used to demonstrate how to integrate with some SaaS product or something like that. I’m sure Parse have written a few open source apps that show how you build an app that uses Parse, for example. It depresses me a little bit that there isn’t that much of a – the open source – I was going to say that the Objective-C or the IRS community doesn’t have much of a tradition of open source applications rather than libraries but now that I think about it, they really leave it to the web community, the limit community, they’re really the only people to open source user facing stuff very seriously. Most of the applications I think of that I use on a regular basis are either web apps or apps on my phone are closed source. Which is kind of sad, actually.

Yeah! I think partly that may be driven by the app store culture. Because you certainly can release an open source app on the app store under your name and even sell it if you want to. But somebody can’t really download your open source app from GitHub and easily get it on to their phone unless they’re a developer. And even then, it’s this weird workflow. And I think the situation’s a little bit better on the Mac. This whole discussion though of open source apps reminds me of something regarding open source libraries that I think is really valuable, which is to include sample code. So, include small apps or whatever that use the library so somebody can look at code that works that uses your library.

It’s a good way of testing it as well.

Speaking about example projects, I have an example project in ORSSerialPort that is just a simple serial terminal. So it lets you open up a port, see data coming in, send data out. And I completely wrote it as just an example app. This is how you can use the library. It shows off some of the cool features of it. Makes it so I can test any features that kind of thing. But I get a surprising amount of email from people who download the repo and it’s actually that app that they want. They’re using the app. They’re not using the code. They’re just using the app for what it does. I don’t exactly know why that is. It’s not the only one out there that does that. It does surprise me.

Because yours is the coolest.

No! It’s actually pretty lame. It’s all default UI. I didn’t write it to be pretty. So, I don’t know.

So, I got one thing that’s been running around in my head as we’ve been talking about this particularly with libraries is versioning and maintaining compatibility because this is something that the average – I actually don’t think you have to deal with this that often as the producer of an API like how do I not break stuff every time I ship a new version. We used to be able to just change the implementation and then change the code consuming that library and we’re done and we move on to the next commit.

When you’ve got people using your code in ways you don’t even know, versioning becomes like a total pain in the behind I would imagine. Have you ran into that, Andrew?

I absolutely! So, there’s this – I think probably a lot of people are familiar with but there’s this concept called Semantic versioning. I’ll have to find the original – it’s a blog post I think about it. I’ll have to put it in the show notes but. Anyway, the idea is that you version your library with version numbers that are actually meaningful. Usually, there are three. There’s a major version, a minor version, a point version. I don’t know what they’re called. I can’t remember but if you’re going to make breaking API – you only make breaking API changes so that those are changes that require users of the library to update their code in major releases like going from a 1.0 to a 2.0. If it’s only the last point that changes, you need to make sure that those are for bug fixes or really minor new features that are not going to break anybody’s existing code. They’re not going to change the way library works.

But you certainly have to be really conscious of that when you’re developing the library because you’re completely right. It’s not just you anymore. You can’t just arbitrarily change the name of a method or change the way that it does something. You even have to be careful about things like side effects or timing because you never know what weird things somebody’s going to use your code for and you don’t even know about it. It’s the exact same problem that Apple has really with versioning Cocoa. You can deprecate things but you can’t really just pull them out right away. Or if you do, you have to be very clear about communicating that to your users.

And the thing that becomes really tricky is when it’s not a syntactic change. It’s a semantic change. The way that your code works means that method A is called before method B and someone has somehow managed to depend on that behavior – that internal behavior of the application and then you accidentally change that or you intentionally change it and breaks stuff and it’s like, “Well, was that part of the API? Was that part of my contract that I was supposed to do things that way? Maybe it was; maybe it wasn’t; or maybe you know that it was but how do you keeping track of those semantic changes to the way your library does things. And it’s something that we don’t run into when we’re just developing private APIs for ourselves not for the world.

Right. So the syntax level changes or like naming changes. Those are actually the easy things because just don’t do any of that. Just don’t change method names and you’re fine but semantic stuff can be quite a bit more – the kind of things you were talking about can be quite a bit more difficult. But I think – do you think you have some leeway. It’s an open source project. It’s not a platform API. And as long as you communicate well and give users an out, they’re not forced to update to the newest version. I think you can deal with it.

And you can do the deprecation thing as well where if you find a typo in the method name or something, then you can make a new method name that doesn’t have that typo and then mark the old one as deprecated. Actually, does Objective-C have mechanisms for marking a method is deprecated? They must do because Apple must do this on its own.

Yeah, there’s a LLVM attribute for deprecate and I think there’s actually a pound to look for it. It’s NS_deprecated, something like that. You can annotate your method declarations with that and then, Xcode will throw up the usual deprecation warning. But another thing I’ve done, there’s actually a feature in MIKMIDI that was there from the very start and at some point – and we were using it in our app – at some point I just realized that I was actually that whole feature that I had written was a stupid idea. The functionality was nice but it basically had a severe performance problem. It just didn’t scale well. I decided I just didn’t want it in there anymore and I didn’t want to support it but I couldn’t full on pull it out because I’m sure people were using it. So, I now log a message: “This has been deprecated.” The first time somebody calls the method in their app, I log a message that they’re using a deprecated API and it will still work.

But future versions won’t.

Yeah. They should migrate away from it. And I think I even say, “Here’s the alternative. This is what you should do instead.” And Apple does that kind of thing too sometimes.

Apple, the source of truth and light. We love them.

Yeah. Right?

I’ll be honest. With a lot of my open source stuff because I know that it doesn’t have a huge user base and because my nature is I’m a little bit of a cowboy to be honest, a lot of times I’ll abuse the Dash pre-release thing that sends a defiance. So I don’t know if it works in CocoaPods but in Ruby Gems, you can release – a pre-release of the changes. And I will just float those out there and ask people to download it and try it out and see if it’d broken anything and let that bake for a week or so and if I don’t get any complaints, then, I’ll bump the – remove the pre thing and that’s my new version, which is totally unprofessional to be honest. But haven’t got into too much trouble so far.

I think if you have a really active project with a lot of contributions in a really healthy project, this problem becomes somewhat easier because you may work on a major new release on a branch for a long time and there are a whole lot of eyes on it and people start to know about it. I’m thinking of CocoaPods or AFnetworing. CocoaPods has been working on Swift support lately and they now have a pre-release branch with Swift support and they’ve announced it and I know a lot of people are using it. So really can do the same beta test cycle that you would do with an app. But, I think that’s a little more difficult when your library is small and there are people using it but not thousands of people using it or anything.

Yeah, that’s true. It’s like Facebook can test on products easily because when they screw up, there’s ten bazillion people discovering this where if you’re a–

Yeah, they find it fast and they roll it back easily, hopefully.

If you imagine your local church’s website, then you’re less likely to be able to test in prod. Although, you probably do test in prod more often because–

Right. Because your impact is smaller.

With that website you’re coding in prod.

That’s because prod is your laptop plunked into a–

Just put on a cowboy hat and go to town.

Pew pew pew.

Yee-haw. Nice so the only other thing I have is testing your library. I’m assuming that when you distribute it, the tests are just around but it doesn’t impact anything when people include it.

Yeah, this is something I’m really bad at for a couple reasons. One is that I’m just not that good at unit testing in general. But the other problem is that both of the libraries that I have that we’ve been talking about MIKMIDI and ORSSerialPort. Those are all really built on talking to external devices and so, that’s hard to test. ORSSerialPort is a wrapper for the I/O kit stuff that actually talks to serial port hardware. I’m sure there’s ways to deal with that but it’s not my area of expertise and I must admit to not having done it. So I actually use the example projects as my test beds and I

generally have to do a lot of manual testing where I get them hooked up to real hardware.

I do have some – one of the applications that I use that library in. I do actually have a very fullfeatured test rig that is an application that mimics the hardware that the app talks to. That way, I can test that. But it does require me to have this separate app running. It’s not just a compile time test unit kind of thing. I think Pete’s right thought that the Continuous Integration test culture on iOS is just really not that well developed for various reasons. Pete, do you know any – so, it seems like I

worked on, particularly on CocoaPods back when they had the GitHub specs Repo. If you made a specs update, they would run a Travis job and your thing would have to pass a bunch of tests before they would accept the pull request. Do you know anything about setting that up so you can actually have a CI test run?

Yeah. It’s pretty straight – Travis has supported iOS, well Xcode projects for a while and you set up Travis it’s actually not that much more complicated than setting it up for a Ruby project or Java or done that. Well, not done that, but it’s pretty straightforward and you just say just like you’d right a bash script on your local system that runs all the tests and returns the right exit codes. You just do the same thing and then Travis keeps magically sends you a GitHub repo and will add that information to the pull request.

What’s golden about Travis and why it took off so well or why people love it so much is it will do that CI on every pull request. So like you said, for CocoaPods, when they get a pull request come in, or when anyone who has Travis set up gets a pull request come in, Travis will take the code on that pull request and run whatever you’ve told it to run on a machine somewhere on the cloud. I think it really – CI really comes in to it’s own – tests in general really – test information really comes into its own with these kind of products where you don’t have to be manually verifying someone who you don’t know at all. Like the first time somebody contributed to your project, you have no idea whether they’re the next Linus Torvalds or like a very competent developer. And having the gate be an automated gate so it just says that these tests are passing or these tests are failing and have that right there on the GitHub UI is super useful. Totally worth the effort to do even if it’s just a – so the minimum bar, which I think depressingly is actually quite useful sometimes. It’s just “Does this thing compile?” In awe of the different ways in which you want to compile it. Does it compile for iOS and OSX? Because Frank has an OSX port and it needs to compile in both those modes. Just checking to see whether it compiles would actually, of course, saying this, I haven’t actually set this up. But it’s actually. It should be really easy to have Travis do that trick for and give that fast feedback to a contributor so as soon as they send a pull request, within a few minutes, they’ll know like “oh, look at that I guess I have to make it pass in OSX as well. I’ll go back and change things.” It’s pretty straightforward to set up. It’s worth doing.

Yeah, I’ve seen people do that with other CI systems too.

Of course the ThoughtWorks Snap CI system also has all of these features and is available for free use for open source projects. I had to do that plug so.

No, that’s fine. They’re a sponsor of the RubyRopes podcast so.

Alright, anything else? Or should we do some picks?

I don’t have anything.

Alright. Let us pick. So I got a couple of things that I can talk about real quick. First one, I picked this on the other shows. But I’m really enjoying it. It’s called DeskTime. And this is something that Mike Hostetler. I talked to him on Monday for the Freelancers’ Show. He turned me onto this. What it is it’s a way to track your time. Now, not like for your clients tracking your time if you’re a freelancer and you’re tracking hours. But instead, it just tracks your time in general and it tells you you spent an hour on Youtube and you spent and hour in Gmail and a half hour in Xcode and whatever. It gives you an idea of where you’re spending your time. And then, you can decide, okay, I need to spend a little bit more time working on these things and a little less time working on these others things and a lot less time playing World of Warcraft or whatever. I’ve been using it for a few days. I’m really liking it and I can designate things as productive or non-productive and then work that out so I can see where my time is going and make sure I’m spending it on the highest priority stuff. I think that’s it for me. Jaim, do you have a pick?

Yeah, I’ll make one pick. So there’s been a library I’ve been using over the past few weeks. I’ve been doing mostly Swift code for the past month or so. If you do any network stuff in Swift, then you know that getting JSON into an opix is a pain. So there’s one library I’ve been using and been pretty happy with because going from optionals to non-optionals is a pain but SwiftyJSON is a really cool library that I’ve been liking that let’s you avoid a lot of that dance. Having eight if-let’s deep into your code. So, I’m going to make my pick as SwiftyJSON. Bailable, CocaoPods (actually I don’t know if it’s CocoaPods. It’s Swift only) but it is on Carthage. It’ll probably on CocaPods soon.

Yeah, CocoaPods’ Swift support is in pre-release now so if it’s not there now, it should be soon I think.

Andrew, do you have a pick for us?

Not exactly. I came up with a pick and I searched through our picks. But it was a long time ago so I

guess I’ll pick it again.

Yeah.

It’s an app called – it’s actually a pair of apps that are next to each other in my dock that I use fairly often. They both share really colorful terrible icons. And they’re both not exactly very polished but they’re still useful enough that I use them often and keep them on my dock. The first one is just CocoaColor. This is just the little Mac app that got a bunch or different ways to pick colors. You can use the color picker. It’s got hue saturation and brightness sliders, etc. and it’ll just copy the code for UI color or NS color or CG color to your clipboard so you can easily add the right colors to your code. I think it’ll also do CSS and that kind of think. It has support for gradients too. If you’re on the Mac, there’s a class called NS gradient. On iOS, there’s CG gradient. So it’ll generate those too. Pretty cool and pretty useful when I’m doing custom UI stuff and need to do work with colors in code.

The other one is called Unretiner. And it’s got a bad name. But this is just a super simple app where you can drop an app to x ping onto it and it will scale it down and create the non-retina version for you. And so, a lot of times when I’m working on an app interface, I’ve got the retina assets and every time I make a tweak to an image, I need to create the non-retina version too. So those are my picks.

Very nice. Pete, do you have some picks for us?

I do. So the first pick I’m going to make is a conference talk called the social coding contract from a guy called The Social Coding Contract from a guy called Justin Searls. I’m picking this despite not actually having watched it all the way through because I’ve been to a couple to other talks by Justin Searls. He’s a very smart guy and very interesting guy. Has some interesting ideas. And the topic of the talk is relevant. It’s about open source and how – the social aspects of open source. I think it’s probably worth the watch.

I’m going to do some self-service picks. Some open source libraries that I maintain. The first is a Gem – RubyGem called microstatic and it’s just a really easy way of deploying static websites to S3 buckets if you want to host a website and you don’t want to pay money for it. The tenuous connection to an iOS podcast is if you have an iOS open source project and you want to build a

website and you want to deploy that website somewhere, then you could use this open source product to do that. Microstatic.

I’ll pick Frank, which is my testing tool because we’ve been talking about it a lot. Other testing tools are available. I have a preference for this one because I built it.

And then the last thing I’m going to pick is three things. Post it notes, index cards and Sharpies. If you’ve ever worked with ThoughtWorkers on a project, you know that we’re obsessed with these things. Just recently, I was – had like two days of brainstorming sessions with a team of people. It is just amazing how much effective you are at thinking when you’re moving physical things around and you’re looking at physical things on a table or on a wall. So, if you’re having to be creative and think about things and try to kick yourself out of a rut, then get out of your seat, write some stuff with some sharpies and come up with some new ideas. Those are my picks.

Can I amend one of my picks. So I didn’t realize this when I picked it but unretiner, the second app I picked. I just looked and it’s actually open source. I didn’t know that at all. What we talked about there not being that many open source apps. It’s a Mac app. It’s on the Mac app store but it’s also on GitHub. Seems like there’s actually a pretty healthy level of people forking it to add new features. There’s a bunch of different versions of it but it’s just cool example of an open source app that’s also useful and on the app store.

Awesome. Alright, well I just want to throw out a big thanks to you guys for coming. We’re wrapping the show we’ll catch you next week.