The colour palette analogy of OSS

Let’s say you act for a service provider and the diagram below represents the number of variations you could offer to customers – the number that are technically supported by your solution.
13,824,000 Colours
That’s 13,824,000 colours.

By comparison, the following diagram contains just 20 colours:
20 Colours

If I asked you what colours are in the upper diagram, would you say red, orange, yellow, green, blue, etc? Is it roughly the same response as to the lower diagram?

If you’re the customer, and know you want an “orange*” product, will you be able to easily identify between the many thousands of different orange hues available in the upper diagram? Would you be disenfranchised if you were only offered the two orange hues in the lower diagram instead of thousands? Or might you even be relieved to have a much easier decision to make?

The analogy here to OSS is that just because our solutions can support millions of variants, doesn’t mean we should. If our OSS try to offer millions of variants, it means we have to design, then build, then test, then post-sale support millions of variants.

However, in reality, we can’t provide 100% coverage across so many variants – we aren’t able to sufficiently design, then build, then test, then post-sale support every one of the millions of variants. We end up overlooking some or accept risk on some or estimate a test spread that bypasses others. We’ve effectively opened the door to fall-outs.

And it’s fall-outs that tend to create larger customer dissatisfaction metrics than limited colour palettes.

Just curious – if you’ve delivered OSS into large service providers, have you ever seen evidence of palette analysis (ie variant reduction analysis) across domains (ie products, marketing, networks, digital, IT, field-work, etc)?

Alternatively, have you ever pushed back on decisions made upstream to say you’ll only support a smaller sub-set of options? This doesn’t seem to happen very often.

* When I’m talking about colours, I’m using the term figuratively, not necessarily the hues on a particular handset being sold through a service provider.

The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Who can make your OSS dance?

OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.

Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS‘s strings. Most only use the tiniest sub-set of functionality.

If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.

A question for you – You can make your OSS dance, but can your customers / users?

What can you do to assist users to navigate the decision tree? A few thoughts below:

  1. Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
  2. Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
  3. Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
  4. Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)

I’d love to hear your additional thoughts how to make it easier for users to make your  (their) OSS dance.

Linus’s Law of OSS defects

Given enough eyeballs, all bugs are shallow.”
Eric S. Raymond
, whose quote is now known as Linus’ Law in honour of Linus Torvalds.

In other words, if you have enough people looking at the code, someone will surely categorise the problem and then the community will also figure out a way to solve it.

The fragmentation of the OSS industry means that OSS eyeballs are spread across thousands of code bases. Based on the inverse of Linus’ Law, there’s an implication that OSS bugs are deep. In fact, there are so many defects and/or enhancements waiting to be resolved across our industry that only the highest priority tickets tend to get any eyeballs at all.

The open-source revolution has ensured that the code of the most important applications (I use the word “important” figuratively) get lots of eyeballs. It’s one of the reasons that I believe the next OSS revolution will come about when an open-source OSS (an OSS OSS??) starts getting a critical mass of eyeballs. That OSS OSS just needs to be compelling enough to draw the eyeballs to it.

This is one of the pillars in the Call for Innovation that will be released here on PAOSS shortly.

Call for Innovation by Swisscom, Telia and Proximus

Software Defined Networking (SDN) and Network Function Virtualization (NFV) are about to transform and disrupt the network operator industry.

That’s why Swisscom, Telia Company and Proximus, three leading telco providers from across Europe, are jointly issuing this unique Call for Innovation and invite startups and innovators developing “Next Generation Virtual Telco Functions & Services (SDN / NFV 2.0)” to apply until 23 October 2016.

The best startups will be able to pitch their solution in front of an expert jury and have the chance to be selected for a PoC project and future collaboration with all three telcos..
What we are looking for

The topics considered for this call are related to SDN/NFV development within the telecommunication industry. The baseline infrastructure for SDN/NFV is available and is largely based on the de-facto standards and open source-based systems of OpenStack/OPNVF/CloudFoundry. The next steps and next wave of innovations should be using that infrastructure for new networking functions, cloud-native implementation of existing network functions, and new Telco services we could offer in the market.”


