Earning Money with Open Source Software

With all the news about the decision of Sun to acquire open source icon MySQL, this reminded me of that particular thread in Slashdot regarding earning money with OSS. Before anything else, US$1Billion is definitely earning money (though still far from 8.5B ). Kudos to the MySQL team, more validation for FOSS being legit.

Aside from the typical support subscription, dual licensing, and other conventional direct business models for FOSS, there are also a lot of ways to earn from it indirectly. Off the top of my head, here are a few I can think of:

1. Open source software usually happens because people just need to "scratch their own itch." For companies and organizations, these itches may be quite different from the current scratchers. Now, reinventing the wheel would be a lot effort (and of course money). In lieu of that, you could always fork an existing open source project to fit your own philosophy, just so long as the license of course would grant you to allow that component to co-exist harmoniously with your proprietary offering. Earning in this case by saving.
2. An organization may open source core but general components of their product without necessarily releasing their specialized offerings to the public. For example, you may have a set of Javascript libraries that is not too specific for your product but not too general that it does not fit into a niche. Being general would give you enough shield not to divulge much of your secret sauce, but specific enough to target a cohesive set of problems which would give it more sense. Think GWT and how little knowledge the public has of the implementation of GMail. So if your open source components gets enough mileage and community support, the stability of the component would definitely enhance your product and, indirectly, your earning power.
3. You may need special tools to address your needs that aren't available yet (or those available aren't sufficient). You could spearhead an open source effort for this. If successful, this tool would hopefully make you more productive, hence more earning potential.
4. Finally, open sourcing parts or your whole product showcases your brilliance as a developer/development organization. The sheer reputation itself could be a great money making tool. Just make sure you do show brilliant codes and design. Quoting Law 5 of The 48 Laws of Power by Robert Greene: "Through reputation alone you can intimidate and win." This guy would've never been taken seriously, trying to slay a giant, if not for his reputation.
   

Problem Driven Exploration

Who could resist the charm of shiny new toys? The least is a few seconds distraction. At best, we just couldn't get them off our minds, we just can't not reach out and touch them. I guess that inner kid in all of us just would never go away. Always the explorer of new things. And guess what, this could be a good thing.

20-something Java developers like me are easily intrigued by the newer and the not so new toys the past months brought like RoR, scripting languages on the VM, REST, etc. Of course with the intrigue and the curiosity, comes time and effort investment. The curious "kids" invest in the hype, well at least speaking for myself. But how productive are these exploration activities? Would a Java developer be better off concentrating instead and improving his handles on the "toys" already in his command?

Point is, exploration has the potential for innovation. But, blind exploration would more or less rest that amount of potential on luck. And unsuccessful effort is tiring and wasteful. What we want is to lessen our dependency on luck and drive this inner yearning to a direction that would make us successful.

This brings me to one possible solution to this: limit exploration to possible solutions of pre-determined problems. Problem driven exploration, as I would like to call it. Simply, look for answers, not questions for those answers. Tools solve problems. It's really not very helpful if you have a tool but have no problem. And problems differ from one person or organization to another. If you have no personal problems with your Java MVC framework, then why bother with RoR? But, if XML is becoming a hassle for your specific situation, then time to explore on stuff like YAML and DSL's perhaps.

In this light, I guess it's very important how an individual or organization keeps their list of problems specific to their situation (last four words very important). For organizations in particular, I guess they would be doing themselves a favor if they are pretty transparent with their pin-pointed difficulties to their developers. Who knows, some kid in a tiny department might have all the zest to explore a solution for them?

Never let the inner kid in you grow old and boring. But take advantage by strategic control of that phenomenal behavior.