the rise and fall of the microsoft empire


Our historical timeline begins in 1975 when an unlikely duo—Paul Allen as Batman and Bill Gates as his awkward “Boy Wonder”—started Microsoft Corporation.  I’m guessing that ro-sham-bo was involved in this decision but incredibly somehow Bill was made the CEO when the company got its start.  Maybe dropping out of Harvard gives you that kind of confidence.



Nothing really significant happened until they managed to modify an existing operating system for the IBM PC in 1981 from another company and rename this to MS-DOS. Significant sales of the IBM series of computers and those of their competitors then launched a thirty-year stretch of dominance in the business world in the area of operating systems, software and development platforms.

For most of us, we reasonably dismissed Apple’s hardware and the MacIntosh operating systems as nothing we could seriously use in business outside of the marketing department.

Consumers bought new versions of software and that license was good for life.  It could often be transferred from one computer to the next as long as the last one was de-registered first.  If you built software for Windows, you likely used a Microsoft compiler to do so and you paid for that.  In fact, the Microsoft Technet collection of CDs was quite expensive.


About six years into the “Internet Tidal Wave” as Bill would call it, Microsoft was starting to lose its way.  They tried to dominate in the browser wars but never quite managed to quash the competition.  Others saw their efforts in this area as annoying.  Their software for creating programs, Visual Studio, first hit the scene about four years prior to this.

Google was founded some five years prior and was just beginning to get attention from an investor before they had anything real yet.  In 1999 they moved from their garage to an actual building in Palo Alto.  Yahoo’s popularity as a search engine from a decade ago was waning.  Google’s ad-based revenue from keywords was paying off; they’d planted a money tree which eventually created an entire forest of money trees for them.  It wouldn’t be long until Microsoft’s executives behind closed doors would consider Google their biggest threat.

About this time Apple created a very clever method of provisioning content for one-and-only-one device within the music-delivery space.  The iTunes store would turn out to be the goose that laid the golden egg, as seen in the following revenues.  And yet, it would take years for either Microsoft or Google to realize the beauty in this fulfillment model and to come up with their own versions.


The “Internet of Things” concept started gaining in popularity at this time.


Microsoft’s attempts at copying Google’s success (MSN Search, Windows Live Search, Live Search) now culminated in the introduction of Bing as their default search engine destination for all things Microsoft.

Apple introduced the first iPhone and the first iPad about this time, noting that the same provisioning model from iTunes was incorporated into both via iOS.  The subscription model of sofware licensing was born with this, if you think about it.  If you wanted to write a program for either, you needed to use Apple’s software to do so.

Google has just introduced Chrome as a browser and would begin their campaign to slowly break Internet Explorer.  The same was true of the Android phone and its related operating system.  It would take a few years for Microsoft to catch up to either the iPhone or the Android before releasing their own app-savvy smartphone offering.

Amazon some three years prior had introduced the beginning of what would be a full complement of cloud-based services to support web development.  It would take Microsoft two full years to realize that they needed to be in this space and they didn’t have their offering ready for a few years more, too late to effectively compete. had just celebrated their first year online, hosting over 46,000 repositories by then.  The world of open source was the very antonym to the way that software had been developed prior to this.

The free Ubuntu operating system was released about four years prior to this, backed by the well-funded company Canonical.


Microsoft releases Windows 10, “the last version of Windows” (they claimed).  Rumors suggested that Windows would eventually go from a version-based license model to an annual-subscription model with respect to pricing.  I think it’s safe to say that the market hasn’t really embraced either Windows 8 or Windows 10.

The subscription-based model for Office 365 was introduced four years prior to this so the writing was definitely on the wall:  Microsoft wanted to depart from their former methods of making money and to chase the monthly subscription model.


The world of open source was offering new programmers a wealth of free code.  All they had to do was to take it and make it their own.  Formerly, Microsoft-friendly coding languages like C, C++, C#, VB and .NET dominated the playing field but this graphic shows how the game had changed.


And here we are, present-day.  That curious number 42 now describes the number of years that Microsoft has been around.

Yesterday evening, I attended a very geeky meetup of perhaps fifty or sixty coders and only saw one Windows-based laptop.  Almost everyone had a MacBook of some kind.

