In the software industry, open source has become a way of life. If not quite the de facto choice for enterprise software at every level (proprietary vendor-closed software isn’t going away any time this decade), then we can at least say that we’re seeing major organizations embrace a high degree of open technology platforms, products and protocols at many levels throughout their IT stacks.
Where firms haven’t deliberately bought into open source, they may very often be using cloud-based services that are sold as ‘branded & supported’ products after having been built on essentially open core technologies. This means that the deployment levels and use cases are widespread, even if the open core is just an ingredient in a wider technology platform in question.
What that implies for enterprise IT departments going forwards is a new responsibility. They need to be ‘looking out’ for open products and services that are bubbling upwards, coming forwards and enjoying the glow of widespread user adoption. It’s not complete guesswork – sometimes users will simply tell you, other times we can look for the point at which a project gets officially bootstrapped.
But What Is Bootstrapping?
Not to be confused with the process your computer goes through when it ‘boots up’ (although the term possibly borrows from that origin in some etymological senses) Alois Reitbauer, VP and chief technical strategist at Dynatrace explains that bootstrapping for an open source software entity is not the same as a product launch, it’s something that happens before that point in time.
“The key idea here to identify the point of bootstrapping is that there is some initial investment from a collective – a group of people or organization – to a) get the product to a level of functionality but also b) get an initial community around the project to reach ‘critical mass’ around it,” said Reitbauer. “But even though core functionality is obviously the most important thing as nobody will use a product/project if does not provide any value add – there are however an awful lot more elements of support structure that need to be built around an open (or indeed closed) software project before you can say it is successfully bootstrapped.”
Dynatrace’s approach to its development of Keptn and subsequent bootstrapping of this technology tells a story not just about what the product itself does, but of how organizations might move a product forward to open source status… and how they consider managing it afterwards. Keptn is an open source pluggable ‘control plane’ (in simpler terms: technology that configures and orchestrates how software gets shipped and managed) and it is part of the software industry’s efforts to promote movement toward autonomous self-managing clouds.
What ‘Points Of Maturity’ Define Bootstrapping?
So what else tells us that we’re ready to bootstrap a software project? Reitbauer says that bootstrapping also means making sure that the software supports the use case that it was initially conceived for. But actually, defining a key use case in precise terms is not always a cut and dried affair.
“Picking key use cases is always challenging. Usually there are (almost) always already solutions out there which cover parts of what a new project does. The key is to identify the fundamental [work] problem you are trying to solve – because this will encourage people to give the project a try, even if it’s initial development is not perfect in every area,” said Reitbauer.
Bootstrapping also requires that you have given the project itself a mindset, a personality perhaps. What we have to realize is that a software project is so much more than just the code. There are design principles, core values and the wider concepts that the project follows. These need to be well established and tested with the target audience. From their own experience with open sourcing software, the Dynatrace team say that the first months – or even year – is always especially hard… and you need a dedicated team that sees it as their mission to make the project successful.
After You’ve Bootstrapped, They Will Come, Right?
It is true that after a thoughtful, strategic and we could perhaps say ‘conscientious’ bootstrapping process has been carried out, a project is ready to open its doors to the global community of programmers who will help progress it and users who will adopt it. But as with so many things, it’s rarely that simple.
“After bootstrapping, you are open to the community from day one. However, nobody will just show up because your software code is accessible and downloadable on GitHub. Very often, people will have a quick look at the project and wait for a future, more mature release… or they won’t want to get actively involved as they don’t see the value – yet. Once you move beyond these initial hurdles, a community will (hopefully) start to emerge around the project,” explained Reitbauer.
Looking slightly longer term at next steps, let’s think 1-year-plus down the line. We may find that even after bootstrapping, the original development organization remains the major contributor. This is okay in principle. Red Hat Linux is still mostly developed by Red Hat (and indeed Linux is mostly contributed to by Red Hat). However, there are other examples – like Kubernetes – too.
“Open source development is a significant investment for a company… and it can be a good one if done seriously. Companies will stay and contribute more when they see proper business outcomes. Obviously, the initially contributing organization very often does, as this is the reason why they started the project in the first place. Organizations that develop projects where they are the only user will come and go. They might also stop contributing as the project becomes more mature. This is not real open source freedom playing out,” said Dynatrace’s Reitbauer.
Is Ignoring Open Source A Software Death Warrant?
If we accept the rise of enterprise open source and see where large-scale vendors from Microsoft to Oracle and every other branch of the tree are getting involved, is ignoring it akin to software suicide? To put the question another way, if you don’t open source some (possibly all, eventually) parts of your total technology proposition, then have you have signed the death warrant on your software to become legacy code?
“I don’t think this proposition can be generalized in this way. For some software, being open source is not necessary. There are cases where a cloud computing Software-as-a-Service (SaaS) product needs to have a free tier to drive market momentum. This is particularly true for software you use as a ready-made product like Google Gmail etc. This is still not a validation for all software needing to be open source. Instead you need to think about at least having an open source proposition at some level so that other people can build on top of your software, or even integrate it as a key part of their own software stack,” said Reitbauer.
As the practice of bootstrapping open projects grows and becomes a more prevalent part of the way software develops, it will not be a question of knowing when the bootstrap is tight enough – tautness doesn’t really factor in here in that way.
What will be important is knowing how much bootstrapping it will take to get a project off the ground… and so being able to question an organization’s internal resources (in this case we mean team members and workflow time, rather than machines) and being able to assess whether the team is willing and able to dedicate the effort. If they are, then it’s time to go and look for a clean pair of socks and strap your boots on.
originally posted on forbes.com by Adrian Bridgwater
