Enabling Open Innovation with Open Data using the JValue Open Data Service

Today I gave my JValue Open Data Service talk at USM (University of Sciences, Malaysia, at Penang). I am grateful for the opportunity and the recording.

Abstract: Open data has the potential to create significant practical value for its users through open innovation. Yet, to realize this value, we need an open ecosystem, next to open data, that allows app developers to create that value. In this talk I present my view of this open ecosystem of open data and how it should be structured. I then present the JValue Open Data Service (ODS), an open source software under development at my research group, that provides a key piece of this ecosystem. The goal of the JValue ODS project is to enable open innovation through app developers.

Continue reading “Enabling Open Innovation with Open Data using the JValue Open Data Service”

Why Self-Enlightened Contribution to Open Source Projects is Difficult

Self-enlightened contributions to open source projects are (code) contributions that come about because a company chooses to contribute. The opposite is forced open sourcing, which typically happens when a reciprocal license like the GPLv2 forces a company to lay open some source code.

Self-enlightened contribution is hard!

Continue reading “Why Self-Enlightened Contribution to Open Source Projects is Difficult”

Do You Need a Macbook to Learn to Code? (Coding vs. Systems Building)

Someone on Twitter asked this question and people loved to weigh in. Most answered: “No, just get an old $200 laptop.” While not wrong, this answer misses the point. Coding, here, apparently means reading and writing code. For that, indeed, any cheap computer will do. However, being able to read and write code does not mean you will be able to build and ship systems, which is what customers pay for.

Continue reading “Do You Need a Macbook to Learn to Code? (Coding vs. Systems Building)”

Why Software Engineering is Not Like Assembly Line Work

The other day I ran into one of the oldest software engineering tropes in the book: That software engineering should be more like work in a factory, and that developers are best equated to assembly line workers who put together a software product by assembling components to a specification. I wasn’t sure whether I should be amused or irritated. In any case, this nonsensical idea has long been debunked by Peter Naur, before it even took roots in later work by others. In Naur’s words, programming is (best viewed as) theory building, and this gets to the heart of the matter.

Continue reading “Why Software Engineering is Not Like Assembly Line Work”

Agile Methods and the Magic Triangle

In software engineering, the magic triangle is a well-known concept to illustrate the relationship between scope, time, and cost of a software development project. Of the three (scope, time, cost), pick two, and the third will magically follow. (It is determined by the other two.) Scope means features (or delivered functionality), time means duration or deadline, and cost typically means number of developers or, more abstractly, available labor.

Continue reading “Agile Methods and the Magic Triangle”

Open Source Expanded (New Column)

Open Source Expanded is the name of a new column (open-ended article series) that I’m editing for IEEE Computer Magazine. Expect a new article on open source and how it is changing the world every two months!

The first article on the innovations of open source was just published, kicking of the column. I could not negotiate an open license, however, all articles will be free to read and download.

Continue reading “Open Source Expanded (New Column)”

CTO vs. VP of Engineering

In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:

Continue reading “CTO vs. VP of Engineering”

Escalating Levels of Complexity in Inner Source Projects

Yesterday, I discussed what makes a good pilot project in inner source. The main thrust of the suggestion was not to start with a big bang but rather to choose a relevant but not too large project. This begs the question of complexity of projects, specifically viewed from an inner source perspective. How should you escalate and grow your ambition for inner source projects? I see a 1 + 3 structure of levels.

Continue reading “Escalating Levels of Complexity in Inner Source Projects”