Developer Forced To Stop Development on Mercurial due to BitKeeper License

Ben Collins-Sussman pointed to this blog entry written by a developer on the Mercurial Distributed Version Control System which talks about Larry McVoy contacting his employer about his work on the project. His employer is a licensed user of the BitKeeper software.

I think its sad that an employee of a customer of a software company, with no access to the tools source code, can be told to stop developing open source software because of his use of another software application.

Think about this a minute. Before OpenOffice was useable, what if each developer who had to use Microsoft Word at work was forced to stop working on the software because of their use of the Microsoft products at work?

Much of what is going on in the Bitkeeper world right now was the main reason why there was such an uproar over the licensing of the product when Linus Torvalds started using it to manage the Linux kernel. Looks like the community was right again.

On another note, however, I’m definitely going to take a look at Mercurial. It looks like an interesting piece of software. I think its a travesty that its lost one of its developers due to the decision of his employer on what software package to license.

The full discussion on this can be found on the Subversion Developers mailing list.

Will The Build Bottleneck Put The Brakes On Agile?

There is a great article in the SD Times called Will The Build Bottleneck Put The Brakes On Agile? which talks about the use of both version control and an automated build process in which to receive feedback on the “health of the software” more frequently.

Our group has used Open Source products for this kind of thing for a few years (I think we started using CruiseControl at version 1.0, as Keith and I tend to be those “high risk”, early adopter types) with excellent results. The ability to have the software you are developing automatically build from source to deployment packages (we have both the traditional tarballs and ISO images for a Windows product) is an excellent way to remove a ton of unproductive manual labor from your processes and get builds to QA.

One of the great features of this kind of system that isn’t really publicized in the article is the ability, upon build failure, to notify the committers to the current build that a build failure has occurred. This allows a proactive response to these kinds of failures rather than the typical “one guy watches the build and hunts down the guy who broke it” process that most companies normally go through when one person handles build duties.

The other nice thing about this? It makes it really easy to rotate “buildmaster” duties throughout the department. In our case, we built a system around the open source tools in order to help people manage the build, and utilized functionality in CruiseControl like the JMX interface in order to allow people to kick builds without having physical access to the server. This allows us to control what is going on with the server, but still allow anyone with sufficient role based permissions to access the system in order to manage the day to day activities around a build.

We have also implemented CodeStriker, an online code review tool in order to try and keep people out of meeting rooms and give them the ability to comment on source code at the line level, per project, from wherever they happen to be at the time. This has been another really great addition to our process and has reduced the amount of paper each person had to fill out during a code review. We now have documentation of all items raised during the reviews, who raised them, and what the status is of each. The tool also provides full integration with CVS and Subversion.

I’m glad an article like this has come out. These sorts of automated processes need to become the norm in order for IT to be able to get out of the rut it has been in for the last few years in which the manual effort required to produce a software release prevents it from delivering on the things the business needs. Read it. Think about it. Then give it a try.

Here’s some software resources to get you started:

Keith, did I leave anything out?

IBM Backs PHP Programming Language

I found an article hidden away on slashdot talking about how IBM has entered into a partnership with Zend Technologies, a leading provider of PHP development tools, in order to "help make PHP work better with corporate databases and web service technologies".

I have used PHP quite a bit over the years both on the work and home fronts. Almost every incarnation of this web site has been written in PHP, including this one (WordPress is written entirely in PHP). At work, I’ve used PHP to help manage data related to development and deployment processes that has been running for over three years with very little modification over the time its been in production. It’s very easy to write pretty solid code in an abbreviated amount of time using PHP.

PHP is a very powerful language, and it is very easy to get a highly interactive web site up very quickly. While I’ve never used the Zend development tools in order to perform any of this development, I’ve had very good experiences with the tool in general and I’m glad to see that it is finally going to get some backing from a pretty large corporate entity.

For one, it does something to validate the tool as valid corporate tool. Secondly, and probably more important to me, it validates the technology choice I made three years ago in order to get solid results as quickly as possible.

This should be a very interesting time for the PHP community. While they’ve had huge support from the Open Source community over the years, I’m interested to see how many companies start finding the PHP language a valid technology due to IBM’s backing.

Related Articles: