Welcome to the domain of the Wever and Semb Wever family.
There can be found here the family tree, photos, blog pages, and more.
Semb Wever Family Family Tree
Blogs on Environment
Wednesday, 13. November 2013
Are you an Open Source programmer?
My participation with open source started properly in 2000. At the time i was working for a company that wrote an autocad type desktop application. It was a codebase going back to the seventies and was in a need of a facelift.
Not then, nor now, do i believe in writing code from scratch. Like a style of rugby we have in Australia called "Aussie Rules". If you're ever watched it you would have seen everyone jumping up on each others backs to get higher to catch the ball first. Not even in a greenfields project am i interested in writing code from scratch. I'm interested in who's back i can climb up on to get a head start. Some programmers see existing code as a challenge. I'd rather see existing code as an assert, as an advantage.
At that time, when i looked around for something to make gui development faster, this autocad program had hundreds of wizards, dialogs and screens, what i found was netbeans which had just been open sourced out of the Czech Republic. At the time i was also lucky to be working under some brilliant minds that were positive to such open source involvement. NetBeans, even back then, had a clean architecture to it. All of the GUI and configuration to it was separated from the IDE functionality. So it was easy for me to step in and split the codebase up and use half of it for the autocad type program.
I wasn't the only one with the same ideas ontop of NetBeans at that time, and this initiative lead into what's known today as the NetBeans Platform, and years later when Eclipse started they too did something similar. The initiative also got me elected by popular vote as one of the three members to the netbeans governance board. Enough bragging, that's not the point. It is, if you are passionate about code, not just about writing code, but about others code, then open source isn't a pet project, nor a hobby on the side, but an central part of your craft.
But the passion is only the half story. Being an open source programmer is also about being responsible. Now i mislike the idea of code ownership. This idea that we belong in organisational silos and that code is to be protected has to be an idea now decades out of date. Well there's something i mislike more that the blame game and that's when people quietly hack around faults they find in open source code rather than filing bug reports, or creating simple test cases that reproduce the fault, or even attempting an simple initial fix to the problem. It's not the lack of collaboration that bugs me so much, but the lack of responsibility. A lot of us started programming when the enterprise was primarily using proprietary products that came with guarantees, support, and someone to blame if things went wrong. As we've shifted over to use predominantly open sourced libraries and frameworks in the enterprise i wonder have we still lingering remnants of this old attitude?
Open Source is not a free lunch. There's noone to blame. There's no support. There's no guarantee. When you use open source you're taking code that a bunch of volunteers have written and assuming responsibility over it. In theory you must treat it the same as the code you've written yourself. When you find a fault in the open source part of your stack you can say that you've identified technical debt. When you choose to hack around that fault instead of properly fixing it what you're doing is doubling your technical debt.
To play devil's advocate here one can say that taking this attitude means exploding the lines of code you're involved in, and that in itself adds a huge amount of technical debt. For example your developers could get bogged down in improving low level stuff in the open source layers. There's a healthy amount of truth here. But it's missing the point. No matter what, every code layer in your architecture deserves a lean and result-orientated attitude. And the technical debt isn't represented by the lines of code in total, but by the total entropy of the code. When you pick an open source project there's value in picking a stable project. But when you find a bug you should still fix it properly.
So the boundary you think exists between your company's code and the open source code it is built upon need not be real. Your company is already paying you to maintain a sustainable relationship to technical debt over the code you are responsible for. Is it only your own engagement and ability to communicate across mediums and groups that's holding you back from being the open source programmer you already are?
This was from a lightning talk held at FINN's tech day.
Watch the youtube video of it.