Corporate Open Source

One concept that is under active discussion for the past decade or so but constantly being misunderstood. Open Source is often taken as a label for software downloaded from the internet, packages free of charge, components under a particular license filed under “Creative”. Often enough it’s misused for lower quality software, which reality has proven wrong by 2017, not to mention the issue with intellectual property.

However, there are many much more aspects to the concept, that add substantial value to any software centrist product organisation. And in times of digitalisation and digital transformation, software will move into the value chain of many organisation that don’t anticipate it yet. Whenever a customer offering is complex and / or service based, transparency and documentation are often key to a satisfactory result and efficient processes.

Open source may not be the one single bullet for any organization, but the concept will help becoming more transparent and efficient.

Single Source of Truth

While SharePoint is a powerful tool with many opportunities to improve processes, many organisations use it to maintain a file server. Which has information about any other effort, therefore creating a large spread between the tangible product and the then theoretical documentation. Not to mention the version horror everybody experienced at least once, trying to ask a few people for the latest version.

Reversing this process through Wiki or even Version Control Repositories allows to keep only one version, that is automatically the latest. Software will take care of all versioning, that would go in filenames_v01_final.docx otherwise.


Adding together the product with documentation allows quick reference, pointing back and forth between customer facing and engineering. While this may sound terrible technical, the nasty guts of any product can still be ignored by those who don’t need to see it. However, for those requiring insight, they don’t have to go through a process to see it. Or even have to talk to a colleague first and ask. Oh, and the colleague will be on vacation anyway.

Opening the product internals will remove any barrier to productive work and allow employees for quick insight. Obviously, some may argue an open repository may lead to uncontrollable product results, but that’s actually a different point. Write access or merge credentials are not required for anybody without responsibility.

Applicable Metrics

To shape it all up, the management world has plenty of nice metrics that can be applied to measure the whole thing. Not all of them express quality by themselves, but applied consciously these can carry a product far.

Documentation Coverage is something that will serve as a great basis for the point I’m trying to make here. With closed projects, or engineering only code, it’s often difficult to understand whether a product, feature or bug is actually just badly documented or the colleague just doesn’t want to help.

With a metric to measure percentage of a product being documented, at a minimum the amount of available documentation can be measured. And with the product internals being transparent, any reader can – at least theoretically – see whether the documentation correctly corresponds.


While being a strong supporter of open source software in general, I’m not trying to make a point for open sourcing anything outside an organisation. However, transparency will help any organisation improve the offering and processes. And the concept of open source will help achieve this transparency. It has a hurdle to overcome, in particular management will have to overcome their fear of software and technology to adopt this concept, but the step is worth taking on the way to digital transformation.


Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.

Celery Worker wide configuration

Celery is a distributed task execution environment for Python. While the emphasis is on distributed in this software, the concept of having workers allows for settings beyond the individual task. While the first rule of optimisation is “don’t”, sharing database connections is a low hanging fruit in most cases. And this can be configured per worker with Celery provided signals. To create a database connection for individual worker instances, leverage these signals to create the connection when the worker starts.

This can be achieved leveraging the worker_process_init signal, and the corresponding worker_process_shutdown signal to clean up when the worker shuts down.

The code should obviously be picked up at worker start, hence the file will be a good location to keep these settings.


from celery.signals import worker_process_init
from celery.signals import worker_process_shutdown

app = Celery('tasks', broker=CELERY_BROKER_URL)
db = None

def init_worker(**kwargs):
  global db
  log.debug('Initializing database connection for worker.')
  db = sqlite3.connect("urls.sqlite")

def shutdown_worker(**kwargs):
  global db
  if db:
    log.debug('Closing database connectionn for worker.')

The example above opens a connection to a sqlite3 database, which in itself has other issues, but is only meant as an example. This connection is established for each individual worker at startup.

Digitalisierung – Die den Code der Welt von morgen schreiben

Welche Verantwortung tragen Softwareentwickler für die gesellschaftlichen Veränderungen, die sie vorantreiben? Die Antwort ist komplexer, als es der Mythos vom Programmierer als Rockstar erscheinen lässt.

