Mashing Up The Open Web - Mar 2010

From my personal experience as a developer and project manager for websites and -applications based on existing software and frameworks in the commercial area I approve the point that "Every good work of software starts by scratching a developer´s personal itch". The problem is that in the commercial sector and especially in a company delivering consultancy services, we face different problems on every project, which are not ours.

Often we encounter ourselves with strong opinions about the usefulness of the project and the idea the client has. Motivation for working on the project therefore is purely out of necessity receiving the monthly paycheck. Constraining the available programmers by letting them work on different projects at the same time adds to the frustration. We do the project, because the client pays for it and that is what the company needs to exist.

Not inventing the wheel every time we start a new project, we reuse existing software to build web-based applications and websites. Although this software is open source, we often experience the "not invented here syndrome" which manifests itself in reluctance to tackle certain problems of implementation or fixing bugs in the software itself. Bringing new developers into the company which are not satisfied with the established software used as the foundation of the projects we realise, threatens performance and an successful outcome.
Tight budgets add to the equation a negative factor, making a project to be pure stress and not fun at all.

Therefore I agree with Eric Raymond and the point he made about the advantage of open source over closed source software development.
Thinking about the comment a colleague made to me lately: "What web developers could have achieved elsewhere in the time they tried to fix their sites to display correctly in Internet Explorer 6". My personal opinion: IE6, a closed software program, the foundation of access to the Internet for many years, nearly a decade, would not have made that much problems when it would not have been the child of a huge profit-oriented company which neglected it for long but at the same time spread it aggressively all over the world, strongly integrated in its operating system.

It was interesting to get the connection in the writing of Eric Raymond to the later developments of the methods of Agile/Lean Software Development and Extreme Programming. The origins of "Release Early and Often", "Prototyping" and the "User-centric approach" are found earlier than I expected. But that also leverages the notion that not a lot has changed in the last thirty years, just the packaging became different.

The approach of letting the client early into the project has not been that easy so far from my experience and point of view. Especially when they are not very technology-prone, but have made themselves a clear picture of what they want, they are not able to understand why the prototypes they are presented with are so "rough", "incomplete" or "not as in the Photoshop".
Therefore it often seems better to exclude the client from the implementation phase after he has accepted and signed a design proposal. But for now I have chosen the path of educating the clients and marketing the possibilities the open and transparent approach has, fighting with the constraints fixed-price contracts apply to me.

Finally, what I see nowadays in companies using open source software and selling its configuration and deployment as a service: if they do not employ programmers who are engaged with the software itself and the company does not contribute feedback, bug fixes or features back to the software, they do not understand or grasp the concept of open source. Additionally, they will fail as a company.