389COM: Becoming an Open Source Developer

Dr Carey Pridgeon, DR Nazaraf Shah

Created: 2017-07-20 Thu 18:25

Becoming an Open Source Developer

Benefits

  • Jobs all need experience.
  • You can't get experience without a job.
  • A Good Open Source Product can give you that same experience, if your project is complex enough (it might take several iterations to achieve this).
  • You get to control everything in your product
  • You can learn new technologies/practices without an employers deadlines.
  • It doesn't matter if you fail.

Managing Expectations

  • Making money from your project cannot be you motivation, because you won't.
  • Making money through the experience you gain can be, because you will.
  • Your project (if it's a lone project) isn't likely to be a worldwide success.
  • Having a few people appreciate your work can feel very good.

Starting your own Project

  • Identify an interesting subject that will teach you something new.
  • Choose an online repository (don't host it yourself, this isn't the dark ages)
  • Write a User Story (why is this product interesting/useful, even if only to you).
  • Pick a licence and start. (getting this aspect right is really important.

Joining another Project

  • Identify an existing project that interests you.
  • What value can you add to that project?
  • Write something and submit it to the project owner.

Develop Good Practices

  • The moment you apply for a programming job, someone will go look at your code online.
  • Write code, then write a test for that code, and document it as you go along.
  • Use Continuous Integration from day one.
  • Write loosely coupled code, such that you can re-use it easily, more of your open source projects will fail than will succeed (although this entirely depends on your personal definition of those terms), so you might as well be building up a decent code library as you go along.

What open source developers do wrong

  • The biggest complaint is that documentation is rubbish.
  • Thinking that users will not notice issues your code has (bugs or design).
  • Not responding to requests or recommendations.
  • Choosing the wrong type of licence. This has for instance been a major issue for Linux, Where Linus Torvald chose the GPL Version 2 without thinking about it.
  • Assuming your project will get additional developers as part of the initial concept.

Forking an existing project

  • Is it worth doing? Can your fork add value.
  • Forking has been used as a protest action (X-Org being a major example, also related to licencing issues).
  • Fork vs submodule, can you simply extend/utilise a project?

Research your field

  • Has anyone else done what you want to do?
  • What can you learn from their efforts?
  • If someone has done something, it doesn't mean you can't, but maybe collaboration to extend is an option?
  • Is there a demand? (if their isn't it needn't matter, but it might).

Walk first, Run later

  • Don't set goals too far ahead.
  • Design, and putting that design online with your code is important, since people will look if you apply for a job.
  • Perfection is not the aim, a design that sucks is better then no design at all, since a design can be critiqued, and improved, no design at all means a project that is doomed.
  • If you are enjoying creating your project, you are more likely to succeed.

Obligatory XKCD

goto.png

  • Copyright: Randall Munroe - XKCD
  • Mirrored in my hosting to avoid bandwidth stealing

Licence for this work

  • Licenced under Creative Commons Attribution-ShareAlike 4.0 International by Dr Carey Pridgeon 2016
  • (Licence does not cover linked images owned by other content creators)