AgileVale 2013 - open source?
Last friday I’ve had the opportunity of speaking at AgileVale 2013, an agile development methodologies and software engineering regional conference. You can find some nice photos here. I’d like to thank Robson for the invitation!
I really love this conference because the organizers have a long track record of doing community events right. Btw, don’t miss RuPy 2013, last year was awesome and this year is promising to be even more awesomesauce :)
So this talk was special to me because I committed myself on doing this talk without a slide deck. As you can probably guess, I was ultra nervous, but it was a good exercise.
Here I’m posting my full talk notes, which might give you a better idea of what I wanted to communicate.
I’d love to get feedback on it, so feel free to bug me on twitter!
The open source topic is kinda contentious, as people usually relate it to volunteer work.
But it is volunteer work.
Why on earth someone would do something for free?
People only realize the value after they have done some sort of volunteer work.
The reward always comes after you run that 10K.
But how investing your time can be something to care for?
You can learn a lot about team dynamics by getting involved in an open source project.
thick skin, eh?
I’d like to tell you a story, about an open source project that was trying to be agile - after all agile is cool, eh?
We went with a scrum-like model, defined the backlog, defined the sprints and BAM!
Nothing happened. Why?
Open Source is done on the person’s own time, which means there’s no boss telling you what to do besides yourself.
ANY methodology would kill the organic nature of what we do in our leisure time.
Do you actually live in sprints? Do you use burn-down charts for keeping track of your college assignments? (Keep in mind that burn down charts might appear when you realize your salary is over and there’s still 20 days in the month :P)
That brings us to the obsessed crowd complaining that nowadays the market just got cold and insensitive, reducing people as numbers on a big behaviors-based spreadsheet.
Everything is about conversion goals.
A wise friend once said:
optimize for happiness.
Open source projects are successful because people already want to play, you don’t need to convince/coerce them on it. If I’m stuck at a debug session, I can just say screw it and go playing some StarCraft 2 with my son.
No one is forcing me to meet some artificial deadline made by someone potentially wearing a suit. (Nothing against suits, ok?)
What happens when people already have the inner drive and try to create something together?
So, what about dropping the process altogether, and just letting it flow?
The true Open Source Development Methodology is called Chaos
Every time you apply unreasonable external constraints on a contributor you’re robbing their personal time!
Have you ever talked to someone who kept fiddling with their smartphone? Know that feeling of wasting time?
Every time when you facilitate that contribution to happen, walk another mile teaching a contributor on how to deliver quality patches, you’re actually saying that you value their time, by giving your own time to them.
Time is more precious than gold. And this is exactly why people get so emotional when doing open source.
the reality check
Talking about emotions, did I mention that we’re human?
Being human beings implies that our emotions play a huge deal into what we are able to create.
But how this all applies to our day to day activities? We still have bosses, stupid deadlines, etc.
The reality is that if everything fails, you still can make a good outcome of it by learning from your mistakes.
There are valuable lessons to be learned from a typical open source project flow.
It’s all about TACOs
When you approach an open source project wanting to contribute, no one trusts you. This might sound harsh, but that’s the reality. You have to prove yourself.
But I’m a n00b!
The reality is that I as a project maintainer love when a n00b committed to invest time and learn approaches my projects. And people who learn how to do open source tend to stick around and pass it forward.
We love SCMs like git, don’t we? I remember my reaction when I learned the
blame command for the first time :)
This might scare some people, but in general terms everything you do is forever. And this is awesome!
The fact that nearly 100% of the communication happens though written medium makes it really easy to spawn fights. (who has never been involved into a flame?)
At the same time, you learn and reap the benefits of having a true async communication.
Building software is kinda like art. You need to find the right mindset to do it, and it usually doesn’t happen just because someone told you to do it. Since you own the time, you decide when you’re into the right mood. (and with this we avoid several wars)
It’s nearly impossible for someone to steal your credit (that still happens sometimes, but it’s kinda rare)
Consider the Hudson/Jenkins thing: Oracle complained about the name, the community just moved to Jenkins ;)
Even with a critical project like MySQL the community ended up moving to MariaDB.
Another wise friend says:
The one who does the code has the say
- Time is the most precious asset - value it.
- Remember that there are people on the other end of your favorite online communication medium.
- Avoid negativity
- eat more TACOs :)