Opening up a can of source: Open Source Pros and Cons

One of the more interesting decisions I think an individual or organization can make is whether or not to make their software open source.  Here are some factors I've been going over that I think make the difference.


Open source lends itself best to the very easiest and very hardest problems.  The very easiest will get implemented by competitors anyway, so no advantage is kept by proprietary source.  The very hardest are beyond the scope of most teams, crowd-sourcing is a major help for these projects.  Configuration scripts might be an example of the former, research projects the latter.


Open source works on no budget, or more accurately donated time budgets.  Proprietary code rarely works under that environment.  Proprietary code is boxed in by budget, so your code must be justified by the financial returns.

Time Frame

Is your code timeless?  Do you expect it to be used far into the future?  Then it may be a good fit for open source.  The longer you are in development, the more dividends crowd sourcing can pay.  The longer your solution is useful, the more likely someone else is going to develop a similar solution.  Open source also let's your users update it themselves after you've dropped official support.  Proprietary code instead trades on users needing a solution "now" for the problems they have "now".  Support of proprietary code is only provided as long as it provides a good rate of return.


Are your users developers, system administrators, or highly technical?  Is your user population very large or very small?  If your users are effective contributors (in development or testing) then open source is going to get a super charged crowd sourcing effect.

If your user population is very large, then crowd sourcing still is in effect even if average contribution per user is low.  Large user populations also attract competitors, which can be hard to fight off without network effects of obtaining a large user base.

Very small user populations are difficult to monetize.  Even if the your company generates some advantage from internally developed niche applications, it might still be useful.  You might generate more by getting contributions from other niche users who don't compete directly.  You might open up new business strategy by lowering the cost associated with maintaining the code.  Finally, if your internal project is behind the market leader open source may help you achieve parity at a lower development cost.

Final Thought

There are better explanations of the pros and cons of open source, but I hope you've gotten something out of mine.  The most important factor of all of these is time.  When development time is plentiful, open source thrives.  When you start running against some constraints, proprietary code begins to make sense.  If you box your development constraints in too far however, proprietary code no longer makes sense.

A recent argument I had: Math in Programming

A friend pointed out the following quote from the blog post linked above.
I'm not sure how this stereotype got instilled in me, but I'm slightly embarrassed to admit that I was surprised to discover how little math is involved in day-to-day programming, especially for a web developer. A command of the written word is far more important. Intelligent, clearly-articulated prose is probably the most significant goal for both writers and programmers alike.
The math I do regularly is much more similar to the logic truth table exercises I learned in ninth grade than the complex algorithms you hear mentioned so frequently by programmers. Knowing whether an evaluation is true, false, or nil and how my programming language specifically treats each state is the extent of the "math" I do regularly. Occasionally I've had to calculate discounts or sales tax, but that's less mathematical than managing a cash register at a restaurant.
Besides, computers are way better at math than you are anyway. By learning to program, you'll learn to let them handle it for you.
Now there is clearly some truth in this quote.  I haven't felt the need to pull out a trigonometric or  calculus equation during my short professional programming career.  Unless I start doing something geometry related I might never do so.  Command of natural language is probably the most important skill anyone can develop.  The rest of the blog post is truthful as well.

But I don't agree that with the subtext of the quote that math class stopped being useful at ninth grade or that math programmers do regularly isn't complex.

I apply college level discrete mathematics and logic coursework to my programming everyday. Do I break out the formal notation? Sometimes, but unfortunately not usually. However, just because I use informal notation (pseudo code) or work out the problem in my head doesn't mean I didn't do any math.  It just means I didn't properly show my work.

I think the mathematical logic I use is fairly complex and took a fair amount of time to obtain my current level of mastery. Set operations and data transformations in singular instances are well within the purview of laymen. Chaining multiple instances of both is something that takes some practice. You may not understand the formalities and rigor, but you do develop a feel for discrete mathematics and logic as a programmer.

You could argue that set operations and data transformations can be abstracted away. That the remaining model is simple, no complex math required. I'd say you were fundamentally wrong.

Abstractions are a tool to manage complexity, not reduce it. Complexity of a problem is constant with respect to static requirements.  The complexity of the solution may change, but the required inputs and outputs remain the same.

If I have 1,000 set operations required to come to a desired result (output), it is decidedly more complex than a program which requires only one.  Even if I abstract the 1,000 down to only a handful at any time complexity remains.  Logic is not constrained to individual IF blocks or JOINS. It is the entire sets of possible input transformed into the entire sets of possible outputs that define the program.  Your program may give intermediary output in the duration, you may have abstractions to conceptualize layers or components of the system, but fundamentally you are operating on a state machine at there beginning and an end (or cycle).

That is not to say that abstractions don't have a place in every programmer's toolbelt.  It just happens they do because they are a powerful application of discrete mathematics and/or logic. For example, chunking a large set operation into manageable pieces is discrete mathematics.

Example: Login
((E U P) ^ R) ^ S = A
((Email Union Password) Intersect Users) Intersect Session = Authenticated Session

Authenticated Session is an abstraction. This abstraction will be used later in other set operations, probably in and on other abstractions. Together they will form a complex mathematical construct, even if you never think about them that way.

Example2: Login with additional abstraction
E U P = C
Email Union Password = Credentials
(C ^ R) ^ S = A
(Credentials Intersect Users) Intersect Session = Authenticated Session

The complexity of the problem has not changed (mapping of inputs to outputs), but the additional abstraction allows us to mange the complexity.

I hope the above is suitably demonstrative of applied discrete mathematics in programming. I would think most programmers could have arrived at the solutions by intuition, that is to say do it in their head or by instinct.  I'd argue this is because they are very good at discrete mathematics.

The point of my argument is that my formal education in computer science placed an emphasis on discrete mathematics and logic, which are true mathematic disciplines. While I do not employ the rigor or formality, the concepts are very useful in my work.

My other point is that I use these types of complex math *all the time* in programming, even when I do not explicitly show my work.  Don't sell yourself short as mathematician if you are a programmer.