I made the mistake, apparently, of previously announcing the fact that I was hiring freelance free software developers, with as little fanfare as possible, tucked into the bottom of an article that was primarily about other stuff. As such, nobody really noticed that “you can get paid to write cool software” message.
Well, in light of that, let me try again, more bluntly and with vigor.
I am, right now, sponsoring the development of EJTP, and other parts of the DJDNS stack as they become mature enough. With real cash.
You can take a look at the repository here.
Now, I already explained the technical environment in my previous post, but not really focusing on what would be important for the role of a freelance developer. Let me try to summarize the important bits.
I have an issue label for issues in the EJTP bug tracker on github, where the sponsored bugs are listed. I’m using FreedomSponsors.org for a funding platform, which is underused but fairly straightforward. If you have a github account and PayPal, you can use FreedomSponsors.org.
Right now I’ve only got a couple bugs in there, but the more mature EJTP gets, the more I can offload onto other people without getting into architectural conflicts.
Developing for EJTP
$ git clone https://github.com/dlitz/pycrypto.git $ cd pycrypto $ python setup.py build $ sudo python setup.py install $ cd .. $ git clone https://github.com/campadrenalin/DoctestAll.git $ cd DoctestAll $ python setup.py build $ sudo python setup.py install $ cd ..
Now that you have the dependencies installed, install and test EJTP, forking your own copy on github (you do the fork process through the website):
$ git clone https://github.com/SomeBlokeThatIsMe/EJTP-lib-python.git $ cd EJTP-lib-python $ python setup.py build $ sudo python setup.py install $ doctestall ejtp
If you get any errors right off the bat, please put them up in the EJTP issue tracker so that I can help you out. It might be something simple like the wrong version of Python (EJTP hasn’t been tested in 3.X), or it could be some convoluted bug in my code. Either way, if there’s anything seriously wrong, the unit tests should catch it in my last step.
If you don’t get errors, you can go ahead and move on to the next step.
Actually doing work (project workflow)
Make a branch with a name that follows the pattern “bugX-faster-widgets”. In this example, we’ll tackle the gzip enhancement ticket:
$ git checkout development $ git checkout -b bug20-gzip-compression
This creates a new branch and immediately checks it out, forked off of the dev branch. Now you can go ahead and do your thing, writing and updating code to make stuff work better.
An important thing is that if you want your code to be accepted, include unit tests. You should be using the unit test system anyways to help notice/deal with regressions, and to confirm that your code works without having to constantly run external scripts or what have you. If you actually use the unit testing system as part of the development process, it’ll make you more efficient, and make it less burdensome to include tests as part of the patch. If you don’t write the tests, that puts the burden on me to do it for you, and unless it’s something extremely quick and easy, I may just outright refuse to do so, because that’s not my job. He who writes the code, writes the test, or finds someone to do it for him.
Once it’s done, you’ll want to push it to your fork of the project on github. I prefer work being broken out into multiple comprehensible commits, but I’ll accept single-commit work, especially for small jobs.
$ git add . && git commit -m "Closes #20: GZip support is complete" $ git push
And create a pull request through the github website for me to pull that bug branch into my development branch. This is when I take a look over the code, do any finishing touches that need doing (and commenting on the pull request so that you know what I’m doing and why), and ultimately merge it into the main dev branch.
I don’t want to write a whole git tutorial here, and even if I did I’d surely still miss including whatever ends up being a point of failure, so be sure and use the issue tracker if you run into problems.
Working with FreedomSponsors
The bug tickets that are financially sponsored will have the FreedomSponsors label, and a link to their page on FS. There, to get paid, you have to add yourself as a worker, and mark it as complete when you’re done. It’s really simple and straightforward.
Making no assumptions about priority, which can add a “bonus” to the price:
- Easy bugs pay $10-20
- Medium complexity pays $50
- Hard bugs pay $100+
Hard bugs are going to be primarily architectural for awhile, so don’t expect any of those to crop up as sponsored, I try to do that sorta stuff myself so there’s no surprises, or serious time investments in a development path that I’m just gonna not like at the end of it. That would be as much a waste of your time as mine. I’d much rather sponsor bugs where I think everyone will feel like things were fair by the end of it, with clearly defined expectations.