I just spent about two hours today installing the free Visual Studio Community 2017 software so that I could—in theory, anyway—alter a free copy of the source code for TightVNC software.  Out of the box, so-to-speak, Visual Studio doesn’t want me to build this project since it uses an earlier target platform (Windows 7 or 8, one would assume).

Microsoft only wants me to make things for Windows 10.

So rather than making it easy for me to build a program that will happily work with Windows 7, they’re forcing me to jump through hoops in order to add the necessary pieces for this to happen.

Add two more hours to this and I find that my installation does not want to download the earlier pieces to allow this to happen.  I’m forced to then upgrade the code to Windows 10 compatibility mode… only to find that the build fails with 528 errors.

The main crux of all these errors appear to be:  “we can’t find common files”.  It’s a very amateur sort of error from a company that’s been providing compilers for several decades now.

I have to think that Microsoft doesn’t want me to do anything with Visual Studio unless it benefits Microsoft.  And this is the core of the reason why I suggest that they’re doomed.

Every time a coder like myself runs into obstacles like these, the usual seed that’s planted inside their head is “this would be easier with another free compiler or another language from someone else”.


Fast-forward another five years and Microsoft will have lost ground on many fronts.  New software development here, there and everywhere will be via some language which wasn’t popularized by Microsoft on computers which aren’t Windows and with browsers which aren’t Internet Explorer or Edge.  Our toasters and refrigerators and our cars will be powered by the Ubuntu operating system or perhaps Debian, a similar free Linux flavor.  These appliances will be connected to our wi-fi and even to the Internet but there won’t be a scrap of anything Microsoft about them.  They’ll be coded up with something that isn’t C#, doesn’t use .NET and doesn’t need Visual Studio in order to compile it.

The only thing with a Microsoft pedigree with some staying power could be some of the websites and services currently served up at Microsoft’s datacenters via Azure.  But Amazon or Google could kill that by simply lowering their own prices for cloud-based services.

the 21st century digital résumé

It used to be that a programmer’s résumé was a single sheet of onionskin paper (expensive, semi-transparent) with a carefully-selected collection of one’s job history and such. Parts of what you were trying to “sell” to the would-be employer were your wordprocessing and layout design skills.

Now, everyone can type, has access to printers/computers and Microsoft Word. In fact, they can even select an attractive template from the many offered so it’s not like much skill is now involved in those areas. At one time, spellchecking was an activity that involved a Webster’s dictionary. The world has changed.


To be an open-source programmer, you must now have a public set of repositories on or so it seems.  My collection of repositories on github.


As of today, I now have my very own collection. My public dashboard on jsfiddle.

WordPress blog

More and more, programmers are encouraged to be social and outgoing enough to want to communicate to others. Obviously, you’re here already so you have my blog’s address.


And part of that “being social” requirement now seemingly includes spending a fair amount of time during your life chatting with others within the coding space. Since projects appear to be project-centric rather than coder-centric, there doesn’t appear to be a way of publicizing your identity outside of a particular team URL.

Website portfolio

And then of course, potential employers want you to highlight several existing website concepts in which you either participated or you directly own them.

why do you contribute to other’s repositories?

I’m interested to hear from other open-source coders out there. I’d like to know some of your motivations for contributing to another person’s or another team’s open-source repository. Call it a social studies experiment, if you will.

1st-Person Open-source

Here, I’m attempting to answer the question for everyone: “Why do you work on your own project in a public way and sharing your source code, knowing full-well that someone may take your code or fork your project and become rich and famous as a result?”

  1. I believe that my project has some worth for others and sharing it could make the world a better place to live in
  2. Other people might help me with my project
  3. A well-rounded github set of repositories looks good on my résumé
  4. I’m not expecting to make money from doing this
  5. Since I don’t live in America, there aren’t as many opportunities so this is my way of getting some attention from potential companies there

Let me know if I’ve missed any motivations here.

2nd/3rd-Person Open-source

This one’s a little trickier for me since I’ve been a life-time coder. In the not-so-distant past I was well-paid for working on software projects and have watched the coding salaries and the availability of programming gigs all erode.

The next question then for everyone: “Why do you work on someone else’s project in a public way, fixing their bugs and adding features, knowing full-well that some else may become rich and famous as a result?”

