Software Research and the Industry
Dirk Riehle's blog on everything computer science and more
Last week the German government published a commissioned study on how it depends on software and services vendors (local copy). The day after the publication, Cathrin Schaer of ZDnet called to ask for my thoughts on the study and digital sovereignty for Germany: Is it even possible? Cathrin’s resulting article picked up some of our discussion, but I wanted to take the time here to elaborate on my thoughts.
Continue reading “Digital Sovereignty for Germany?”
I’m at my Ph.D. student retreat, following the Open Core Summit, a commercial conference on the use of open source strategies by product vendors, on Twitter. From afar, it appears that the attack on the definition of open source has made it to the conference. This is regrettable, but possible because of a root problem with the open source definition as defined by the Open Source Initiative (OSI): It is about the licenses only. Only on the side, in the open source initiative’s mission statement does it say something about process:
Continue reading “The Missed Opportunity in Defining Open Source #OpenCoreSummit”
In software engineering, the structure of research theses, most notably dissertations, is straightforward: (1) Formulate a research question, choose a method, build a theory, then (2) generate at least one interesting hypothesis, choose a method, and test the hypothesis as part of the theory’s attempted validation. A dissertation can do both parts 1 and 2 or just one of them, relying on or leaving stuff to others. The benefit of this structure is that it will be easily recognized by other researchers and make it eas(ier) to write great papers.
Continue reading “How Not to Ask Your Research Question (And What to do About it)”
On a whim, I asked my Twitterverse (which includes a fair number of computer scientists) what they think about the following question:
Continue reading “Anecdotal Evidence on the Method Wars”When peer-reviewing somebody else’s work submitted for publication, what should you do if you find that the authors have a different belief than you about what can be known?
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”
A professor, so my belief, can play an important role in generating startups from University research. Most professors don’t, but some do, and I wanted to summarize my experiences as to what would be the perfect combination in one person.
There are three ingredients to get a university startup set-up and off the ground: (1) team, (2) idea, and (3) seed funding. Team, as anyone in startup-land knows, is by far the most important ingredient, as the others ultimately follow from it.
Continue reading “The Perfect Professor for University Startups”
I thought I’d illustrate how I’d solve the current licensing conundrum of single-vendor open source firms like MongoDB and Elastic using some graphics. In short: While open source application vendors can still dual-license, open source component vendors (like the companies just mentioned) need to triple-license to get the benefits of open source yet keep their competitors at bay.
Continue reading “Triple-Licensing Single-Vendor Open Source Components (Illustrated)”
On a lighter note, someone with a similar name to mine just used one of my email addresses to register for the Lexus Remote app. Judging by the email I got, using this email address that I own, I can register for the app and presumably do something about the car behind it. Does Lexus already offer a “summon” feature? Seems like the car is based in the U.S. so it would be good if it was amphibious.
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)”
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”