Let me start out with an apology. This is old news. The Swisscom / Telia Company / Proximus Call for Innovation closed nearly a year ago. However, I’m bringing it to your attention for what it means to the telco industry. It’s acknowledging that traditional suppliers to telcos are not always servicing the need for innovative approaches to the problems the telcos are facing. It’s targeting the long tail of innovation.

Whilst this is specifically seeking SDN/NFV innovations, what does a Call for Innovation look like for OSS? Keep an eye out here on PAOSS, as I’ll be publishing an OSS Call for Innovation shortly.

Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

The OSS Think Big juxtaposition

I recently saw the advertisement below:

I’ve clipped only the last 10 seconds because that was the part that struck me. The ad is for BHP*, one of the world’s largest miners. The mining industry thinks in long-term projects because it takes many years to deliver results – for exploration, planning, approvals, for the infrastructure to be built and operationalised, etc.

Mining is “only” the process of pulling natural resources out of the ground, but despite all our complexities, mining projects tend to be far more complex than for OSS. The decade-long duration of projects means that technologies that were originally included in plans frequently become obsolete mid-flight and have to be re-planned. That means major contracts also need to be obsoleted and re-planned mid-flight. Work-force management has a completely different scale than for OSS.

Mining thinks in time-frames of decades. OSS transformations are planned in time-frames of years. OSS delivery, especially Agile deliveries, often only think in quarters (or much, much less).

In OSS, do we really Think Big?

But there’s a twist on this question. In the rare cases when we do think big, are we constraining ourselves by then following into the “deliver big” mindset too? In OSS, I’ve always felt that we deliver most efficiently when very small numbers of very clever people group together.

So there’s the juxtaposition with the clip above – Think Big… Think Small.

When you’re thinking of OSS roadmaps, what’s your thinking time-frame?

* For disclosure, I’m not an investor in BHP to my knowledge, but perhaps my super fund is.

Getting past the first layer on the OSS onion

When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions.”
Steve Jobs

The quote above pretty well describes my experience with OSS. The first solutions we come up with for a given problem are generally very complex…. and that’s where we stop because there are so many other problems to move on to next.

Does that reflect your experiences too?

Do we ever get the chance to take a deep breath because we have all our roadmap items completed, and then therefore have time to peel more layers off old problems?

In my experience this just doesn’t happen. So that just leaves us with solutions that are complex… to the detriment of OSS as a whole.

So the question for you today is how to give the time and space to be able to peel more layers off our OSS onions?

My initial thought is that we should stop adding so many things into the roadmap – to take the 80/20 approach into our roadmap prioritisation – leaving more time to refine the really important stuff. I’d love to hear your thoughts though.

Think war!

Think war. Extreme times call for extreme measures. When your ideas are facing life or death, that’s an extreme time. Like a soldier in battle, you can’t even afford to suffer a single hit – so make sure you hit first. Pull out all stops. Remember, when your idea’s life is on the line, the last thing you want is a fair fight. Use every available weapon. If possible, grab the unfair advantage. And never forget what might well be your most effective weapon: the passion you feel for your idea.
Ken Segall
in his book, “Insanely Simple.”

I’m normally involved in OSS projects as a delivery or strategy resource rather than the instigator of the project. However, the quote above represents one of the key messages I suggest to customers during the early days of a project, especially on significant OSS transformation or implementation projects.

Plan to bring (and sustain) all the firepower you can to the change effort. Don’t just scramble for air support if you’re losing the change battle.

Expect there to be many obstacles to arise that are outside the level of influence the delivery teams can exert. What are your unfair advantages?

Nuage Networks wins enterprise SDN project in China

Nuage Networks wins first SDN-based, large enterprise project in China.

Nuage Networks, the Nokia venture focused on software-defined networking (SDN) solutions, announced a significant addition to its roster of global financial customers with its first SDN-based, large enterprise project win in China with China Pacific Insurance Company (CPIC), the country’s second-largest property insurance company. The private cloud SDN project,won via Nokia Shanghai Bell, will use Nuage Networks Virtualized Services Platform (VSP) in two CPIC data centers: one to integrate the dispersed IT systems of 82 branch offices into one unified private cloud platform, and the second to assist in building and testing the company cloud for R&D. As a result, CPIC can achieve improved flexibility, agility and security, all while simplifying network operations and lowering IT costs.