Case study – Github: Bloomberg reports that they recently brought in another $100M in venture capital based upon the Enterprise-level private repository revenue they’re currently earning. They’re currently valued at US$2B.

  1. I really like the other project’s code (let’s say, the Atom editor), believe in it and want it to be more awesome than it already is; since I use it myself, I’m getting something from the collaboration
  2. I want to work on a big project but I can’t otherwise get a job in a software development company so this is the next best thing; I’m getting the experience working in a software development team
  3. “Many hands make light work”; it feels good to help others; karma; “what comes around, goes around”…
  4. As a new programmer, I don’t have enough experience to start my own project yet
  5. Since I don’t live in America, there aren’t as many opportunities so this is my way of getting some attention from potential companies there; I might get hired by doing this

If I’ve missed any of your own motivations for coding on other people’s/team’s open-source projects, please add a comment here.

Some Thoughts on the Open-source Subject

What’s strange is when you have an entire team of people spread all over the planet, they’re working together on a project started by one guy (let’s say), time goes by, the project goes viral and then suddenly one day that “one guy” gets $250M in venture capital (like in the case of github). It’s valued at US$2B at the moment, btw. That’s about the same value as the New York Times.

I wonder if the investment companies realize that for the average open-source “company” this means that 1) they’re not necessarily incorporated, 2) they probably don’t have an office nor even a business checking account, 3) and anyone can fork the collection of code and start their own Atom-knockoff project if they wanted to.

And what happens to all the people whose free labor went into making github who they are today? Do they get a share of the money? No, they don’t. Do they get a job? Possibly, I suppose it all depends upon that original guy. But at this point, the power has greatly shifted from what it was before (more of a democratic society) to what it is now (more of a capitalistic corporation).

The siren call of open-source is a world which is free from capitalism. But what seems to happen is that these big projects are becoming exactly that, the thing these coders hated in the first place (or so it would seem). Open-source is supposed to be a culture. So why is it turning into nothing more than a first step to becoming a (funded) software development corporation in the end?

unseen complications

Don’t you hate the unseen complications that rear their ugly heads somewhere down the line?  Today’s drama involved the inclusion of a very cool fullscreen api by Vincent Guillou.  Of course, it worked great in development and then failed silently on production.  Here is an overview of what makes my production site a little different.

Production Site Overview

GoDaddy domain name hosting with option “forwarding with masking” —>—based hosting site

GoDaddy does this technically by serving up a single HTML page which simply frames the remote content.  By its nature, it uses the HTTP protocol and cannot use HTTPS. In its configuration it allows you to set either HTTP/HTTPS for the framed content, however.  You’d think that you would have plenty of room to make something work. And it did work just fine up until the latest add to the project:  a button which allows the browser to go full screen and back again.

Unfortunately, the first push to production then failed silently. The button was there but didn’t seem to work. Entering the development area of the browser I saw that the browser had to block the content because the framing page was HTTP and the framed content was HTTPS and this isn’t allowed.

Okay, so I thought I could then adjust GoDaddy’s settings so that I could frame the content as HTTP to match the parent document. Unfortunately I see that Firebase always uses HTTPS and does not support HTTP. Since I can’t mis-match the content and combined with the fact that I can’t easily promote GoDaddy to HTTPS on the framing page or demote Firebase on the framed page, I was screwed.

To make a long story short, I either had to pay for hosting at Firebase (which allows you to bind your domain name to their hosting server) or I could abandon the cool  feature. Since I’m trying to highlight the cool new features of the latest browsers I decided that’s it’s better to just pay Firebase in this case.

It was still a bit technical in getting all this to work since Firebase only bound a single entity (www) to the website using my domain. This means that if someone just puts in my domain name only then they’re stuck at a GoDaddy-parked page. To work around this problem, I set up a redirect to deal with this situation. This time it looked like: -> Problem solved.

So now, the cool new feature is working on production and the implementation is slightly simpler, not that anyone else would necessarily know.

royalty-source code

The Concept

Here, I’m coining a new term for the software development world.  Similar to open source software, royalty-source code would be widely available for download via a system like github.  Unlike open source, however, royalty-source includes a mechanism so that each coder gets paid as programs get downloaded.  This new mechanism should fairly distribute royalties based upon some sort of weighted system for each of the dependencies.

Typical Dependencies

