YC announcement


Digital transparency of customer value, or the truth about software tech investment risks – three examples Google, CloudBees and Docker

We live in a connected world, and a connected world leads to more and more transparency. Transparency means also discovering things which were not obvious.

So, a new fresh insight by Yoav Fisher on startup business and venture capitalists is that venture capitalists (VC) are so to say real estate agents: they sell startups not by value, but just by price. A stunning quotation: “If the foundations of the unit are shoddy, like poor installation or termites, this isn’t part of the pricing — it is left for the future buyer to deal with these undisclosed issues and suffer the negative ramifications on the long term value of their home.”

This is indeed quite interesting also in information technology context if we look at the value of the ICT layer and notions of outsourcing: long-term maintenance and termites bugs are a problem. And, what does mean long term for your company? Therefore SaaS and PaaS are so successful, but also here – how would you know the real value offered by the API service provider – some of them use outsourcing as well, and the responsibility, and also the liability are blurred along a quite lengthy delegation chain.

But, if we come back to transparency, an interesting thing is that many software enterprises build their technology stack today on open source software components – up to 80%, by the way, which raises also the question about USP of virtually any IT consulting company on a $90bn market. What is the business model here – selling workforce time and bill hours (cost), or delivering software (value asset)?

Now let’s have a look at three prominent examples. Let’s say, we pick Google, CloudBees and Docker. The first one is prominent enough without comments, and two others are innovative, even game changing technology leaders for disruptive labor automation for software organizations – both got by the way about up 100m venture capital last years.

Now imagine we would like to invest in these companies. During an according due diligence process, many things are important; as technology specialist I would focus on my part to establish something like a sanity check. This said, the working assumption is that quality of technology matters, if we talk about a tech company.

What could limit value of a software company on the technical side? I think, open bugs in its main software product is one starting point.

So let’s have a look on bugs statistics of Docker and Jenkins and put them in relation with other facts like latest publicly available release, or developer community size. The following table puts it all in one place (as of March 2016).


What do we see?

  • Docker community is about 3 times larger than same around Jenkins, although Jenkins is much older
  • Docker seems to have less bugs
  • Jenkins has weak bug ownership management (almost a hald of serious issues is not assigned)
  • Note: Information about size of the code base is not available in this statistic

The questions arising from this data are:

  • In case the commercial versions are differ from the open source versions and are supreme over them, does this mean,  there is say a Jenkins 2.0 and a Docker 1.5, with a paid team who has managed to fix most, or all of those critical bugs? And how does look the internal statistic then?
  • Or, in case that both versions are same, why should I use commercial versions? Would the paid team fix already known bugs which I, let’s say, personally do not like on my demand (and I probably contribute my time as tester)?
  • What happens exactly with those millions of venture capital? :-)
  • According to Yoav’s considerations in the cited article at the beginning of this article, the VC money does not express the value of these companies, or products; it expresses rather the price tag a VC thinks it could attach later on.

Now, I am really eager to find out how much the investors (well, not only venture capitalists) and also company owners are involved in this sort as discussion and due diligence. Does anybody care – and where to find facts I have probably missed? Of course, maybe I have totally misunderstood what is going on and in this case search to learn it the right way. Please help me!

Now if you are a thoughtful reader, and managed till here, you might ask yourself, “what about Google? Was this guy talking about three examples?”

For you, here comes the bonus. As mentioned above, after all you never know what happens behind the scenes of a shiny SaaS/PaaS company. While having big respect for what Google does, its Google Apps service desk does not seem to work well at least for one example. I ask myself whether there is a single point of truth on such data anywhere and if not, which risks this ignorance, or lack of resources might introduce in other domains. So, there is a quite simple feature request for the presentation app: allow user to disable a slide from presentation. Funny enough, this feature is even there for imported PowerPoint slides, but not by default. This feature request lives for more than 3 years, and has been confirmed by many hundreds of users…. Without any reaction from Google. This is unfortunately an example of epic failure in customer support, despite implemented digital capability. Ownership and strategy will be always key! That’s it, and how much customer dedication is there, becomes transparent and measurable for anybody in the digital age.

