By Judy Puritt
Recently, at the full day Drupal Camp session held at the University of Ottawa, I had the chance to sit down with Jose de Leon and Jason Berry over lunch to chat about ‘open source’ and the implications of this approach to software for major projects. Almost immediately, I was reminded of Einstein’s quote, “The only reason for time is so that everything doesn’t happen at once.” Indeed, both Jose and Jason ooze enthusiasm when it comes to talking about code and the concept of programming, and neither one is hung up on issues related to time. Below, they share some insights on open source, documentation, patches, and philosophy.
Jose, you are a huge open source advocate. When you joined Askari, how did you hope to impact and influence the company philosophy?
Jose de Leon: Well for starters, open source is a fact of life for technology today. It is sort of the mechanism by which open data (as recently discussed by Dominique in her Open Data discussion) is processed. The open source community is truly built on collaboration. In my mentoring experiences teaching high school students the ‘other’ part of software development (through the ONFE/TechU.me program), the part not covered in formal classroom lessons, I hope to put across this notion of how pervasive open source is. In that spirit, I encourage new users to set up a Github account as soon as possible; not only does that give them a sandbox for playing, it shows potential employers your coding ability.
And, Jason, what has been your experience and thoughts with the open source community?
Jason Berry: Oh, it’s been great. Jose definitely has been a super mentor. He encouraged me to become more active on Github, and I’ve found the process learning about version or source control particularly useful. It lets you develop side projects, and the whole time you are encouraged to document so that others trying to use your code piece or replicate your scenario know the relevant details.
Okay, that sounds exciting… and potentially very risky?
JDL: For sure! Imagine building a house: you know you want a deck, but you’re not sure about the final parameters. Well, in source control you can safely experiment and trial different elements and approaches. If one of the experiments is successful, you can merge it to the main system. The safety of designing in isolation is useful, and encouraged by the community. Sharing in a structured manner is very important. Thinking back to the deck example: if I draw up a plan for a deck based on my experience of building a simple one at a past house, and then show it to my friend who has built decks, there’s room for constructive and informed discussion. The collaborative nature of the open source environment allows inclusion for oversight and there is a strong guideline that new patches should not crash systems.
JB: Yes! Using open source has definitely expanded my skill set in figuring out how to plan. I realize how important it is to know what I want as the end outcome and how it needs to fit within the existing structure. Documenting as you go along is critical to recording and tracking where and why something behaves in a certain way, but none of it is helpful if you don’t know where you want to end up.
So this sounds as if open source software is entirely reactive?
JDL: No, that’s not the case. The shared nature of the documentation encourages participants/developers to document not just the WHAT they’re changing but to explain the WHY they’re changing something. A good part of the success behind the open source movement is documentation. Now, it’s not that developers in open source like to document any more than those working in proprietary software, but rather the open nature of the community – the collaborative nature of working with others – results in a more comprehensive documentation process. So, getting back to the proactive or reactive nature of patch development, when developers share their findings in this community, other developers experiencing similar conditions can jump in and share their insights. You are constantly documenting, bringing in pieces of code, and sharing your experience with others.
Interesting. Let’s go back to the patch business. How does patching make economic or business sense?
JB: The discussion forums are fairly normalized. It’s not just a random posting of problems you’re facing, say in Drupal. If you’re facing the challenge so are others. In that sense, again it’s really clear how collaborative and open the community is. We’re keen on what we do and we enjoy sharing that excitement with others.
JDL: Absolutely. You realize quickly it’s about people working with software, rather than software directing how people work. The model of open source is NOT that the product is code, but rather that the product is the service you’re selling related to code. Your expertise is what’s important. The openness in the community is such that talented coders with good insight and working patches quickly rise to the surface.
Well, all in all, the open source community sounds very exciting and you are both strong advocates – why?
JDL: Oh, that’s easy: I think coding is a creative outlet! Part of it is, coding expresses who I am. Getting involved with open source was not only a good career move, but a good personal move. Historically, I was an advocate for years before joining this Drupal project, contributing documentation and bug reports on other projects. Really, open source fits my personal ethic: 1. it lets me accomplish goals I have, and 2. it lets me prove I can code.
JB: Well, I really hadn’t thought that my role was that significant. Jose has been mentoring me for a while, and certainly his encouragement of me using my Github account more was very important. I really like the overall philosophy I have encountered and experienced in the open source community: anyone who wants to contribute and collaborate is welcome. That kind of inclusiveness is really cool.