The following tree shows a typical collection of dependencies pulled into a new Node.js program named MyNodeProgram, as an example, with the single command npm install mongoose:

  • MyNodeProgram
    • mongoose
      • async
        • benchmark + 22 other dependent libraries
      • bson
        • nodeunit
        • one
        • benchmark
        • colors
      • hooks-fixed
        • expresso
        • should
        • underscore
      • kareem
        • acquit
        • gulp
        • gulp-mocha
        • gulp-jscs
        • istanbul
        • jscs
        • mocha
      • mongodb
        • etc
      • mpath
        • mocha
        • benchmark
      • mpromise
        • etc
      • mquery
        • etc
      • ms
        • etc
      • muri
        • etc
      • regexp-clone
        • etc
      • sliced
        • etc

Doing a directory listing of your program’s node-modules subdirectory should then reveal just how much code got pulled from github with that single npm install command earlier.

Royalty Debt

Unlike open source coding projects, royalty-source coding projects add a new concept to the business model.  Royalty debt is the added virtual cost to your project with each npm install command you invoke.

If you envisioned charging $1.00 for each download of your own program and it now contains that mongoose dependency from before, you’ve greatly diluted your own code with the inclusion of this large collection of code that somebody else created.  If you created a typical Hello World program that uses a MongoDB database and assuming that you only add a few lines of your own code, then you might only get $0.01 of that $1.00 download royalty and everybody else would get the remaining $0.99 of that sale.  Without that mongoose inclusion, it would be unlikely that anyone would want to pay you $0.01 for your code, at least in theory.  You might then accept this 1% ratio as what it takes to make money.

Instead, you might start to rethink your entire program from the ground up.  If you could remove the mongoose dependency and store your data in a simple BSON object instead you possibly could drop that dependency completely and the royalty debt it incurs.  Assuming that you no longer had any other dependencies and people are still happy to pay the $1.00 price tag, 100% of that is now yours to keep.

One big benefit to this concept of royalty debt is that it should incentivize coders to review that stack of dependencies to look for anything that’s been included and yet which doesn’t add much value to the overall project.  The coder then should remove any unwarranted code to lower the bloat effect we often see in open source projects.  Smaller code is often better code.

Pay the House

Obviously, whoever is the new github provider will charge a commission of some kind for each download.  The download price minus the commission equals the total royalty to be split up.

Hopefully this system would include balances which would allow someone with existing credits to then use them to download other code.

Royalty Distribution

Presumably, a value system would be in place which weighs each dependency against the parent program’s code with some kind of fair distribution model.  As in the above Node.js example, the benchmark code appears at least three times as a dependency and should then get a bigger piece of the pie, so to speak.

New Tools

Given that we’d now have royalty debt to think about before adding a new dependency to our project, we should have some tools to quantify that cost.  In theory, you’d run the npm install command with an extra argument which quantifies that module’s package.json dependency list.  Let’s say that you might run the following command from your MyNodeProgram folder:  npm install mongoose --cost

At this point, npm might indicate…

mongoose @4.3.5:  Cost=$0.99/$1.00

Note that this is assumed to be a guesstimate at this time since your own program’s few lines of code were compared to the collective code and dependent modules of mongoose to return this ratio.

As a coder, you now have a build-versus-buy decision:  1) build your own database code instead or 2) expect to pay for mongoose (and dependent code) with each sale/download of your own code.

Pay the Piper

Obviously, it wouldn’t be fair to the coders of your own dependencies if you under-valued your own program.  If you decided to charge only one cent for your Hello World example above with all those dependencies, you’re distributing someone else’s code for a small fraction of what it would be worth otherwise.  In this system each module author should be able to define a minimum cost for their library.  As this code gets included into parent projects they should honor this requirement.

The benefit of this minimum cost feature is that it will gradually increase the cost of increasingly-larger code.  If the total minimum cost for the mongoose module is $0.33 then the next author must charge a minimum amount which factors this into the total download price.

Final Thoughts

So why should we bother with a royalty-source code system when open source seems to be working fine?

  1. We’re not getting paid to create software
  2. Everybody expects us to be responsive to their own needs (fixing bugs/issues) without considering that we normally expect to pay for services rendered
  3. Corporations are using open source code as a means of not paying software developers
  4. Other than a virtual tip jar, there doesn’t appear to be anywhere within the open source system where the coder gets anything for their efforts
  5. It costs a lot of money to pay rent, to eat and to otherwise afford a working computer and Internet connection as a developer