Nuage Networks VSP will enhance CPIC’s efficiency by increasing scale and reducing errors with a centralized policy manager. The solution gives CPIC and other financial institutions greater agility to automate the configuration, management and optimization of virtual networks, including security services for individual applications and workloads.

Openet’s policy solution wins with Iridium

Openet’s policy solution has now been implemented by three satellite operators.

Openet announced that Iridium Communications has implemented its Policy Manager solution. The solution, Openet’s third deployment with a satellite operator, will allow Iridium to drive revenue by imposing real-time controls on data consumption and time usage across its 66 low-Earth orbiting (LEO) cross-linked satellites.

With the world’s largest commercial satellite constellation, Iridium provides reliable voice and data services to global enterprises for mission-critical activities. The company therefore required a future-proof, dynamic solution to control and monetize network resources by volume in real-time. Its commercial proposition – providing ubiquitous connectivity through reliable, low-latency communications services – also meant that the high availability of Openet’s Policy Manager played an important role in the partnership for Iridium.

Policy Manager allows Iridium to differentiate its users by class (e.g. prepaid vs. post-paid) or types of data (real time streaming vs. non-real time). Openet’s technology also enables Iridium to intelligently control data consumption and time usage. Aligning with Iridium’s core network roadmap, the solution will expand to include other types of policy controls including time of day or geography.

“Openet came highly recommended by our partner network,” said Hermon Pon, vice president of technology development and network engineering at Iridium. “Openet’s highly technical features meet our requirements, allowing us to drive revenue and remain continuously operational which is a key part of our proposition. The company’s agile approach to policy management also allows us to focus each specific use case for data usage when we need it, making the company a dependable technology partner as we continue to future proof.”

“As demand for satellite services and connectivity grow in emerging areas such as enterprise services and IoT, policy management is required to help satellite operators drive revenue and differentiate against competition including cellular and terrestrial networks,” said Niall Norton, CEO, Openet. “This is our third policy deal with a satellite operator, and we have also deployed the solution with a number of fixed broadband providers. The demand for policy controls outside of traditional telecoms networks is growing, and we’re proud to play a key role in helping Iridium evolve within its market.”

One of the biggest insights we had…

One of the biggest insights we had was that we decided not to try to manage your music library on the iPod, but to manage it in iTunes. Other companies tried to do everything on the device itself and made it so complicated that it was useless.”
Steve Jobs

How does this insight apply to OSS? Can this “off device” perspective help us in designing better OSS?

Let’s face it – many OSS are bordering on useless due to the complexity that’s build in to the user experience. So what complexity can we take off the “device?” Let’s start by saying “the device” is the UI of our OSS (although noting the off-device perspective could be viewed much more broadly than that).

What are the complexities that we face when using an OSS;

  • The process of order entry / service design / service parameters / provisioning can be time consuming and prone to errors,
  • Searching / choosing / tracing resources, particularly on large networks, can result in very slow response times,
  • Navigating through multiple layers of inventory in CLI or tabular forms can be challenging,
  • Dealing with fixed processes that don’t accommodate the many weird and wonderful variants that we encounter
  • Dealing with workflows that cross multiple integration boundaries and slip through the cracks,
  • Analysing data that is flawed generally produces flawed results
  • Identifying the proverbial needle in the haystack when something goes wrong
  • And many, many more

How can we take some of those complexities “off-device”

  • Abstracting order and provisioning complexity through the use of catalogs and auto-populating as many values as possible,
  • Using augmented decision support to assist operators through complex processes, choosing from layers of resources, finding root-causes to problems, etc,
  • Using event-based processes that traverse process states rather than fixed processes, particularly where omni-channel interactions are available to customers
  • Using inventory discovery (and automated build-up / tear-down in virtualised networks) and decision support to present simpler navigations and views of resources
  • Off-device data grooming / curation to make data analysis more intuitive on-device
  • etc

In effect, we’re describing the tasks of an “on-device” persona (typically day-to-day OSS operators that need greater efficiency) and “off-device” persona/s (these are typically OSS admins, configuration experts, integrators, data scientists, UI/UX experts, automation developers, etc who tune the OSS).

The augmented analytics journey

