For Whom the Batphone Calls

A Runbook for Enterprise Adoption of Open Source Software 


Enterprise leaders wanting to do a “Dev and Ops” pivot need to own up to the fact that you have to earn you keep today when choosing this path.
If shit is broke, YOU should have the power to fix it.  This idea of outsourcing all problems to a paid closed source vendor support call can be naive and lazy in many cases.  You should have the power to be your own bat phone.  When you call Batman, you are in essence calling yourself.

Retirement Home Enterprise          

For the longest time, infrastructure and application support teams have operated in a super old workflow that was uninspiring.  They got paid well to be effectively “glorified maintenance/janitorial staff.”  An operations spreadsheet/app had a name on it that says they support X and Y.  When X or Y breaks, they put a ticket in a queue and call people.  These people look at some super basic stuff like 1) Is the server up and pingable?, 2) Is the app process running?, or 3) Is there a vague, nefarious network issue?  If none of these things get hits, they shrug their shoulders and  and open a ticket with the Vendor that they pay support to and then wait.  They then report to some person that reports to some other ops person that they are “working on the issue” with the vendor.  

The vendor then has a support engineer (L1/L2) work the call and ask for sane things like logs and read the case notes.  The enterprise support person just acts like a drone in this case typing whatever the vendor support engineer says and accepts whatever the vendor provides as an answer.  Unless an answer cannot be found, the enterprise support person just accepts the answer/fix and closes the case.  If no fix can be found, it effectively is like reporting a bug (If it is not already well known).  The fixing for the bug can be soon* or indefinite.  Unless the enterprise customer is huge (spends loads on support & products) the bug fix doesn’t get addressed fast.  It gets addressed on the schedule most convenient to the vendor.  These support contracts are not cheap.  This is such a lazy, lame approach.  I call this the “Batphone Mentality” where the vendor software support superhero is always a support phone call away.  This is  especially true for closed source COTS apps whose heavy handed approach actually creates a self-reinforcing cycle of enterprise retirement home “Batphone” mentalities. The problem is that Batman worked for free for Gotham, while enterprises have to pay salaries for multiple external vendor Batmans.

“closed source COTS apps … heavy handed approach actually creates a self-reinforcing cycle of enterprise retirement home “Batphone” mentalities.” 

The Emerging Open-Source Enterprise 

When you decide that you want to control your destiny, get things fixed faster, or add features and functionality to applications and tools you need to run your business, you may be ready to make the open-source switch.  If paying loads of money for support contracts is leaving you beholden to a vendor that is not transparent and open about product bug fixes or feature roadmaps, you are effectively trapped.  Major commercial software vendors with closed source products maintain a kind of hegemony over enterprise customers in the following ways: 

  • Forcing the customer to follow often stringent tech-stack requirements to install and use the product.
  • Forcing the customer to forgo support officially if they try to deviate any part of the tech-stack.
  • Making money off parts of this “required” tech-stack with onerous licensing.
  • Releasing new versions that require forklift upgrades that are uber costly and are often not backward compatible.
  • Purposely not being open with support documentation and requiring pay/account gateways to get it.
  • Forcing a god forsaken license key or licensing process that makes installs painful and limited.
  • Dropping a product completely leaving the customer with no option. 

“Major commercial software vendors with closed source products maintain a kind of hegemony over enterprise customers.”

For years enterprises just accepted this in large part due to the following reasons:

  • They used closed source OS platforms (Windows/AIX/Mainframes) since viable open-source alternatives were not available.
  • They bought software that was closed source because developing the software was hard and costly.
  • Tools needed to write software for these closed-source platforms were not easily accessible or free ($1000+ for Visual Studio is pathetic).
  • Technology perhaps was not a key part their business (non-tech companies).
  • Staff that had requisite skills to overcome (1-4) were not widely available. 