I suppose most of us these days have a github repository and this blog post would be the obligatory mention of mine.  I try to work on phone apps these days (PhoneGap) and Node.js backends every chance I get.

I can’t say that I’m very active on the open source side of things.  I only manage to throw down another version about once per week or so.  I find myself fairly ignorant of what goes on with respect to active multi-person open source projects—I only really have experience in bigger Microsoft programming shops on a Visual SourceSafe repository, for example.  And I have also used Microsoft Team Foundation Server as served up via the website from the Visual Studio program itself.

Outsource Guru on Github

I may start putting some of my older projects on there, time will tell.  I tend to select things that have a tutorial component to them so that I can demonstrate to others an intro to something.

Would I add a library to github?  At the moment, I don’t think so.  Libraries are useful to other open source coders but they’re also usable to corporations who are well-financed.  I’m usually paid to code so I think I’d like to be careful what I put out there for free.

A better github paradigm

What would be nice is if you earned credits with github for every download of your code.  And then you could spend these credits by paying for your own downloads on there.  Any individual without credits would need to buy them with money first if they wanted to download code.  If you could buy a credit for $1 then in theory you ought to be able to sell a bulk of credits for $0.75 each.  Github themselves would earn the difference since they’re hosting the platform itself.

And yet, it’s the norm these days for an average open source program to be made up of other open source code as dependencies.  So the crediting scheme would necessarily need to pay out fractional royalties to the people who created those dependent portions of code.  And so, if your own code is made up of 90% of other people’s code you would only see 10% of that credit and the rest would be distributed to them.

The benefit to a system like this is that a coder like myself—who’s used to getting paid to do this—gets paid for doing this.  Anyone who downloads code has to pay a credit from the balance on their account.  Having downloaded code they’re free to then use it.  And if they then re-bundle someone else’s code into their own then it’s become part of a commissioning scheme and everyone gets paid for their effort.

“The benefit to a system like this is that a coder like myself—who’s used to getting paid to do this—gets paid for doing this.”

An additional benefit to this system is that it no longer rewards the corporations who get a free pass to download unlimited code at your expense.

So the new system would work like iTunes, perhaps.  Maybe you could buy a card in a retail store with credits and redeem them on the site.  But if you created an account and uploaded a popular library then you could start earning credits almost immediately, in theory, anyway.

flogging a dead horse

Many times in my career I’ve been at some technical crossroads which demanded a decision on my part:

  1. stay the course with some primary skillset I’d been developing or
  2. branch off on some new expertise.

If you think about it, that’s a pretty big gamble.  What will hiring managers be looking for two or even five years in the future?  What will look better on your résumé, a couple more years of experience in the old skillset or the old skills plus the two years of the new skills?  Is it possible that continuing to work with the old skill will now somehow look bad for your career?  But then, if you include too many skills does it look like you’re not focused enough on anything to actually have expertise?

Recognize Trends

I’d suggest that the following trends are appearing in the development playing space.

  • Java is no longer trusted:  Oracle’s Java was a good idea back in the early ’90s.  It allowed coders to write one set of programming which could be compiled and then distributed and run on a variety of platforms.  Several security-related issues with Java have forced many to outright ban Java from workstations within organizations.  Apple’s Safari browser blocks the plug-in for Java now and Microsoft Internet Explorer in newer versions disables Java by default.
  • Objective-C is a pain:  Apple probably should have replaced this language when it introduced iOS.  Since it only really is used for Mac OS and iOS development, a coder’s skillset in this language limits them to just Macs, iPads, iPhones and the Apple Watch.
  • JavaScript is the new black:  Open source and Node.js have invigorated the JavaScript language.  In the past it was only really used for client-side browser validations and such but today, it’s being used for almost anything on the client or the server.  PhoneGap allows cross-platform phone app development in JavaScript, threatening to destroy all competitors in this space.  In Tolkienian terms, Javascript is the one ring to rule them all.
  • C and even C++ seem dated now:  C (circa 1972) and C++ (circa 1979) are wonderful languages and yet they’re over thirty years old and that makes them seem stale to coders today.  C# (circa 2000) is now over 15 years old and is beginning to feel the same fate.
  • .net is only for Windows:  Even though Microsoft had originally intended .net to compete with Java as a multi-platform coding option, you don’t see this in practice since nobody has worked on a UNIX .net platform to allow this to take place.  The trend would be that single-platform solutions don’t have enough market share to ultimately survive the test of time.
  • Every day there are more coders entering this space:  Schools globally have been pushing technical careers over the last three decades.  Outsourcing websites and better English training and translation software are allowing people in other countries to compete more effectively with U.S.-based coders.
  • It’s not just keyboards and mice anymore:  Hand-held devices, touchscreen monitors and see-through goggles may be the norm soon.
  • Apps and stores (not programs and major versions):  It used to be that a new version of a program was delivered and a major update cost money.  An app now usually comes with unlimited updates and yet “in app purchases” still allow a stream of money for the developer.  In fact, these updates allow the developer another marketing opportunity to up-sell the customer something else.  Apple has made so much money with iTunes that Microsoft has completely re-tooled their own operating system to chase that same business model.  Google has done the same with their Android platform.

