Why Jenkins is better off as an independent organization

One thing that has definitely moved me this year is the development around Jenkins / Hudson. I never even used either (although I am quite sure that I will during the 20 years of my remaining professional live), so I cannot even tell why it was moving me, but I definitely followed with real concern. May be, that it was due to the well known persons that are involved, including Kohsuke Kawaguchi (the guy who drove JAXB 2) as well as the founders of Sonatypehttp://www.blogger.com/img/blank.gif, Tasktop, and Cloudbees. May be that it was caused by the front built between the opponents, consisting of an open source community and Oracle, a corporation that nowadays enjoys much more weight than it requires. Whatever.

One point that definitely interested me has been whether the respective projects would join a larger organization or not. As it currently looks, Jenkins has decided to stay independently and not join, for example, Apache. OTOH, Hudson will be moved to Eclipse. My expectation is that Jenkins will be better off with it's decision.

It's not that I'd vote against big organizations in general. For example, I believe that Subversion's move to Apache has been
a good choice. In that case, the benefits of having a big daddy will outweigh the disadvantages like the need to following certain policies that are largely driven by a bigger community and close-to-corporate culture. I haven't got any personal experiences with Eclipse, but I'd expect that both the benefits and the weak points will be comparable for Hudson.

From my point of view, the power of Hudson/Jenkins is the unusual multitude of plugins. Name any source control or build system, programming language, repository or CMS: Chances are excellent that you'll find one or even more plugins that support it. This is most likely due to the architecture, most likely borrowed from Eclipse, which has had a phenomenal success in this regard. Consequently, the more attractive Hudson or Jenkins can be for plugin developers, the more successful they will be.

But fine grained access rights, tight control over legal aspects of code that enters and well defined policies aren't exactly what a bunch of completely different plugin developers requires. In contrary, the lower the hurdles are for adding a new plugin or publishing a new plugin release, the more attractive.

I can very well imagine that Sonatype, in particular, will do an excellent Job in driving Hudson at Eclipse. They have demonstrated their exceptional abilities with Maven, Tycho, or Nexus. In the medium term, I'd expect Hudson to be more visually attractive, perhaps easier to use and possibly will have a cleaner and mroe agile core. (That's some things they are doing really well.) But they won't be able to create and maintain plugins for just everything. My guess is that Jenkins will take the lead in terms of extension points (that's the part of the core that's driven by plugin developers), number of plugins and hence applicability in different situations. May very well be that Hudson can be the bigger commercial success, but Jenkin's big enough to counter.

Whatever the outcome, it will be interesting to follow. :-)

Standing on the shoulders of giants

In building our homegrown basic, we borrowed bits and pieces of our design from previous versions, a long-standing software tradition. Languages evolve; ideas blend together; in computer technology, we all stand on others’ shoulders.

Paul Allen, Microsoft co-founder, in Microsoft's Odd Couple, 2011

Paul Allen is also the owner of Interval Licensing, LLC, a company that is currently accusing AOL, Apple, eBay, Facebook, Google, Netflix, Office Depot, OfficeMax, Staples, Yahoo!, and YouTube (but not Microsoft) for violation of four almost ridiculous patents.

How to develop a project

I don't know how others do this, but having just experienced this for the n-th time in another different company (it feels the same in all big companies), it seems to deserve some notes.

In my experience, project development typically works like this:

1. A general target is set. ("Wouldn't it be cool, if we could do this and that automatically? Currently it involves a manual process, which goes over weeks. It could save a lot of work and we'd possibly have it done in minutes, or at least days?") The target is agreed upon, a sponsor is found who agrees to spend some money.


2. A project team is built. The project team usually involves a project manager, business people from all affected departments, including operations (which will usually have nothing to do with the thing until and possibly even after the first months of productive use). Finally, there are the people who will actually be writing the documents on requirements, architecture, and whatever else seems to be required. Let's call them the consultants.
3. The consultants are usually very clever people, or at least some of them are. In most cases there even is at least one so-called "software architect". As the term indicates, consultants are rarely internal staff. And if they are, they are rarely bound to a particular department, but hopping from project to project. Very cleaver people are rare and sought after everywhere. The sooner they can start a new project, the better. OTOH, this means that they don't have a deep knowledge of the business topics involved. In other words, a lot of discussion between the consultants and the business people will be required. The consultants have to learn to translate the different languages of the business people into their own terms and, not less important, they must translate their own terms back into a language that the business people understand. (The last 2 years, I have been working in a project, where the word "order" has at least 4 completely different technical and semantical meanings, depending on the context.)


4. The specification evolves over time. Initially, it was expected that fixing the specification (including agreement from all affected departments) will take 6 months and another 6 months was expected for implementation. That means go-live in one year. Of course, given all the required discussions, changes, additions, and whatever, the specification won't take 6 months, but 9 months, one year, or even more. You're lucky, if the estimated time for implementation remains at 6 months: I've seen it happening that the additional time for specification was cat from the implementation time frame. No problem, because the specs are now so good, thanks to the additional time, that the implementors can save the same amount of time.
5. Finally the specs are done. Let's assume that the estimated amount of work for implementation is 2 man-years. Now we can estimate the time that it takes quite easily: With 4 team members, it will take 6 months. But we don't have time. We'll have 6 team members, hence only 4 months, so we can keep our targets.
   You think, this is funny? Just ask yourself: When did you see it the last time, that one or more additional team members were hired, if the project wasn't on schedule.