Auch die Süddeutsche greift das Thema der moralischen Verantwortung von Programmierern auf. Teil des Problems ist, dass die Profession – der Wahrnehmung des Authors nach jedenfalls – als rein technische Tätigkeit wahrgenommen wird. Vergleichbar des Berufs eines Maurers und weniger der eines Architekten oder Bauingenieurs.

Tatsächlich versetzt die Digitalisierung aber jeden in die Position, mit äusserst abstrahierten Programmiersprachen, die teilweise mehr schon menschlicher Sprache ähneln, einen Beitrag zur weiteren Digitalisierung zu leisten. Webservices oder Chatbots zu programmieren ist mit detaillierten Anleitungen einfach zu erlernen und Schritt für Schritt auch dem Laien nachvollziehbar. Viele der zu Betrieb notwendigen Services sind kostenfrei erhältlich.

Es gibt gewissermaßen keine Einstiegs-Hürde. Weder in der Ausbildung noch finanziell. Diese technische Ermächtigung der Gesellschaft und die Lücke in der Wahrnehmung ist zu einem erheblichen Teil auch der Demographie geschuldet, so finden sich unter Digital Natives kaum über 40-Jährige.  Genauso wie sich unter Konzernlenkern kaum unter 40-Jährige finden.

Und so ist die Tätigkeit des Programmierens nicht länger dem Programmierer – mit einem Diplom von 1995 – vorbehalten, sondern in der Breite der Gesellschaft angekommen. Phänomene wie 4Chan oder Anonymous entstehen aus dieser technischen Möglichkeit, entkoppelt von moralischen Richtlinien. Dort werden Beiträge erzeugt, die tatsächlich ethische und moralische Fragestellungen aufwerfen.

Es werden nicht Regeln von heute sein, die das Zusammenspiel der Gesellschaft in Zukunft regelt, die kommende Generation wird im Internet neue Regeln für den Umgang miteinander finden.

Source: Digitalisierung – Die den Code der Welt von morgen schreiben

The Practical Dev auf Twitter: “Chapter 1: Databases with cool-sounding names”

There is always that one guy in the development department, that knows that one database that’s the coolest|smartest|sexiest technology on planet earth. It scales, has best read and write performance and lowest latency and whatever. For an use case of 2000 rows.

The practical dev nails it:

Update: Apache Cassandra – WAT – Cassandra: Row level consistency #$@&%*!

The code I’m still ashamed of

The following came through my timelines a few days back. A guy feels guilty for what he did – as a programmer – when he was young. Basically he built a promotional website for a questionable medicaments. Apparently the drug has side effects of depression and suicidal thoughts. Only after his sister was prescribed the same medicaments, his conscience made him quit what he was doing.

If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little…

Source: The code I’m still ashamed of

Also, the author writes the following:

As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.

It’s a pretty sure bet everybody long enough in the Internet Business has had moments like this before. For myself, there were a few moments, where I saw an ethical border that I didn’t want to cross. As a student, this was porn. As a professional, it was weapons manufacturers.

Interestingly enough, I even quit two companies for their ambition in IT security. The first pushed datacenter-grade firewalls to small businesses that basically only needed a DSL modem. Through a sales method borrowed from insurance brokers.

The other one at least had a solid technology, but developed a solid sales pitch relying on the same FUD, that crosses that ethical border.

Just like with medication, people shouldn’t buy security out of fear, or any other product for that matter. And any technical person should strive for educating customers and not helping sales people create that fear.

Symantec will Sicherheitsanbieter Lifelock übernehmen

Digitalisierung verlagert vieles Alltägliche ins Internet, und die Unsicherheit um den Umgang mit dieser neuen Situation wird von Sicherheitsfirmen schon lange ausgenutzt. Nun will Symantec offenbar Schutz vor Identitätsdiebstahl anbieten und dazu einen umstrittenen Anbieter übernehmen:

2,3 Milliarden US-Dollar will Symantec zahlen, um sich mit einem Anbieter für Schutz vor Identitätsdiebstahl zu verstärken. Die Firma namens Lifelock musste aber schon zwei Millionenstrafen wegen nicht gehaltener Werbeversprechen zahlen.

via: Symantec will umstrittenen Sicherheitsanbieter Lifelock schlucken | heise online