There, he said it again, at the Open Source Meets Business conference in Nuremberg, Germany: “We would like to donate this code to the community.” Sounds great, doesn’t it? Well, I’m not so sure. Or, to be frank, I think if somebody talks about donating code to the community they probably don’t understand effective open source.
For your information, the fourth workshop on wikis for (in) software engineering. I’m on the program committee.
CALL FOR PAPERS
Fourth Workshop on “Wikis for Software Engineering”, May 16, 2009, at ICSE 2009, Vancouver, Canada, May 16-24, 2009
Submissions are due on January 26 (abstracts), February 2 (papers), 2009
I’ll be giving a talk at the Open Source Business Conference 2009 in San Francisco on March 24, 2009. The talk will present an easily accessible summary of our data-driven analytical work on how open source software development works. Here is the abstract:
For the first time in the history of software engineering, we can both broadly and deeply analyze the behavior and dynamics of software development projects. This has become possible because of open source, which is publicly developed software. In this presentation, I will discuss our recent findings about open source software, its development process, and programmer behavior. I also discuss the challenges we encountered when quantitatively mining software repositories for such insights.
Reference: Talk at OSBC 2009. San Francisco, CA: 2009.
Available as a PDF file.
Most readers of this blog are probably familiar with Conway’s Law. So named by Fred Brooks in the “Mythical Man-Month” and popularized by the saying “if you have four teams working on a compiler you will get a four-pass compiler.” This sociological observation stipulates that the social architecture of a corporation i.e. its organizational hierarchy determines the technical architecture of its products. My industry experience supports this observation and I made fun of it as early (for me) as 1996.
Now Rodrigo Magalhaes and Antonio Rito Silva of Technical University of Lisbon are expanding this and related observations into a full-blown research area called “organizational design and engineering”. You are invited to submit to and participate in
- the 2009 International Workshop on Organizational Design and Engineering (IWODE ’09) and
- the International Journal of Organisational Design and Engineering (IJODE)
I’ll be helping as member of the IWODE ’09 program committee and as a member of the IJODE editorial board. Please find appended the Call for Papers for IWODE ’09 as a PDF file.
WikiSym 2009 Call for Papers
The International Symposium on Wikis and Open Collaboration
October 25-27, 2009, in Orlando, Florida, USA
The International Symposium on Wikis (WikiSym) is the premier conference dedicated to wikis and related open collaboration systems and processes.
The title of this blog post is my paraphrasing of a “law” from the tongue-in-cheek but nevertheless somewhat serious book “Systemantics” by John Gall. I tracked it down through Grady Booch’s original OOAD book and it had been pointed out to me by Ralph Johnson.
What’s so special about this quote? Well, it frames an inconvenient truth rather nicely: That you can’t create a complex system from scratch. Rather you have to evolve it step-by-step from a simpler system. This clearly runs counter to the intuition of many top-level IT or R&D managers. Thus, the unabated stream of expensive software project failures.
Open source and wikis are great examples of this proverb because of their (typically initially at least) volunteer nature. If they don’t work, they’ll get deserted quickly. If they get deserted, they are dead, and you don’t want that, if you are working on the project. Hence, this mechanism keeps you focused on the value the project or wiki provides to its users.
…is not nearly as sexy a title for an industry talk as is “Open Source Hacker Careers” so it had to go. The result you can observe at the 2009 Open Source Meets Business conference in Nuremberg, Germany, on January 28th, 2009, when I will be giving a talk (almost) so named.
Open Source Software Developer Careers
Open source is changing how software is built and how money is made. Open source also defines a new developer career that is independent of the traditional career within companies. This talk discusses this new career and argues that it creates economic value for some while it makes life harder for others. Suggesting that such a career is worthwhile, the talk then discusses key skills that a developer should possess or train in order to be successful in open source projects.
For your information, a workshop on Collaboration and Knowledge Sharing in Software Development Teams (SofTEAM ’09)
CALL FOR PAPERS
European Workshop on “Collaboration and Knowledge Sharing in Software Development Teams (SofTEAM’09)”
We recently looked at the commenting practice of active working open source projects. It is quite impressive: The average comment density of open source is around 19%. (Comment density is the percentage of text that are comments, or, more formally: comment density = comment lines / (comment lines + source code lines); for example, two lines of text, one a comment line and one a source code line, have a 50% comment density.) A 19% comment density is much more documentation than most people thought!
However, such a rough number needs discussion. Here, we look at the comment density on a programming language basis. As it turns out, the comment density of active open source projects varies by programming language. Not surprisingly, Java is leading the bunch.
The growth and corporate adoption of many community open source projects is hindered by the lack of commercial support. At the same time, well working community open source is a temptation for startups to make a buck by turning the community project into commercial open source. We can currently observe the unraveling of such a story.
TWiki is a community open source project, a successful wiki engine, and the company TWIKI.NET is trying to turn it into a commercial open source project. This post discusses some of the levers and dynamics of this process. But first, to clarify terms: Community open source is open source owned by a community with no single dominant stakeholder, and commercial open source is open source owned or dominated by a single legal entity, typically a software firm that wants earn money with it.