6. If we are lucky, the six team members are at least average programmers. It is rare, that a "very clever" one is included. Very clever people are too rare to stay in the implementation teams. They are pulled off to work at presales, as "software architects", or "business consultants". In bad cases, two or three of the team members are clearly below. Either that, or they come from a less technical world (main frame), have been working in a simpler environment for 20 years and are now exposed to a world where you work with 7 servers or worse, including frontend, backend, database, LDAP, and at least three different queues or other external services.
   The team members have "clear assignments". After all, there are business requirements, formal specifications, and whatever you might ask for. But, of course, they are also external staff, or at least members of a different (IT) department. In other words, just as the consultants before, they need to learn and understand the business topics. In theory, you *can* read, understand, and memorize those thousand (or even more) pages of specs. In practice, you are expected to do this while already implementing. At least, I can't remember a projects GANTT diagram, where the first two weeks have been reserved for "reading".
   

In other words, let's face it: In particular in the first weeks, implementors are clearly overstrained. And there is few guidance: The consultants who wrote the specs, or at least most of them, have already been assigned to another project. I can't remember a case, where a specification writer has been part of the implementation team, with the exception of yours truly. Of course, they are available for questions. But the first technical decisions, apart from "we will have those 8 different modules running on 3 servers with application server X and OS Y (all choosen by the big companies inquisitio..., pardon, central IT department, except the third server, where we are forced to use application server, or OS Z)" (Usually written down in a document called "software architecture", together with the promise that the application will scale well, by "simply" using more than one instance of X and Y per server...) are usually made

• at a time where the schedule is already heavily pressing


• by people who haven't yet a deeper understanding of the project


• by people who aren't considered excellent

Take that together with the fact that these first decisions will have heavy impact on the projects future.

Another matter is the teams structure. Ideally, a project would start with one or two, preferably good, programmers who lay the general architecture. In time, other programmers would come in, taking up what's there and with the possibility to learn quick by asking the initial. After some weeks, it would be possible to assign a dedicated field of work to a new programmer: Most API's basically fixed, at least dummy implementations of interfaces to other services, and so on. In other words, an environment where even an under-average programmer has a chance to do good work. Perhaps the specs might even be helpful at that time, because one of the initial programmers can tell you know exactly where to implement the stuff, which API's to use, and so on. The specs have become applicable.

I really wonder, whether things couldn't be different. Suggest the following:

• Let's add one, or even two, very clever consultants to the specification team. Of course, that means that the sponsor's initial costs become bigger.


• The task of the additional people would be two-fold: 75% implementation, 25% following the specs. The latter means that they should participate in the most important meatings, follow the communications via mail, or whatever, and read the documents.


• Implementation means, at this time, to develop something that is as good as possible between a click-dummy, or PoC, and the real target.


• In case of a real implementation, the initial implementors ought to stay
  in the project for at least 6 months.

Of course, the chances are, that a good part of this initial implementation will be thrown away later on. But, I'd bet that a good part of work could be taken over. Not to underestimate the amount of input

• from the technical side (the implementors) on the spec writers and


• from both spec writers and business team on the implementors


• the much greater momentum that the real implementation will have


• the better chance to have a good estimation of the implementations costs and schedule

I believe, it is because they are much closer to my idea of a project when companies like Google, or Apple, can be innovative, and more innovative than others. Doing things is never the same than planning. Most likely, I'll never see that happening...

Join the Microsoft campaign ...

to move off Internet Epxlorer 6! Use Firefox!

Neill Gaiman on copyright and piracy

Good thing to note that one of your favourite authors gets it: http://www.youtube.com/watch?v=0Qkyt1wXNlI

Certificate conversion

Quite a useful tool for conversion between the various certificate/keystore formats: The SSL Converter is a small web interface which allows you to upload a file from your hard drive. The format is usually detected automatically from the file extension. You select the target format and press "Convert Certificate" - that's it!



If you'd like to automate your further conversions, the site is even nice enough to mention the equivalent openssl commands.

Bad news for Oracle

I think this is bad news for Oracle: Groklaw will cover the Oracle-Google litigation on Java patents allegedly violated by Android's Dalvik JVM.

Well deserved. If big companies believe that software patents are a good thing, then only because there is a balance between 'em. Assuming that Oracle is not by itself violating one patent or the other is ridiculous. Now Oracle has annihilated this balance. Just at the same time when they announced to drop OpenSolaris. I think they'll soon learn that Google is not the only opponent they have acquired. A pinprick (Bugzilla's main developer requests dropping Oracle support as a consequence of the patent litigation.) is only a pinprick, but we'll see how many of them will follow.

If I were a Google lawyer, I'd definitely follow Groklaw in the months and possibly years to come: Groklaw's much more than a pinprick.