Smart Data Discovery goes beyond data monitoring to help business users discover subtle and important factors and identify issues and patterns within the data so the organization can identify challenges and capitalize on opportunities. These tools allow business users to leverage sophisticated analytical techniques without the assistance of technical professionals or analysts. Users can perform advanced analytics in an easy-to-use, drag and drop interface without knowledge of statistical analysis or algorithms. Smart Data Discovery tools should enable gathering, preparation, integration and analysis of data and allow users to share findings and apply strategic, operational and tactical activities and will suggest relationships, identifies patterns, suggests visualization techniques and formats, highlights trends and patterns and helps to forecast and predict results for planning activities.

Augmented Data Preparation empowers business users with access to meaningful data to test theories and hypotheses without the assistance of data scientists or IT staff. It allows users access to crucial data and Information and allows them to connect to various data sources (personal, external, cloud, and IT provisioned). Users can mash-up and integrate data in a single, uniform, interactive view and leverage auto-suggested relationships, JOINs, type casts, hierarchies and clean, reduce and clarify data so that it is easier to use and interpret, using integrated statistical algorithms like binning, clustering and regression for noise reduction and identification of trends and patterns. The ideal solution should balance agility with data governance to provide data quality and clear watermarks to identify the source of data.

Augmented Analytics automates data insight by utilizing machine learning and natural language to automate data preparation and enable data sharing. This advanced use, manipulation and presentation of data simplifies data to present clear results and provides access to sophisticated tools so business users can make day-to-day decisions with confidence. Users can go beyond opinion and bias to get real insight and act on data quickly and accurately.”
The definitions above come from a post by Kartik Patel entitled, “What is Augmented Analytics and Why Does it Matter?.”

Over the years I’ve loved playing with data and learnt so much from it – about networks, about services, about opportunities, about failures, about gaps, etc. However, modern statistical analysis techniques fall into one of the categories described in “You have to love being incompetent“, where I’m yet to develop the skills to a comfortable level. Revisiting my fifth year uni mathematics content is more nightmare than dream, so if augmented analytics tools can bypass the stats, I can’t wait to try them out.

The concepts described by Kartik above would take those data learning opportunities out of the data science labs and into the hands of the masses. Having worked with data science labs in the past, the value of the information has been mixed, all dependent upon which data scientist I dealt with. Some were great and had their fingers on the pulse of what data could resolve the questions asked. Others, not so much.

I’m excited about augmented analytics, but I’m even more excited about the layer that sits on top of it – the layer that manages, shares and socialises the aggregation of questions (and their answers). Data in itself doesn’t provide any great insight. It only responds when clever questions are asked of it.

OSS data has an immeasurable number of profound insights just waiting to be unlocked, so I can’t wait to see where this relatively nascent field of augmented analytics takes us.

My least successful project

Many years ago I worked on a three-way project with 1) a customer, 2) a well-known equipment vendor and 3) a service provider (my client). Time-frames were particularly tight, not so much because of the technical challenge, but because of the bureaucratic processes of the customer and the service provider. The project was worth well in excess of $100M, so it was a decent-sized project as part of a $1B+ program.

The customer had handed the responsibility of building a project schedule to the equipment vendor and I, which we duly performed. The Gantt chart was quite comprehensive, running into thousands of lines of activities and had many dependencies where actions by the customer were essential. These were standard dependencies such as access to their data centres, uplift to infrastructure, firewall burns, design approvals, and the list goes on. The customer had also just embarked on a whole-of-company switch of project management frameworks, so it wasn’t hard to see that related delays were likely.

The vendor and I met with the customer to walk through the project plan. About half-way in, the customer asked the vendor whether they were confident that timelines could be met. The vendor was happy to say yes. I was asked the same question. My response was that I was comfortable with the vendor’s part, I was comfortable with our part (ie the service provider’s), but that the customer’s dependencies were a risk because we’d had push-back from their Project Manager and each of the internal business units that we knew were impacted (not to mention the other ones that were likely to be impacted but we had no visibility of yet).

That didn’t go down well. I copped by far the biggest smashing of my career to date. The customer didn’t want to acknowledge that they had any involvement in the project – despite the fact that they were to approve it, house it, host it, use it and maintain aspects of it. It seemed like common sense that they would need to get involved.