Enter the modern tech era Circa 2007 – 2014 where open-source software is almost an American birthright and as normal and accepted as apple pie.  Open source operating systems, applications, and software development tools are widely available that can solve many (if not most) of the things an enterprise might need (Linux, OpenStack, Nagios, Hadoop, Tomcat, Apache, Rails, NodeJS, and on and on).  Public code sharing repositories like Github, Gitlab, Gitorious, Cloudforge, Sourceforge, and GoogleCode have been a revolution in open-source workflow and project accessibility.  Github in particular has been a big part of this inflection point in social coding.  There has likely been more open-source momentum in the past 7 years than in that past 30.  It is truly an amazing time. Decades from now, folks may look back and ask all us old-timers stary-eyed questions about “what was it like to live during the second open-source revolution?” like we we lived through the equivalent of the roaring twenties or some other historically significant time.

“There has likely been more open-source momentum in the past 7 years than in that past 30.” 

While the open-source movement may have not started precisely in the San Francisco bay area, the area has been home to many leaders in the movement.  Partly perhaps due to the roots (even today) of silicon valley as a haven for free thinkers and futurists.  A place also were it was ok to be distrustful of governments and “the man.”  The bay area hippie culture of the 60’s may have also contributed in part to a tradition of folks wanting things to be free or more accessible that continues.  Today, there is still a vein of this benevolent revolutionary mindset behind every open-source project.  The interesting thing that has happened is that the hippies have been replaced by benevolent libertarian capitalists.  This is very cool.  Many startups in the valley today often release their product day one as an open-source project.  They simultaneously offer paid support for customers.  In many cases, their products are based on open-source products but sold also as SaaS or cloud offerings.  This is an amazing amount of new freedom for the enterprise.

“…the hippies have been replaced by benevolent libertarian capitalists.” 

Be your own Batphone 

If you want to control your destiny, get things fixed faster, or add features and functionality you need on your own schedule, you need to be using open-source software and hiring staff that are not drones or retirees.  Here is proposal for how the modern enterprise can call their own Batphone.

1) Use open-source software
     – get access to the source code now (there is a boat load out there
     – check lists like this (
2) Hire good developers for Apps and good developers for Infra
     – Pay them well
     – Empower them
3) Be very strategic about what commercial, closed source software you buy and use
     – It needs to provide a better ROI for functionality, speed, reliability than an OSS alternative.
     – Try to pick closed source software that at least is largely standards based (it can ease a transition off the product later if needed).
     – Put pressure on the vendor to allow flexibility of the tech stack to use open-source projects (tomcat, node, etc).
4) Train your staff and engineers well
5) Accept the fact that you can now truly control your destiny.

On this last point, it is a function of having skilled developers and engineers that use open source projects and have a specific mentality.  The mentality needed is really an “Anti-Batphone” mentality.  Developers and Engineers have to own up to the fact that they are the last person standing.  They are the last solider in the bunker and have to be McGiver or Will Wheaton to get it working.  They have to believe there is no fucking Batphone.  They are the Batphone. 

A Sample Enterprise anti-Batphone Support Call Flow

1) Some important app is broke
2) Open-source monitoring software alerts the app owner/developer team 
     – Operations sees that same alert and opens a ticket
3) Internal support engineer starts working on it
     – logs, processes, system level debugging
4) Something is broken with the code (a bug)
     – Look at the damn source code, you have it!
5) Commit code changes with the fix to your CI/CD pipeline.
     – Push to prod for the fix
     – close the internal support case.

Paying for Support with an Open Source Vendor 

Paying for support with a vendor that has an open-source version of it’s product is truly a win-win.
You get the luxury of official support.
The open-source vendor gets to make money and you still get the source code.
What if you cannot fix the bug with your internal staff?  What if you need to pay for support?
No problem, do the following: 

1) Locate a vendor that provides the product platform you need as open-source + support
2) Pay these good people for support.
3) Use their product and do the following for support issues
          – Open issues on Github for problems and bugs
          – Fix the bugs yourself and submit pull requests directly to the vendor github
4) Influence product roadmaps by submitting pull requests and collaborating with the vendor:
          – this can be from your own internal staff if they are skilled enough.
          – this can be through skilled contractors that you pay to develop modifications to submit as pull requests to the vendor.
          – this can be through outright paying the vendor for adding the features directly.
