> There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”.

I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something.

If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in.

The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place.

> It’s not obvious where to start.

This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this.

Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules.

I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at.

Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out.

> Guidelines often make a maintainer’s life easier, and mine harder.

I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work.

> Open source is for people who are better at this than me.

I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way.

> Trying to contribute and failing makes me feel stupid.

Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things.

> There’s no time.

Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :)

> It’s pretty lonely.

The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.

Definitely a misleading title and kind of unfair to Rackspace. I founded Slicehost (with Matt Tanase) and I absolutely think this is the right thing to do and definitely is the best thing for existing Slicehost customers.

Given that this is a public plan now I feel like I can share that during the acquisition process of Slicehost we debated heavily what the right thing was to do with the brand. It was honestly a very very tough call and at the time the thing we all (Matt, me and Rackspace) were most sensitive to was to not disrupt the Slicehost community. We succeeded in that goal but the net effect (unintentionally so) was to disconnect Slicehost from Rackspace's cloud roadmap and effectively strand the product.

Unfortunately I think in hindsight I can say that our decision was probably the wrong call. I honestly think everyone would have been better off if we just ripped the band-aid early and tried to figure out how to make the core Cloud Server community out of the incoming Slicehost customers.

Control panels, features, pricing, etc all change and in the long run are only ephemerally important. What matters is having your interests be in the direct path for the company that is serving you and as a Rackspace Cloud customer you'll have that, while as a Slicehost customer you did not (post acquisition).

I definitely can see this from all sides and for Slicehost customers, all I can say is that at no point along the way did anyone (at Slicehost or Rackspace) ever have less than the best intentions for the brand and the community. There are some serious champions of Slicehost at Rackspace both in the form of former Slicehost employees still there (Paul Tomes, article site creator) and long time Rackers. Trust me that these guys are really working for the best for you all.

Here's how you contribute to open source. Start writing some software. Use an open source library.

One day, something will break. Instead of whining on the bug tracker or hunting for shitty workarounds... open up the library source, delete the bug, make a diff, and send that to the project maintainers with a note like, "I was trying to call foobar, but it segfaults because bazquux is off by one. Patch attached."

That's contributing to open source.

Alternatively, write some code and share it with people. That's good too.

>Justice Tennent jailed Monks for 18 months, with the last 12 months of the sentence suspended on condition she be of good behaviour for three years. >She was ordered to repay Aurora $193,187.43.

This is a horrendous miscarriage of justice. 4 months internet access = approx $80.