See the Future

To me, the future of coding will embrace anything that will allow one set of (familiar) code to be compiled to multiple platforms.

  1. Until the next “new, new thing” comes along, it looks like Javascript (in general) is for now the core language to know.
  2. Some interesting things appear to be coming from the Javascript ECMAScript 6 (ES6) standard.  When a sufficient number of browsers support it, this new standard (specifically) should be another good skillset to have.
  3. Node.js has enjoyed an amazing degree of implementation throughout the world in its short lifespan.  Knowing how to code to this would be in your best interest.
  4. HTML5 has been used in a fair number of high-profile websites, enough to ensure its popularity for a few more years.
  5. The github source code repository has over 30 million individual repositories in place and has built-in support in many other systems which can pull code automatically from it.  It looks like github will be around for a while.
  6. Several popular languages will likely be effectively dead soon for a variety of reasons:  Java, Objective-C, Visual Basic, C, C++, .net and Swift to name a few.

Be the Future

If you want a job as a coder in the future it’s time to start actively steering in the right direction instead of just passively continuing to use the platforms you’re now on.  If you don’t have the skills I’ve listed above then consider taking on a project to learn one or more.

If you’re currently embedded on a team that uses Java, for example, then I’d suggest that it’s going to be increasingly harder to find work elsewhere. Given that it’s becoming harder to find coding work now with all the competition it’s more critical to possess the skills that managers are looking for on a team.

Adobe PhoneGap


In 2011, Adobe purchased an existing mobile application development framework by Nitobi, branding it at that time with the name PhoneGap.  They’ve since released it into the open source arena as “Apache Cordova” although many of us still refer to it as PhoneGap.  If you’ve ever attempted to create native iOS, Android or Microsoft Phone applications then you’ll enjoy this new multi-platform approach.

Before PhoneGap, you’d have to install a development kit for each of the various platforms you wanted to target.  And then, you’d need to learn the platform language of each major player:  Objective-C or Swift for iOS, Java for Android and XAML with C# for the Microsoft Phone.  Good luck trying to then design and maintain three completely-different collections of phone app code which hope to provide the same functionality.


But now with PhoneGap, you use what you probably already know:  HTML, JavaScript and CSS.  You then either 1) compress your collection of files using a ZIP file and upload this to Adobe’s website or 2) use the popular repository to manage your software changes and then tell Adobe the location of your github.

I’ll add to this that jQuery Mobile does a great job of streamlining some of the work you can do with PhoneGap.  It includes both methods for interacting with the browser’s DOM and a nice collection of CSS for displaying and lining up the widgets your app will need, for example, phone-styled push buttons that are sized correctly for fingers.


An initial set of app code is created from a command-line interface, producing a collection of files you’ll need for your app.  You’ll usually focus on two files within this collection:  config.xml and www/index.html.  The first will configure the name, version and rights that your app will need and the second defines the interface.  Use any editor you’re comfortable with.  And if you’re familiar with the github source code management then this can be useful later when you build your app.

You usually develop with the help of the PhoneGap Desktop App plus a phone-specific version of the PhoneGap Developer App.  The Desktop App reads your code and serves up a development version of your application; the specific Developer App for your phone will allow you to test your code.  As you make changes in your code the Desktop App will send the new version to your phone so that you can instantly see the change.

