Categories: Software Development

Lessons from “Producing Open Source Software”

The free book, Producing OSS / Producing Open Source Software, is one I’ve referred to now and again when thinking about how free/open source projects should be run and lately I’ve been thinking about how a big company like Red Hat works when they’re based around free/open source projects.

Here are some choice quotes that I think can serve as useful lessons for open organizations.

Continue reading “Lessons from “Producing Open Source Software””

Categories: Portfolio

Did a talk at Software Freedom Day in Toronto on “Open Source, Open Allocation”

Click here to see more information about software freedom day in Toronto.

The talk was on 19 September 2015.

Open allocation: people get to decide what to work on and how. Gives people an opportunity to contribute to strategy, business objectives, etc. It’s bottom-up in terms of organization hierarchy.

Closed allocation: people get to decide how to work on something, they’re given the what by their boss, other department, client, etc. This is the typical way things work at a job and in most jobs this will continue to be the case.

Open source projects are open allocation; the maintainer or developer decides what they want to create and then creates it. There’s no external incentive making them give up control over what they want to create.

I’ll be writing more on this subject and hope to do a few more presentations to clarify the ideas, but basically open allocation is the future of (most) work. Our productivity levels are high enough that we can let people have 20% time to think of new projects and to work on them. At a typical company you’re losing value if you don’t let the employees on the front-lines make contributions to the strategy or business objectives of the company.

Categories: Linux, Software Development

First code patch submission in a long time…

UPDATE: It got in, the patch was reviewed, updated and added to the main code base. The developer even added my name to the credits!

I submitted an issue to the Django Rest Framework project. There was a bit of a problem with the documentation’s example not reflecting the code. The oft-repeated “the docs are never updated with the code” line that other programmers like so much ran through my head.

I think the way I presented the issue was solid…providing enough detail about what I was trying to do, the code that failed, the error message that was trigged, the version of the framework I’m using, and pointing the area of the code base that potentially caused my issue: https://github.com/tomchristie/django-rest-framework/issues/955

To remedy this situation, I forked the repository, created a new branch, made the fix, and created a pull request: https://github.com/tomchristie/django-rest-framework/pull/956

Documentation is important, especially when a project has over 1000 users. Updating it should be seen the same way as fixing code or adding new features, it shouldn’t be seen as a chore. As I quoted in a previous post, “some text is better than no text”.

The author of Django Rest Framework, Tom Christie, was super quick to respond. I got a response to the issue within a few hours. The frequency of releases isn’t too bad either, it feels regular and I would definitely continue using the project over tastypie.

I haven’t submitted a patch to any project in a long time, I’ve only reported a few issues and it will be awesome if this patch is accepted.