Over the last couple of decades of delivery projects, one trend has been particularly clear – the customer gets back what they put in. That project had at least twelve PMs on the customer side over the 18 month duration of the project. It moved forward during stints under the PMs who got involved in internal solutioning, but stagnated during periods under PMs that just blame-stormed. Despite this, we ended up delivering, but the user outcomes weren’t great.

As my least successful project to date (hopefully ever), it was also one of my biggest “learnings” projects. For a start, it emphasised that I needed to get better at hearts and minds change management. There were many areas where better persuasion was required – from the timelines / dependencies to the compromised architecture / hardware that was thrust upon us by the customer’s architects. What seemed obvious to me was clearly not so obvious to the customer stakeholders I was trying to persuade.

You have to love being incompetent

You have to love being incompetent in order to be competent.”
James Altucher

Not sure that anyone loves feeling incompetent, but James’ quote is particularly relevant in the world of OSS. There are always so many changes underway that you’re constantly taken out of your comfort zone. But the question becomes how do you overcome those phases / areas of incompetence?

Earlier in my career, I had more of an opportunity to embed myself into any area of incompetence, usually spawned by a technical challenge being faced, and pick it up through a combination of practical and theoretical research. That’s a little harder these days with less hands-on and more management responsibilities, not to mention more demands on time outside hours.

In a way, it’s a bit like stepping up the layers of TMN management pyramid.
TMN Pyramid
Image courtesy of

With each step up, the context gets broader (eg more domains under management), but more abstracted from what’s happening in the network. Each subsequent step northbound does the same thing:

  • It abstracts – it only performs a sub-set of the lower layer’s functionality
  • It connects – it performs the task of connecting and managing a larger number of network elements than the lower layer

Conversely, each step down the management stack should produce a narrower (ie not so many device interconnections), but deeper field of view (ie a deeper level of information about the fewer devices).

The challenge of OSS is in choosing where to focus curiosity and improvements – diving down the stack into new tech or looking up and sidewards?

Warring tribes and the five paper ball technique

The following extract from Ken Segall’s book, “Insanely Simple,” provides a great story on persuasion:
At one agency meeting with Steve Jobs, we were reviewing the content of a proposed iMac commercial when a debate arose about how much we should say in the commercial. The creative team was arguing that it would work best if the entire spot was devoted to describing the one key feature of this particular iMac. Steve, however, had it in his head that there were four or five really important things to say. It seemed to him that all of those copy points would fit comfortably in a thirty-second spot.
After debating the issue for a few minutes, it didn’t look like Steve was going to budge. That’s when a little voice started to make itself heard inside the head of Lee Clow, leader of the Chiat team. He decided this would be a good time to give Steve a live demonstration.
Lee tore five sheets of paper off of his notepad (yes, notepad—Lee was laptop-resistant at the time) and crumpled them into five balls. Once the crumpling was complete, he started his performance.
“Here, Steve, catch,” said Lee, as he tossed a single ball of paper across the table. Steve caught it, no problem, and tossed it back.
“That’s a good ad,” said Lee.
“Now catch this,” he said, as he threw all five paper balls in Steve’s direction. Steve didn’t catch a single one, and they bounced onto the table and floor.
“That’s a bad ad,” said Lee.
I hadn’t seen that one before, so I rather enjoyed it. And it was pretty convincing proof: The more things you ask people to focus on, the fewer they’ll remember. Lee’s argument was that if we want to give people a good reason to check out an iMac, we should pick the most compelling feature and present it in the most compelling way

For most people in our industry, initiating OSS change is all about designing a technical solution that can fulfill a list of requirements. This may be effective in some situations, but in large carrier environments the bigger challenge is almost always in getting the many stakeholders contributing towards a common goal. If the project is big enough, multiple different business units will be involved and/or impacted. Each will tend to have their own objectives / metrics – and they’re often metrics that are misaligned or even in conflict – what common goal?

In the all-too-common “warring tribe” situation, persuasion techniques become essential. A great place to start is by creating an inspiring vision, much like John F Kennedy established when in 1961, he exhorted America to put a man on the moon before the decade was out.

There are many persuasion techniques, but I put them into two categories:

  • What you’re going to add
  • What you’re going to take away

I’m sure you want to go deeper, so Kellerman and Cole’s 64 Compliance-gaining Strategies give some great persuasive food for thought. Different strategies will work better/worse with different stakeholders of course, .