5) If for whatever reason the open-source vendor decides to stop working on the project, closes shop, or will not accept your pull requests for product modifications, you still own the source code.
          – you can take over the project
          – you can fork the project and do your own thing

This is an awesome new world with loads of new freedom.  Enterprises need to embrace this and control their destiny by using open-source software and using open-source vendors.  You should have the power to be your own bat phone.  When you call Batman, you are in essence calling yourself. 
















Introducing SFSC

I decided to take my many years of skateboarding love and pour it into my own new company.  So, after a lot of of hard work, product development, and testing, I created of San Francisco Skateboard Company (SFSC).  There are so many things I want to do for the sport of skateboarding and this company and brand will provide me a way to make things actually happen.  I plan to do a lot and I will be sharing it with you here.  I would really appreciate your support for the company.  Try out my products and let me know what you think.

Check it out here: San Francisco Skateboard Company


Becoming Coruscant?

The June issue of The Economist has a lead article titled “Towards the end of poverty.”  Among the key points made in the article is that gradually the world is making progress toward raising a defined minimum level of living wages to something more in line with developed countries.  As more countries join the global community and take part in the benefits of developed economies, everyone rises.  Now, there are many more granular, micro-level arguments that can be made about widening gaps between the more wealthy and middle-class, but the point of the article was that those in the world with living conditions that were extreme poverty are decreasing.

This got me thinking:  how long will it be before “developing” countries become “developed” and overall living conditions begin to approach those of current and long-time developed ones?  What would this new fully developed world look like?  How would a global citizenry all wanting and needing similar “developed” things function?  Think about it.  In the past 15 years China has grown in power and stature incredibly and (though opinions rightfully vary per issue) its citizens have benefitted along with this growth.  More middle-class, less poverty (overall), increased numbers of educated, and increased life expectancy levels in general (baring pollution issues) .  Similar exploding growth is happening in India with Africa likely to be next.  So, how many places on earth in 2013 are left that are considered “developing”?  Interestingly, there is not an official index from the UN (need to validate this), but there are some established viewpoints that get published from the World Bank and the IMF.  I found some here from Oxford University that says there are ~35-60 depending on who is reporting.  So, if all these countries took say twice as long as China (perhaps~ 30+ years) we might have a large global middle class by maybe 2050?

Combine this with the incredible advances in technology and medicine we have made in the past 30 years and you have the making of some of these Hollywood visions of the future like the self driving cars in Minority Report and ever larger cities that form interstate sized connecting metropolises.  Fast forward even farther and something like the full planet city of Coruscant in the Star Wars series doesn’t seem all that much of a fantasy.  The interesting thing to ponder is not so much the technology advancements but the globally touching life we all might lead in such a future.  I guess the question remains:  what does this future world look like when everyone becomes developed?  What type of interactions will we all have?  How will trade be done?  How will businesses remain competitive when wages are no longer arbitraged by going to a developing nation?  Could earth become one big developed planet?


Formula for Success in 2013

My formula for success in 2013 is essentially my new years resolution.

It is a simple math formula to get things done.  I have written it on my whiteboard at my desk as a constant reminder.


In other words:   DO  >  TALK

In reality it is way easier to type and say this as it is to actually do it.  The new world of IT Infrastructure means real leaders need to lead by having what I call HOK “Hands on Keyboard” as much as possible making things as well as talking about them.

I am also an optimist so I feel that my chances are really good that I will make this work.  See if it works for you too.


“Hello world!”

So after a long mental loop of reminding myself I need to share my technology discoveries and journeys, I finally did it.  Here it is, Padgeblog.  The blog name is based on a nick name I have had since high-school which is a shortened version of my last name Padgett.    Hence, the nick name “Padge” and now the blog “padgeblog.”

If you like explanations on why things arrived at their current state and where they are moving, especially on all things infrastructure technology with a little splash of skateboarding, occasional nice pictures, music discoveries, and some rants then you might enjoy this blog.

Let’s see how it goes.