240x more dev productivity, or Adam Smith vs full stack developers

Division of labour is the way to more productivity.
In industry, this has been the step from craftmenship to mass production.
How does this compare with full stack developers? The demand for them seems to grow exponentially last years.


However, the full stack itself seems to grow as well. Recently, there is also artificial intelligence – sure the technical guys will build it, too: they are after all the experts. However, saving personal costs on this end might cost your an exponential loss of unleashed productivity because there is no labor division.



Now have a look at the learnings from the 2nd industrial revolution.

“One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.” Adam Smith (1776)

An important difference to a pin factory is however that in software engineering, the productivity between developers can range as 1:10 depending on seniority as quoted by Fred Brooks (“Mythical man month”). Time based billing seems by the way to be rather partly a financially demotivating factor; why should somebody work at speed scaling which cannot be mapped in the salary, or hour rate, if not by a heart commitment?

An argument again building industrial software lines is that this is a loss of creativity, and after all DevOps is for product teams as opposite to project and maintenance teams. However, having interdisciplinary teams does not mean that everybody does same job. And, modern engineers use CAD and sophisticated machines to deliver you electric cars and spaceships – I do not think they consider themselves non-creative.

Devops.com – An Engineering Think Tank to Change the World

We are happy to see our contribution at the global DevOps.com blog! :-)

An Engineering Think Tank to Change the World



DevOps and beyond – a forecast on upcoming generations of software production lines (SPL)


