Why isn't your Angular Application Open Source?

I love Angular. It’s a great client-side MVC framework. One of its major issues is a lack of understanding of how to put together an Angular Application, and the documentation is no help there.
They tried to improve by including a reference application (app), but… Well…

App Structure level: 2legit
App Structure level: 2legit

The problem with reference apps is that they’re not actually being used. Here’s the difference between the two:
Reference App

A real world application

It doesn’t have to be this way.
You can open source your Angular project.
There are traditional arguments against Open sourcing proprietary applications; but I argue that none of those apply here.
It’s our proprietary code: It was, before you released it as an Angular application. Now anyone can see the entire source code of your project. Even if you minify it, they can still see it.
It’s got our secret sauce in it: It probably shouldn’t. You should move any proprietary algorithms or methods to the server side, and expose the result through the API.
It’s not very good!: That’s ok. Any app that has real world usage is useful to see.
Someone may find a vulnerability: That’s good! They’ll let you know there’s something wrong
What if our competitor sees it?: Since (by their nature) JavaScript applications are available to the client; it’s likely if they cared about it, they’d already have copied it. You don’t have a source problem, you have a legal problem.
The source code is a mess! It’ll take us weeks to get it ready: Every company has a period of downtime. Business rarely goes full tilt 24/7. Use one of those periods between product launches to schedule this work. It’ll let your developers relax and recoup after a hard push.
I don’t want to accept patches: That’s your right. It’s not exactly the smartest move, but putting the source code on Github doesn’t mean you have to accept other people’s patches.
With those aside, let’s look at the positive reasons for open sourcing your Angular Application:
Community respect: People are more likely to trust someone they perceive as honest and open. Open sourcing your Angular app (That’s already ‘open’ anyway) gives you a net positive with little to no downside
More eyeballs: It’s more likely someone will uncover a bug, and in the spirit of community, they may even issue a pull-request with a fix.
Learning: Everyone learns when they open source something. The people who do it, and the developers who will see the code. Putting the code out there ensures that there are better examples of how a real world Angular application is structured.
Recruiting tool: You may have unlimited vacation and free lunches, but one of the things that developers really care about is being on the cutting edge and have the ability for everyone to see what they do.
Open source your angular app. There are lots of reasons to do it and very few reasons not to.

The Heartbleed Bug, for the rest of us

This morning while getting reading for work I heard Fox 5 news talk about the Heartbleed Bug. Fox business correspondent Lauren Simonetti referred to it as the “Heartbleed bug virus.” Since it’s a live segment, I figured it was just a verbal gaffe, so I double checked against the recorded segment she does daily for Fox Business:

“Today is the day to refrain from online banking and plugging other sensitive information into the web. That’s because security experts have found a virus called the “Heartbleed bug.” It attacks the software used to provide encryption of 2/3rds of all servers on the Public Internet.” (emphasis mine)

It’s easy to make light of non-techie explanations of software problems, but the blame really is on us. We don’t do a great job of non-technical explanations. If you’re looking for a technical explanation of Heartbleed, here’s one.
For the non-techies among us (especially news anchors), I’ll try to provide a good non-technical metaphor for what the Heartbleed bug is.
The Heartbleed bug is a software bug, *just like any other software bug*. The term ‘bug’ may be confusing here, but we mean a bug to mean a defect in a line of code somewhere, causing the software to behave in a manner that wasn’t intended by its author. They’re named ‘bugs’ because the first computer software error *was literally caused by a bug in the computer*.
It’s called “Heartbleed” because programmers love cute names. I haven’t actually found a credible source for its naming, so I default to the ‘cute’ reasoning. It’s accurate in general, if nothing else.
In human terms, viruses are referred to as ‘bugs’. They’re often used interchangeably, as in “Thanks for giving me that bug that’s going around.”
In software terms, they mean completely different things.
A virus is a piece of software *intentionally* written to infect computers. They can do many different things, from turning on your web cam without you knowing to just being really annoying.
Bugs are *unintentional* defects in software.
In the case of the Heartbleed bug, the defect is the digital equivalent of you leaving your house unlocked for two years in plain view of everyone in the world, and them able to get into your house, listen to your conversations, watch everything you do and record absolutely everything you’ve looked at on the internet for the past two years, while you were looking at it2. Any website, any financial transaction, anything. All without you knowing.
Normally you’d just change your locks, but that wouldn’t help you here. They have the digital equivalent of a skeleton key to 2/3rds of the locks in the world1. Until the company that makes the lock revoke the skeleton key and issues a new one, there’s nothing you can do. Changing your locks won’t help until then.
That’s how serious this software bug is. In your daily travels on the internet, I can guarantee at least one site you use is affected by it.
So what can you do?
– Don’t log into your bank or any sensitive site until they’ve confirmed that they’re not affected by this bug, or they’ve issued new SSL certificates for their site.
– Change your password for each site *after* it has revoked its security certificate.
– Never use the same password on two sites. If you do, at least make sure your bank and other sensitive sites have their own passwords that aren’t used by any other site (or used on each other).
– Follow these helpful instructions to make sure Chrome looks for certificate revocations:

To leave you with a bit of levity and to put this gaffe in context,
It’s not as if this is the first time a news anchor has made a technical gaffe. It’s even pretty low on the scale: The king of all tech gaffes would have to be Katie Couric and Bryant Gumbel’s hilarious description of what an email address and the internet is.
[youtube http://www.youtube.com/watch?v=JUs7iG1mNjI&w=640&h=390]
1: Techies will note that I’m conflating terms here between the skeleton key (SSL certificates) and your house lock (your password). Sometimes there just aren’t non-digital equivalents, so we make do.
2: Heartbleed allows the attacker to see 64K of what’s in memory at the given moment of attack. This is trivial to automate.