Beyond the Code
or, how to win friends, influence people and make a living by writing open source software. It's not just about the code.
Follow me on Twitter as @jonobennett.
Wednesday 29 April 2009, 12:05 PM
Wired blogs switch to open source
Matt Mullenweg, the creator of the open source blogging platform WordPress, has announced in his blog that Wired.com has switched from using TypePad to WordPress for its blogs.
TypePad has lots of great features, and many people are happy using the service, but there's also a reason why WordPress has become so successful, and it's choice. You can install it on just about any web hosting account, virtual server or your own servers and get exactly the same features. You can add new features yourself by downloading add-ons or coding them yourself. You can change every last detail of your blog's design whenever you like.
When your brand is as big as Wired's you need to protect it, and that means having control. An open source platform always offers that, and a service like TypePad, no matter how good, can't offer that level of freedom.
TypePad has lots of great features, and many people are happy using the service, but there's also a reason why WordPress has become so successful, and it's choice. You can install it on just about any web hosting account, virtual server or your own servers and get exactly the same features. You can add new features yourself by downloading add-ons or coding them yourself. You can change every last detail of your blog's design whenever you like.
When your brand is as big as Wired's you need to protect it, and that means having control. An open source platform always offers that, and a service like TypePad, no matter how good, can't offer that level of freedom.
Friday 24 April 2009, 1:36 PM
Open source coders aren't lazy enough
My enthusiasm for open source software partly stems from the times I've spent as a coder, where being able to reuse code for a particular task made my life much easier. Free licensing of code makes this easier across a wider group of developers — choose the right licence, and anyone in the world can share with you.
When I learned Perl, way back when that was what you wrote web applications in — forgive me if I'm showing my age — I learned the "three virtues" of a programmer from the Camel Book: Laziness, Impatience and Hubris. The laziness talked about there was that of using a small amount of extra time when creating code to save yourself lots of time later: Document your code so you don't have to answer the same question about it over and over and over. It's a fantastic principle, and it needs more application by everyone.
I arrived at one such programming job to find that they had written their own HTTP user agent in Perl. There weren't any noticeable bugs in this implementation, but it has taken time to write and didn't have anything like the level of functionality of the LWP module, widely used to do the same job and easily downloadable from CPAN. There were other examples of where other code could have been reused, but there wasn't a culture of finding source code to reuse at the company — the attitude to open source was that you used the finished product — object code — but wrote any new code you needed yourself.
Sharing code is a natural and useful activity for developers, whether that's just amongst coders at one organisation, or with every other user of the language you're writing in. While making sure you share your code is generous, and an important part of the system, you should make use of the other side of the bargain — the ability to use code others have shared with you. The principle of enough eyeballs making all bugs shallow only works if all the eyeballs are looking at the same piece of code.
It's disheartening therefore to see lots of open source projects being started that are very similar to lots of existing projects. Read through a site like Freshmeat and you'll see lots of very useful projects like software build tools, project management systems, network utilities, all of which vary from similar projects in functionality by a few per cent. The user interface may be different, but what the code does will be incredibly similar. The real problem with this is that each codebase will have its own set of bugs, and if a problem is fixed in one, it won't get fixed in the other. This isn't making the best of what open source has to offer coders or users.
My message to open source coders is this: Get lazier. When starting to write code, you should always assume someone else has written it first, all you have to do is find where. Invest that extra time looking for it, and you may save yourself far more time in writing, debugging and maintaining it later.
When I learned Perl, way back when that was what you wrote web applications in — forgive me if I'm showing my age — I learned the "three virtues" of a programmer from the Camel Book: Laziness, Impatience and Hubris. The laziness talked about there was that of using a small amount of extra time when creating code to save yourself lots of time later: Document your code so you don't have to answer the same question about it over and over and over. It's a fantastic principle, and it needs more application by everyone.
I arrived at one such programming job to find that they had written their own HTTP user agent in Perl. There weren't any noticeable bugs in this implementation, but it has taken time to write and didn't have anything like the level of functionality of the LWP module, widely used to do the same job and easily downloadable from CPAN. There were other examples of where other code could have been reused, but there wasn't a culture of finding source code to reuse at the company — the attitude to open source was that you used the finished product — object code — but wrote any new code you needed yourself.
Sharing code is a natural and useful activity for developers, whether that's just amongst coders at one organisation, or with every other user of the language you're writing in. While making sure you share your code is generous, and an important part of the system, you should make use of the other side of the bargain — the ability to use code others have shared with you. The principle of enough eyeballs making all bugs shallow only works if all the eyeballs are looking at the same piece of code.
It's disheartening therefore to see lots of open source projects being started that are very similar to lots of existing projects. Read through a site like Freshmeat and you'll see lots of very useful projects like software build tools, project management systems, network utilities, all of which vary from similar projects in functionality by a few per cent. The user interface may be different, but what the code does will be incredibly similar. The real problem with this is that each codebase will have its own set of bugs, and if a problem is fixed in one, it won't get fixed in the other. This isn't making the best of what open source has to offer coders or users.
My message to open source coders is this: Get lazier. When starting to write code, you should always assume someone else has written it first, all you have to do is find where. Invest that extra time looking for it, and you may save yourself far more time in writing, debugging and maintaining it later.
Wednesday 22 April 2009, 1:50 PM
Is Java's future Cloudy?
Cloud computing has its problems — hype being one of the biggest. Poorly defined and different interpretations of what "cloud computing" actually means aren't helping matters, but if you're one of the people at the coal face — developers having to produce applications that run on a cloud service — your biggest problem is a complete lack of consistency in application programming interfaces.
Having to cope with multiple APIs isn't a new problem in programming ("the wonderful thing about standards is that there's so many to choose from"), so it has already occurred to some people that it needs addressing for cloud computing sooner rather than later. The Java community in particular is eager to get things fixed.
Sun Microsystems' open source czar, Simon Phipps, raised the issue in his blog, prompted in part by Google adding Java support to AppEngine, but also by his experiences in the early days of Java. Back then, standardising Java Standard Edition and Java Enterprise Edition helped developers be sure of what APIs they could expect to be available on which platforms. In those days, Java wasn't open source and Sun wasn't in the process of being acquired by a company whose open source credentials are in doubt, so if that standardisation was important then, it's doubly important now.
There is some concern about the how the process of standardisation will be handled, though. Geir Magnusson of the Apache Software Foundation has commented that the ASF's own efforts to produce a free Java implementation under a different licence to the GPL haven't been helped by the Java Community Process. Magnusson also believes it may be too early for cloud computing to standardise, but is willing to give it a go based on more than one implementation of a Java-based cloud service.
I don't think a new, Oracle-owned Sun should lead the process of creating Java Cloud Edition if it wants the standard to have credibility and acceptance. Developers are going to be wary of the new entity at first, particularly if Oracle is seen to be backing away from Sun's previous wholehearted commitment to open source. Having Google or the ASF lead the project would be a great way to revive interest in the JCP, and a good indication that Sun's new owners aren't going to undo several years of hard work gaining developers' trust.
Having to cope with multiple APIs isn't a new problem in programming ("the wonderful thing about standards is that there's so many to choose from"), so it has already occurred to some people that it needs addressing for cloud computing sooner rather than later. The Java community in particular is eager to get things fixed.
Sun Microsystems' open source czar, Simon Phipps, raised the issue in his blog, prompted in part by Google adding Java support to AppEngine, but also by his experiences in the early days of Java. Back then, standardising Java Standard Edition and Java Enterprise Edition helped developers be sure of what APIs they could expect to be available on which platforms. In those days, Java wasn't open source and Sun wasn't in the process of being acquired by a company whose open source credentials are in doubt, so if that standardisation was important then, it's doubly important now.
There is some concern about the how the process of standardisation will be handled, though. Geir Magnusson of the Apache Software Foundation has commented that the ASF's own efforts to produce a free Java implementation under a different licence to the GPL haven't been helped by the Java Community Process. Magnusson also believes it may be too early for cloud computing to standardise, but is willing to give it a go based on more than one implementation of a Java-based cloud service.
I don't think a new, Oracle-owned Sun should lead the process of creating Java Cloud Edition if it wants the standard to have credibility and acceptance. Developers are going to be wary of the new entity at first, particularly if Oracle is seen to be backing away from Sun's previous wholehearted commitment to open source. Having Google or the ASF lead the project would be a great way to revive interest in the JCP, and a good indication that Sun's new owners aren't going to undo several years of hard work gaining developers' trust.
Friday 17 April 2009, 7:34 PM
Open source in government, and where to start
There's a growing movement pushing for governments to use and produce more open source software. Incidents like the NHS's National Programme for IT and Becta's software procurement procedures have done little for the public sector's reputation in IT projects in the UK. Open source advocates see the development and use of free and open source software within government as one of the solutions to this problem, but then, as Mandy Rice-Davies had it "they would, wouldn't they?".
As it happens, open source is a good choice for public sector software on technical, financial and philosophical levels. The zero acquisition cost and lack of per-seat licensing must surely appeal to cash-strapped councils and central government departments. After all, the French police has saved millions by migrating to Ubuntu-based desktops. However, that's only looking at one relatively small advantage, and doesn't address the issue of project failures.
Aside from costs and licensing, one thing that software development in government could take from open source is its development model. Part of the waste of public sector IT is the duplication it produces. Across the hundreds of county and district councils and unitary authorities there must be an even greater number of software projects, all with largely similar aims and objectives, even if the approaches are different. Even if the developers working on those projects — who may be contractors and not government employees — choose not to collaborate directly on software, being able to see the structure of each other's projects would be a first stepping stone on the way to interoperability.
I'll discuss the benefits of open source licensing for public sector software in a future blog post, but even if a council or government department is wary of opening up its code as is, they could do far worse than have an open source-style forge, open only to government employees and contractors. Electronic delivery of government services is already here, but the more uniform the interfaces — programming or user — are to those services, the better use citizens (that's us) will be able to make of them.
As it happens, open source is a good choice for public sector software on technical, financial and philosophical levels. The zero acquisition cost and lack of per-seat licensing must surely appeal to cash-strapped councils and central government departments. After all, the French police has saved millions by migrating to Ubuntu-based desktops. However, that's only looking at one relatively small advantage, and doesn't address the issue of project failures.
Aside from costs and licensing, one thing that software development in government could take from open source is its development model. Part of the waste of public sector IT is the duplication it produces. Across the hundreds of county and district councils and unitary authorities there must be an even greater number of software projects, all with largely similar aims and objectives, even if the approaches are different. Even if the developers working on those projects — who may be contractors and not government employees — choose not to collaborate directly on software, being able to see the structure of each other's projects would be a first stepping stone on the way to interoperability.
I'll discuss the benefits of open source licensing for public sector software in a future blog post, but even if a council or government department is wary of opening up its code as is, they could do far worse than have an open source-style forge, open only to government employees and contractors. Electronic delivery of government services is already here, but the more uniform the interfaces — programming or user — are to those services, the better use citizens (that's us) will be able to make of them.
Tuesday 14 April 2009, 3:31 PM
The downturn - good for open source, not so good for coders
There doesn't seem to be any doubt that we're still not past the worst of the economic downturn. There are tech companies announcing job cuts everywhere. Some industry commentators have already suggested that developers finding themselves out of work during this time should start contributing to free and open source software projects while they're out of work.
On the face of it, that's a very good idea. It shows to any future employer that you've been keeping your skills up to scratch, and the evidence is publicly accessible — unlike the evidence for most claims made on CVs. One sticking point is that the projects coders tend to do in their spare time are ones that scratch a personal itch, rather than ones that solve a particular business problem. Adding a new module to an open source media centre project may not seem like good experience for creating CRM systems to someone who isn't able to read the code themselves.
Even with an enlightened, knowledgable hiring manager who can see the value of contributions to an open source project, this only increases your chances of getting a job if companies are looking for people with open source experience, and they'll only do that if they're planning large-scale use — and modification of — open source systems.
You can read a lot, both here on ZDNet.co.uk and elsewhere, about how people believe the downturn will be good for open source, often based on its zero acquisition cost. However, this also implies that companies are looking to save money, and hiring developers may be way down the list.
Open source is certainly better value for money longer term, and costs nothing to obtain, but I doubt if the benefits to businesses are going to be much help to coders in the short term. When the upturn comes, that may be a different matter, but if you're going to take advantage of low acquisition costs, the last thing you're then going to do is hire coders.
On the face of it, that's a very good idea. It shows to any future employer that you've been keeping your skills up to scratch, and the evidence is publicly accessible — unlike the evidence for most claims made on CVs. One sticking point is that the projects coders tend to do in their spare time are ones that scratch a personal itch, rather than ones that solve a particular business problem. Adding a new module to an open source media centre project may not seem like good experience for creating CRM systems to someone who isn't able to read the code themselves.
Even with an enlightened, knowledgable hiring manager who can see the value of contributions to an open source project, this only increases your chances of getting a job if companies are looking for people with open source experience, and they'll only do that if they're planning large-scale use — and modification of — open source systems.
You can read a lot, both here on ZDNet.co.uk and elsewhere, about how people believe the downturn will be good for open source, often based on its zero acquisition cost. However, this also implies that companies are looking to save money, and hiring developers may be way down the list.
Open source is certainly better value for money longer term, and costs nothing to obtain, but I doubt if the benefits to businesses are going to be much help to coders in the short term. When the upturn comes, that may be a different matter, but if you're going to take advantage of low acquisition costs, the last thing you're then going to do is hire coders.
Previous