Techniques proven and routine in other engineering
are considered radical innovations
in software engineering.
(Fred Brooks, ‘Mythical Man Month’ (1975) [1]


As the team of the open think tank SIGSPL.org aiming to foster industrial excellence in software delivery methods, we talk to quite many organizations who deal with software delivery. Surprisingly, quite many of these organizations still have to do their homework in terms of lean analysis [2] of their enterprise’s value chain [3]  and digital transformation [4] towards in the meantime broadly known best practices like Continuous Integration [5], Continuous Delivery [6] and DevOps [7] as mission critical core business assets.

But what if we forget the daily struggle bound to technical Change Management [8] and look into our crystal ball? What if today’s systems – which we recognize as software production lines – built around Continuous Delivery and DevOps principles, namely CALMS (Culture, Automation, Lean, Measurement and Sharing) [9], would evolve from one generation to next one, and so forth?

To answer this question, we glance back to what has happened in the software industry in our perception during previous decades, and then proudly present our SIGSPL.org technology forecast on upcoming generations of software production lines (SPL). To illustrate current market dynamics, Figure 1 depictures most prominent software tools and companies as drivers of this development.


Figure 1 – converging trends in software technology (grouped around the generic domains labour automation, analysis and advanced visualization). Source: SIGSPL.org (2016)

For every described period, we consider industrialization trends and advancing technologies in the following generic domains, which we consider to be the pillars of the upcoming SPL paradigm:

  • Labour Automation: new test and simulation approaches, agents, machine learning and artificial intelligence;
  • Analysis: natural language processing and process management;
  • Advanced Visualization: new interfaces and immersive virtual reality technologies.

SPL Level Zero (before 2004)

The time before the raise of the Continuous Integration practice and related tools, the automation of machine code production and delivery was limited to the binary code compiler and some satellite tools. We consider this a time before the 3rd industrial revolution [11] in software engineering industry. Maturity of test automation was quite low, and status reporting of technical teams based mainly on established trust.

SPL Level One (2004-2010):
Continuous Integration era

The industrial concept of supply chain management (SCM) [12] is yet quite new to software engineering domain [13]. One of the clues about mass production in software context is not only increasing variety of software products, but repetitive compilation and composing of complex product’s parts every time the product needs to be delivered, or its change and status tracked internally.

The era of Continuous Integration began with convenient automation tools for the processes described above naturally appearing in bigger teams around bigger products. These tools enabled then an exponential growth of open source code base to millions of standard software components [14]. This period ends for us with the prominent educative books ‘VELOCITY’ [15] and ‘Continuous Delivery’ [8].

SPL Level Two (2010-2018):
DevOps era

In these years, Continuous Integration evolves to Continuous Delivery, and the world starts to buzz about DevOps, reaching also less technical mass media like Forbes [16]. Docker [17] appears on the market and becomes a boom in just one or two years. Lean methods finally penetrate the domain of Information Technology after their first appearance coined as Agile last decade, and some high-end enterprises recognize the necessity of strategic investments to deploy Six Sigma methodology for mission critical software delivery.

From the SPL point of view, Docker can be emphasized as a key organization disruption tool on the delivery end, as it enables standardized virtual integration testing and sharing of integration scenarios, e.g. via so called image bakery [18].

All possible building pieces for industrial software production lines (SPL) are now (as of February 2016) there and well in use [19, 20], what is often missing, is an organized business-driven strategy to put DevOps philosophy tools and related production data spread across many departments in the context of the value chain [21], removing organizational silos. The barrier to a game changing performance and excellence leap already passed by industry leaders like Google and Amazon, is not the technology but lacking management awareness that the hyping Digital Transformation has not yet reached the business processes of departments responsible for the enterprise information technology from research and development to operations – this setting reminds us of crime fiction; guess why.

SPL Level Three (2018-2022):
Post-DevOps era

From here, we start our actual forecast. Let’s imagine, DevOps principles rule the organizations delivering software, and first Software Production Lines are now in operation. How would this world look like?

We think, that while in 2016 Google or Amazon can deploy new features to their operative environments many times a day, we can be quite sure that delivery of new software artifacts e.g. new business functions for enterprise IT will soon touch real time, and this with an increasing technical quality.  Advanced SPL tools will start to support natural language processing (NLP) to enable formal quality assurance for written requirements and specifications as part of the value chain [22]. Standard productivity key performance indicators (KPIs)  for software teams will become  state of the art [23]. Business processes and artifact maps will appear on large interactive dashboards [24] based on captured process relevant Big Data forming the KPIs, maybe in 3D where it will make sense. Figure 2 gives an example of one such visualization, generated by the software analytics tool Seerene.

figure_2Figure 2 – Automated Visual Software Analytics. Source: Döllner/hpi.de (2015)

SPL Level Four (2022-2025):
Digital Value Chain Dominance era

By this time, we can expect that the digital value chain loop will be closed, and mostly any industrial value will find its origin in abstract digital models and software code, these assets cascading towards goods and services perceivable to human beings. For a detailed overview of specific trends, see the World Economic Forum report ‘Deep Shift’. [25]

For software production lines, we expect in this time higher process parallelism and further advance of productivity. Natural language processing (NLP) will experience deep integration to measure and prevent impacts of immature or poor requirements, even to discover ambiguous, or flawed business processes and rule sets. As we assume, this development could become one possible branch of the IBM Watson technology [26]. This approach will lead to deep organizational transformation even before a software project would be anticipated. Advanced machine learning and other artificial intelligence (AI) approaches will serve to optimize product and process quality. We expect by this time also tight integration with Virtual Reality technology, that is, software engineers and testers will operate in virtual environments using fluid complex representations of software assets and related infrastructure [27, 28].
Our expectation is also that further standardization of software components will lead to significant drop in diversity on the software market. Like in many other domains, also specialized commercial SPL cloud services [29] will face the challenge of abundant [30], freely available computational power [31]. Quality measurements and evaluations of prominent software components will become much more transparent towards business users [32] and will benefit from leveraging distributed trust mechanisms like Blockchain [33] in terms of finding common sense across communities; software supply chains and intellectual property business might benefit from smart contract technology [34].

SPL Level Five (2026-2030):
IoT SPL era

While as of 2016 we experience a big hype regarding Internet of Things (IoT), the technologies behind are not in their mature phase yet as we suppose. Technologies behind IoT will become far more advanced within the next decade.  We think that in the SPL domain we have to learn best practices from the mature industry, we assume that the Machine-to-Machine (M2M) [35] and Internet of Things concepts will find their impact in the world of the SPL technology only in the later next decade as the 4th industrial revolution becomes daily reality [36]. In our perception, we talk here about something like the second order IoT, or Internet of Virtual Things [37], as SPL sensors do not digitize physical processes, but furthermore capture already existing digital data relevant for software production. Requirements input interfaces will evolve to interactive NLP powered tools, that is, engineers and domain experts will be able just to talk to computer as peer to induce software specification, modeling and also development in many cases. Industrial software agents [38] could also jump into partially fulfill roles of technical project coordinators and release managers. Quality management will be performed through very advanced simulations and predictive analytics – possibly, using specialized high performance computing (HPC) hardware. VR immersion could advance to augmented VR, that is software teams will find themselves in Holodeck like specialized working environments along with haptics and immersive interactive gamified programming [39].

SPL Level Six (after 2030):
Era of Industry Z

Given the previous rapid pace of digital technology, and as we look back to year 2000, we know that it is almost impossible to predict what could happen until 2030, or whether this amazing development could just stop somewhere.

Therefore, now we aim to describe something so ultimate that further development of SPL technology will remain completely obscure despite of all our imagination strength.

Likewise, in case brain machine interfaces (BMI) [40] become really advanced by 2030, maybe some programmers will try out a direct connection to machine, by this time maybe bidirectionally (Fred Brooks mentions, that productivity level of programmers can range 1:10 [1], so probably best programmers might have neuronal patterns, reusable for design of even more advanced software agents, as already demonstrated in industrial robotics [41]). Even without this type of approach, we are quite sure that dynamic SPL programming with AI support will become possible, e.g. an AI will analyze demand and shape an SPL as a part of the software product. Enterprises will use agent-based technology to create new, more advanced software agents and induce new quality standards in a self-propelling, artificial life manner. Likewise the industrial vision that machines could build their next generations by themselves, so why should same be not possible, even more viable in the virtual digital world – the Cyberspace?

Considering the impacts on the totally digitized… everything, we think that by then, the Industry Z will be born, Z for an maturity state which could dominate the rest of the 21st century and goes beyond our imagination limits, also considered as Technological Singularity [42].


This white paper gives a retrospective how industrial methods for automation, mass production and quality assurance have influenced the software engineering domain before 2016 resulting in Continuous Delivery and DevOps, and establishes a prognosis and a vision on how the Special Interest Group for Software Production lines (SIGSPL.org) estimates these fields can evolve until 2030, considering known trends.

As closing words, we quote Eric Ries, possible one of the most prominent industrial think leaders of our time: “The big question of our time is not Can it be built? but Should it be built? This places us in an unusual historical moment: our future prosperity depends on the quality of our collective imaginations.” [43]


List of Figures

Figure 1 – converging trends in software technology.
Based on: Watch multi-billion capital: SIGSPL.org Magic Triangle reveals how 21st century information technology will look like.
retrieved on 2016-02-12


Figure 2Automated Visual Software Analytics.
Source: Döllner/hpi.de (2015)
retrieved on 2016-02-12


[1] Mythical Man-Month. Brooks (1975)

[2] Lean Software Development: An Agile Toolkit. Poppendieck (2003)

[3] Competitive Advantage: Creating and Sustaining Superior Performance. Porter (1985)

[4] Digital Enterprise Transformation: A Business-Driven Approach to Leveraging Innovative IT. Uhl, Gollenia (2014)

[5] Continuous Integration: Improving Software Quality and Reducing Risk. Duvall et al. (2007)

[6] Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Humble, Farley (2010)

[7] DevOps: A Software Architect’s Perspective. Bass et al. (2015)

[8] Organizing ITSM: Transitioning the IT organization from the silos to services with practical organizational change. Steinberg (2015)

[9] Is the S (Sharing) in CALMS redundant? Devopsguys.com (2014)
retrieved on 2016-02-12

[10] Horizon 2020 Extract from Part 19 Commission Decision C(2014)4995, Annex G. Technology readiness levels (TRL). European Commission (2014)
retrieved on 2016-02-12

[11] Revealing the German plan on the future ‘Industry 4.0’ SIGSPL.org (2015)
retrieved on 2016-02-12

[12]  Supply Chain Engineering. Goetschalckx (2011)

[13] A Newcomer’s Perspective: Software Supply Chains Sonatype (2015)
retrieved on 2016-02-12

[14] Better and Fewer Suppliers (2015 Software Supply Chain Report). Nexus (2015)
retrieved on 2016-02-12

[15] VELOCITY: Combining Lean, Six Sigma and the Theory of Constraints to Achieve Breakthrough Performance – A Business Novel. Jacob et al. (2009).

[16] DevOps and ITIL: Friends or Enemies? Forbes (2015)
retrieved on 2016-02-12

[17] 5 Reasons Why Docker is a Billion Dollar Company. Forbes (2015)
retrieved on 2016-02-12

[18] FI-PPP FICONTENT2 public report, Chapter 5 “Packaging and delivery of server side Specific Enablers (SEs)”  (2015)
retrieved on 2016-02-12

[19] Periodic table of DevOps tools. XebiaLabs (2015)
retrieved on 2016-02-12

[20] Software Measurement: Establish – Extract – Evaluate – Execute. Christof Ebert (2007)

[21] The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Kim Gene (2013)

[22] Kof, 2007. Text Analysis for Requirements Engineering- Application of Computational Linguistics.

[23] Integrated Measurement – KPIs and Metrics for ITSM (Stories in transforming ITIL® best practice into operational success). D. McLean (2013)

[24] 70 MP Delight: Amazing 15000 x 5000 Pixels LHRD wall at the GI VR/AR workshop. SIGSPL.org (2015)
retrieved on 2016-02-12

[25] Deep Shift. Technology Tipping Points and Societal Impact. Survey Report. Global Agenda Council on the Future of Software & Society to World Economic Forum (2015)
retrieved on 2016-02-12

[26] Cognitive Computing and Big Data Analytics. Hurwitz, Kaufman (2015)

[27] A new UI for Docker? Docker.com (2015)
retrieved on 2016-02-12

[28] Build for VR in VR. Unrealengine.com (2016)
retrieved on 2016-02-12

[29] That Pivot Seems To Have Worked Out OK–CloudBees Picks Up $23.5M. Forbes (2015)
retrieved on 2016-02-12

[30] Abundance: The Future Is Better Than You Think. Peter H. Diamandis (2014)

[31] Travis CI – Overview. CrunchBase.com (2016)

[32] CTO Advisory: towards a benchmark for software quality you could show your CEO because it creates value through sustainability. SIGSPL.org (2015)
http://sigspl.org/2015/09/21/cto-advisory-towards-a-benchmark-for-software-quality-you-could-show-your-ceo-because-it-creates-value-through-sustainability  retrieved on 2016-02-12

[33] The Science of the Blockchain. Wattenhofer (2016)

[34] Great Chain of Numbers: A Guide to Smart Contracts, Smart Property and Trustless Asset Management. Swanson (2014)

[35] From Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence. Tsiatsis et al. (2014)

[36] The Fourth Industrial Revolution. Schwab (2016)

[37] IoT 2.0 – the next Internet of Things! SIGSPL.org (2015)
retrieved on 2016-02-12

[38] Industrial Agents: Emerging Applications of Software Agents in Industry. Leitão, Karnouskos (2015)

[39]  Magic Leap – A startup is betting more than half a billion dollars that it will dazzle you with its approach to creating 3-D imagery. TechnologyReview.com (2015)
retrieved on 2016-02-12

[40] Beyond Boundaries: The New Neuroscience of Connecting Brains with Machines – And How It Will Change Our Lives. Nicolelis (2012)

[41] Will robots take our jobs? MIT building worker robots that learn by operating beside humans. ibtimes.co.uk (2015)
retrieved on 2016-02-12

[42] The Technological Singularity. Shanahan (2015)

[43]  The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Ries (2011)

Header image source: http://img1.123freevectors.com/wp-content/uploads/portal/spaceship-illustration-free-vector-839.jpg

Chemistry of DevOps – stunning infografics!

Past days Adobe product portfolio chose quite catchy visual communication for its tools using symbols of chemical elements.

Now, Xebia Labs takes the challenge to use a whole DevOps periodic table approach. Looks indeed very nice, the only side comment is why they have included databases as well.

At SIGSPL.org, we of course can’t expect the times where these tools can be associated with appropriate quality labels to support management and solution architect decisions.



Screen Shot 01-13-16 at 12.40 PM

Copyrgiht notice: please ignore in this case our CC logo, the screenshot of the periodic table is courtesy of Xebia Labs, and we have done no modifications to the original.

Customer’s demand and excellence

Actually, why shouldn’t be possible to make excellence of delivery a clear budget feature? Say, somebody wants to have something small but really awesome, or they are okay with having something big but without paying attention to security and performance – customer is king, but shouldn’t expect that the highest possible level of excellence is always included for free.

2016-01-09 02_13_18-Muryshkin, Peter - Outlook Web App

SIGSPL.org 2015 annual report

Dear friends,

The year 2015 is coming to an end, and we want to wish you all a Merry Christmas and Happy New Year.

This post is a brief review of SIGSPL’s activities this year and technology observations.

The Magic SPL Triangle 4Q/2015


As there is yet no ‘official’ SPL technology but just initial trends, we have decided to put software products, which are in our opinion able to become proto-cells of future Software Production Lines, inside the Triangle. Outside the Triangle are products not directly related to SPL, but able to support.
If you think that your favourite technology is missing here, please tell us and we will consider an update to the diagram.


  • our members have deeper understanding of SPL, as well as good traction in their companies to drive our concepts forward;
  • we have recognized that with our methodology we can disrupt a multi-billion IT services market;
  • we designed an operational model for a rating agency to issue quality certificates. Our vision is to run it as a subsidiary department at the International Computing Centre by United Nations in Geneva;
  • we started contacting top notch VC companies to know how we can evolve after our first year, generate revenue and build a commercial branch, while aiming to improve this world as a public non-profit Think Tank.
  • we started talking to consulting companies interested in disruptive methods we offer.

Public relations

  • we launched this blog, offering its landing page in many languages to reach local communities;
  • we presented to the European Commission and the FICORE consortium our proposal of a technology agnostic digital certificate for technical software excellence, comparable to the EU Energy Consumption Label and received very positive feedback from all parties;

Many thanks to all supporters and readers and to all those who invested their time for brainstorming, exchanging ideas or an interview – we are looking forward to welcome new active members and contributors! 

santa cyborg

IoT 2.0 – the next Internet of Things!

“The Internet of Things 2.0 (IoT 2.0) is a virtual network of virtual objects or ‘virtual things’ embedded with virtual electronics, where applicable special IoT 2.0 software, virtual sensors, and network connectivity, which enables these virtual objects to collect and exchange data globally. That is, the physical matter in the IoT 2.0 domain space is digital code itself (with the two atoms 0 and 1), and virtual things are pieces of this digital code – or cyber artifacts.”


SCM: Better and fewer OSS suppliers in 2015

The 2015 Supply Chain report from Sonatype reveals recent facts on standard OSS software packages and vendors.

“Today I want to focus on the huge ecosystem of open source projects (“suppliers”) that feed a steady stream of innovative components into our software supply chains.  In the Java ecosystem alone, there are now over 108,000 suppliers of open source components [with 1M+ standard components – SIGSPL.org].  Across all component types available to developers (e.g., RubyGems, NuGet, npm, Bower, PyPI, etc.), estimates now reach over 650,000 suppliers of open source projects.” Derek Weeks

Screen Shot 12-16-15 at 06.59 PM 001

However, like in traditional manufacturing, not all suppliers deliver parts of comparable quality and integrity. My latest research, the 2015 State of the Software Supply Chain Report, shows that some open source projects use restrictive licenses and vulnerable sub-components, while other projects are far more diligent at updating the overall quality of their components. Choosing the best and fewest suppliers can improve the quality and integrity of the applications we deliver  to our customers.