But to loop back to Ken Segall again, if you’re responsible for a significant change that crosses multiple domains and multiple stakeholders / influencers, you may choose to start with a vision based around the “most compelling feature and present it in the most compelling way.”

How many of you are wondering whether you could use the five paper ball technique to persuade in your next OSS stakeholder group when complexity is running rampant?

Deciding whether to PoC or to doc

As recently discussed with two friends and colleagues, Raman and Darko, Proofs of Concept (PoC) or Minimum Viable Product (MVP) implementations can be a double-edged sword.

By building something without fully knowing the end-game, you are potentially building tech-debt that may be very difficult to work around without massive (or complete) overhaul of what you’ve built.

The alternative is to go through a process of discovery to build a detailed document showing what you think the end product might look like.

I’m all for leaving important documentation behind for those who come after us, for those who maintain the solutions we create or for those who build upon our solutions. But you’ll notice the past-tense in the sentence above.

There are pros and cons with each approach, but I tend to believe in documentation in the “as-built” sense. However, there is a definite need for some up-front diagrams/docs too (eg inspiring vision statements, use cases, architecture diagrams, GUI/UX designs, etc).

The two biggest reasons I find for conducting PoCs are:

  • Your PoC delivers something tangible, something that stakeholders far and wide can interact with to test assumptions, usefulness, usability, boundary cases, etc. The creation of a doc can devolve into an almost endless set of “what-if” scenarios and opinions, especially when there are large groups of (sometimes militant) stakeholders
  • You’ve already built something – your PoC establishes the momentum that is oh-so-vital on OSS projects. Even if you incur tech-debt, or completely overhaul what you’ve worked on, you’re still further into the delivery cycle than if you spend months documenting. Often OSS change management can be a bigger obstacle than the technical challenge and momentum is one of change management’s strongest tools

I’m all for deep, reflective thinking but that can happen during the PoC process too. To paraphrase John Kennedy, “Don’t think, don’t hope, (don’t document), DO!” 🙂

This is the best OSS book I’ve ever read

This post is about the most inspiring OSS book I’ve ever read, and yet it doesn’t contain a single word that is directly about OSS (so clearly I’m not spruiking my own OSS-centric book here 😉 ).
It’s a book that outlines the resolutions to so many of the challenges being faced by traditional communications service providers (CSPs) as well as the challenges faced by their OSS.

It resonates strongly with me because it reflects so many of my beliefs, but articulates them brilliantly through experiences from some of the most iconic organisations of our times – through their successes and failures.

And the title?

Insanely Simple: The Obsession That Drives Apple’s Success.
Book by Ken Segall.
Insanely Simple

OSS is downstream of so many Complexity choices that this book needs to be read far beyond the boundaries of OSS. Having said that, we’re incredibly good at adding so many of our own layers of complexity.

Upcoming blogs here on PAOSS will surely share some of its words of wisdom.

One unasked last question for OSS business cases

OSS business case evaluators routinely ask many questions that relate to key metrics like return on investment, capital to be outlaid, expected returns, return on investment, and more of the same circular financial questions. 🙂

They do also ask a few technical questions to decide risk – of doing the project or not doing the project. Timeframes and resources come into play, but again tend to land back on the same financial metric(s). Occasionally they’ll ask how the project will impact the precious NPS (Net Promoter Score), which we all know is a simple estimate to calculate (ie pluck out of thin air).

As you can tell, I’m being a little tongue-in-cheek here so far.

One incredibly important question that I’ve never heard asked, but is usually relatively easy to determine is, “Will this change make future upgrades harder?

The answer to this question will determine whether the project will have a snowballing effect on the TCO (total cost of ownership – yes, another financial metric that actually isn’t ROI) of the OSS. Any customisation to off-the-shelf tools will invariably add to the complexity of performing future upgrades. If customisations feed data to additional customisations, then there is a layer multiple to add to the snowball effect.

Throw in enough multi-layered (meshed?) customisations and otherwise routine upgrades start to become massive undertakings. If upgrades are taking months of planning, then your OSS clearly no longer facilitates the level of flexibility that is essential for modern service providers.

The burden of tech-debt insidiously finds its way into OSS stacks, so when evaluating change, don’t forget that one additional question, “Will this change make future upgrades harder?

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?