Up to this point, none of this yet requires any build keys from Apple, Microsoft or in the case of an Android app, your own self-signed certificate.  Since PhoneGap’s Developer App itself is signed, you’re good to go.


The default set of files from PhoneGap comes pre-equipped with the Jasmine test suite built in.  Edit the www/spec/index.js file to modify the default tests, verify that the PhoneGap Desktop App is running and then execute them by bringing up the /spec folder for your application within the PhoneGap Developer App.


When you’re ready to start seeing your application as a stand-alone app you can then build it on the PhoneGap Build website.

You have two choices for pushing your code to PhoneGap Build:  1) compress your files into a ZIP file and upload it or 2) use a repository for your project and tell Adobe that location.

Since phone apps need to be digitally-signed to identify the developer it’s then necessary to upload to PhoneGap Build one or more keys for this purpose.  An iOS app will need an Apple Developer key, a Microsoft Phone app will need a Microsoft Developer key and finally, an Android app uses a self-signed certificate that you can create without Google’s knowledge/consent or paying them a fee (as is the case for the first two platforms).  The PhoneGap Build website provides enough guidance in this area.

Once built, the PhoneGap Build website provides one or more individual binary downloads on a per-platform basis as well as a QR Code scan image that you can use to direct your phone to fetch the appropriate one.

what the fork?

fork noun repository

A copy of a repository’s master code, allowing one to freely experiment with changes without affecting the original.  This also includes a complete departure for the purpose of doing something differently from the original author’s design and sometimes without intent to merge code back into the original master branch.

The question for project managers would be “Is there a natural risk for open source software projects with respect to forking?”

Open source is wonderfully organic in that it grows like a plant.  Branches are created overnight, branches may or may not be maintained by others and some simply wither away.  Like plants, some software branches are buggier than others.  We acknowledge though that our own programs are made up of a collection of the code from these repositories.  At the moment of truth when we decide to include some particular bit of code we make a reasonable assumption:

Over time, I assume that this included code won’t change so dramatically that it no longer serves my own purpose or that it will break my own code.

Can we honestly take on that risk for our own venture given the usual number of dependencies in a typical Node.js project, e.g.?  Most open source code doesn’t de-evolve quite so destructively usually since it hasn’t reached a level of fame yet.  But for some code that enjoys thousands of downloads this necessarily means that many people now are suddenly very interested in the future development of that code.  And if this public forum is anything like the inter-department conversations of an average software development company then you may assume that different parties will have differing ideas about what that future should look like.  And this then is the risk that we take on:  In the future someone else may steer that dependent code in an incompatible direction from our own.

Size Matters

You’d think that each person in the open source arena would have equal say regarding future suggestions and modifications to commonly-used code.  I don’t believe that this is the case, to be honest.  Big players like Google actively participate in the world of open source.  Given their size and the number of developers they can throw at anyone else’s code they could easily steer development efforts into a direction which suits their own needs.  In a way, you would think that the world of open source would operate on merit alone.  The reality could easily be that open source is very much at the mercy of anyone with the wherewithal to dominate the playing field.

Adobe’s PhoneGap promotes Cordova behind the scenes for multi-platform phone development.  Given their level of commitment this will likely mean that over time competing technologies may not succeed.  If you choose the wrong technology you could abruptly lose support in the future when some dependent code author decides to hang it up and do something else.  Big players like Adobe can enter this space almost overnight and quickly change the playing field for everyone else.


The Fork in the Road

Personally, I use jQuery and jQuery Mobile in my own software.  What would happen in the future if somebody there at the jQuery Foundation decided to change up the fundamental ways that the interface works with PhoneGap, the development platform I’m also using?  I then find myself as the helpless passenger inside a carriage I’m not piloting suddenly careening down some path I didn’t envision.  Not only would my code break for some single build but I might then need to re-evaluate bigger decisions like platform and dependency selections.  It might be necessary to even consider throwing labor at jQuery development as an option.  If I do choose to depart from the direction they want to go then I necessarily lose support over time as a consequence.

It just strikes me as a long-time software developer that we could use some risk management strategies for what we’re taking on into our projects as these dependencies.  Is it then necessary to read outstanding issues on a per-dependency basis and to haunt those discussions?  I hope not.  I don’t think that the average coder would have that luxury of time on their schedule.