They added that before it does so, company officials have to be certain the move won’t lead to diverging paths in the code. I think this is a great move, and one that has been a long-time coming. Perhaps on a more interesting note, it will be interesting to see what Microsoft’s next move will be. I seriously doubt there will be one – which is a move in and of itself.

I’m not going to rehash the whole thing here in the blog. If you are interested in learning more, you can read a great feature story on this development over at Computerworld’s site.

Cheers.

To open source, or not to open source? That is the question that CIOs have been asking themselves for the better part of a decade. And while the argument for open source grows stronger every day, especially at the enterprise level, questions still remain. Being the new CIO doesn’t help either. You just never know what political minefield awaits you.

The other day I found myself sitting quasi-comfortably in an interview for a CIO position. This particular organization had a technology environment that wasn’t necessarily all that complex, but it was deemed mission critical to their operations. At one point in the interview, the CEO asked me the following question:

What are your views on open source versus proprietary/COTS (Commercial-Off-The-Shelf) software?

Generally speaking, before an interview, I will have researched the company, its technology, and its principals to the fullest extent allowed to me by the major search engines, my personal business networks, and other “valued” resources on the net (such as searching the major job boards to try to find some hiring profiles for their technologists – a great way to begin gathering intelligence about their business model and system architectures). Unfortunately, I had very little information on this firm’s technology platform, so my canned (but well thought out) answer to his question would have to suffice. There would be no tailoring and positioning this time around.

On the one hand, if you respond with something along the lines of “open source is great; I love it; it is the best thing since 32-bit registers”, you run the risk of isolating yourself if the organization has not embraced the open source movement. On the other hand, if you respond with “open source is folly, give me Microsoft or give me death”, you run the risk of being labeled something completely different, and again, isolating yourself. So, you have to straddle the fence, but you try to do so as intelligently as possible.

I also am very careful not to tread into the political side of the open-source debate. I view things primarily through the business-benefit prism. I could care less about people who use open-source solutions solely because they “hate Microsoft”, “want Bill Gates to slide under a moving milk truck”, or “believe that software should be free”. The “I hate the system” spiel is so 1967.

The following is a longer, more structured version of what I served up as my answer to that interview question, but the general tenets remain:

Implementing a solution grounded in open-source code is not something to tread into lightly, although it can provide certain benefits. However, the extent to which those benefits reach depends upon a wealth of criteria:

1. First and foremost, the obvious business prism questions. What business problem does an open-source tool solve? What inherent business benefits am I going to obtain by using it?

2. New system or existing? Are we talking about building a new system from the ground up with very few constraints, or are we talking about an existing system that is mired with them?

3. What is the company culture, at both the technology and management levels? Will the company’s culture support open-source?

4. Do you have the right skillsets in house, and the right mentality for open source? In other words, will there be a learning curve on the implementation side, or is this going to be a no-brainer for your staff?

5. What are the integration points with your customers (internal and external), vendors, partners, etc.?

6. What are the cost ramifications? What is the total cost of ownership of these systems? True, open-source software is generally freely available, but there could be hidden costs. This goes back to all of the questions above. For example, if you don’t have the skills to implement the solution in house, then there would inherently be some form of training cost, followed by opportunity cost. Or, perhaps services fees to a systems integrator.

7. On the other hand, in organizations where the company culture, the skillsets of the IT staff, and the business requirements are in line, open-source can represent a tremendous reduction in cost/COGS (cost-of-goods-sold) and development timeframes.

Satisfied with my answer, I looked at the CEO, patiently awaiting his response, or perhaps a followup question. Instead, he responded with:

Well, you should know that we are a .NET/C# shop, and that isn’t about to change.

Suffice it to say, he probably wasn’t thrilled with my answer, because in the end, it did leave the door open for open-source as a viable solution. I immediately responded with “but I’m not necessarily endorsing open-source as a panacea to solve all of your technology/business problems”, but I don’t think it did any good.

This particular fellow turned out not to be what I would call an “enlightened” CEO, at least as it pertains to the strategic deployment of technology.

An “enlightened” executive realizes that sometimes, in order to be agile within the marketplace, solutions need to shift. The landscape for technology changes each day – there is no such thing as a “long-term” solution anymore. Every solution we put into place has a half-life associated with it. You just hope that you make the right decisions that will lead to slightly longer half-lifes than those of your competition.

What say you? Share your thoughts on the open-source decision by using the comment form below! No registration is necessary, but all comments are moderated to prevent spam.

Cheers.

First and foremost, there is the obvious issue of bandwidth. Obviously, running a web server over a Bluetooth network is a moot point, given that any clients making web requests would need to be within 10 feet of the web server. Even if both devices were running “high-powered” Bluetooth connections, the range would be around 100 feet – still not viable. Wi-Fi connections partially solve the connectivity issue, at least as far as “range” goes. However, Wi-Fi connections over a cell phone (at best) cap out at around 500kbps (kilobits per second). That’s pretty measly when compared to what you’d get in a data center running at 54mbps (megabits per second) or higher. So the bandwidth for anything other than low-traffic installations is simply not there.

Second, there exists the second obvious issue, which is availability. I live in metro Atlanta where cell connectivity is considered to be pretty advanced. However, there isn’t a day that goes by where I don’t lose cell phone connections due to dead spots or interference. Imagine someone standing in your data center randomly pulling the plug on your servers, making all of your clients lose connectivity. That’s basically the situation we’d have with running cell phone based web servers, as your “web server” would move around among the jurisdiction of various cell towers.

Third, one must consider the issue of security. How will firewalling work? What sort of “phone” exploits would this open up? Can you imagine cell phone based worms that spread via HTTP requests to ill-behaved CGI scripts? And what if that worm decided to “harvest” all of your phone/PDA data, such as names, numbers, appointments, etc., and emailed those to some arbitrary source? Pandora’s box comes to mind. Frankly, I think if you run a web server on your cell phone, you should no longer be allowed to call it a cell phone. You should simply refer to it as your Pandora’s Box.

Fourth, we must examine content. Most useful content that exists on the web is the result of a complicated dance involving application servers, content management systems, database systems, and other components. Static content is becoming hard to find on the web. Porting Apache to a cell phone would merely allow you to serve static content. To get to the dynamic stage, you’d also need to port things such as MySQL/Oracle/Postgres, PHP/.NET/ASP/Perl/Ruby, and a host of other tools. Not gonna happen.

Next, we would be remiss not to examine computing capability. The PDA functionality in newer cell phones already pushes the limit of most cell based processors. Palm’s new Treo 700w smartphone, one of the more advanced phones on the market, is equipped with an Intel® XScale™ 312MHz processor. The last time I had a “server” that ran anywhere near that speed was an old IBM 386 MHz PC, which really struggled to run a single line dialup bulletin board system. Apache has a relatively large footprint, especially when you start getting into the realm of compiling in additional functionality (see content above). The horsepower just isn’t there.

In 2004, an estimated 715 million cell phones were shipped to consumers. That number is clearly higher now. I’m not even going to get into what ramifications this would have on IP addresses and namespaces. Even with the advent of IPv6, which could easily support it, the logistics behind it would be staggering.

Finally and far more importantly, why? Why on god’s green earth would you want to run a web server from your cell phone? Cell phones, by their very nature, are mobile devices. They are ideally suited to be clients, not servers. Cell phone based web servers, IMHO, do not solve any known enterprise problem, and offers very little in the way of innovation. I’m sure if we worked hard enough, we could probably port Eric Allman’s wonderfully arcane and useful sendmail to cell phones. But that would also be pointless.

The world is full of really hip software ports. Some are actually quite useful. For instance, being able to edit Excel, Word, and Powerpoint documents on my Treo 650. That’s useful. Being able to use my cell phone to establish an SSH connection to a remote server and being able to work on it – another useful software port.

Then there are the pointless ports. From Linux running on the XBox to most everything you’d want to put on an iPod. Running an Apache web server on my cell phone ranks right up there. Cool? Yes. But pointless all the same.

To be more than just “cool”, a port needs to have (a) a viable use, (b) a sustainable environment (in this case, bandwidth and availability), and (c) demand. Running an Apache web server on my cell phone offers none of the above.

I suppose that in 20 years, when the data center is a thing of the past, and even the most transaction-heavy web sites are being easily facilitated by the latest and greatest in mobile devices, I will eat my words. But for now, I think I’ll stick to my 2U rack mounts …

Cheers.

SugarCRM was founded in 2004 by CEO John Roberts, GM Clint Oram, and CTO Jacob Taylor. Since their founding, they’ve grown to a respectable 55 employees. In 2004, the same year of their founding, the company scooped up Communications Solutions 2004 Product of the Year Award. Not shabby.

The core product (SugarCRM Open Source) is freely available, so if you are running a business, you are able to download and implement the system without any software license costs whatsoever. This core offering serves up a lot in the way of functionality, including integrated contact managment, marketing campaigns, opportunity management, project management, lead tracking, account relationship management, web portals, integrated shared calendar, and RSS syndication. A nice “dashboard” metaphor brings all of the elements (and others) together nicely.

SugarCRM is also offered in 2 different commercial editions. The SugarCRM Professional edition adds additional features such as team management, MS Outlook integration, wireless access, sales forecasting, catalog management, and quoting. Among other things, the more robust SugarCRM Enterprise edition adds support for Oracle 9i and 10g on the database side, as well as some access to professional services and dedicated support services. If you want an easier path to going live, they also offer hosted solutions on a per-user basis.

SugarCRM (the company) gets open source. They realize that in order to be successful as an open source company, you basically have a very limited playbook. You offer a freely available core product, that is distributed via the open source license, and you grow your revenue streams around licensing for more advanced versions of the product, as well as professional services. If I’ve said it once, I’ll say it again: open source businesses are essentially services companies. (See: Software, Services, and Revenue, Oh My!).

From an architecture standpoint, SugarCRM is built around the wildly popular LAMP stack (Linux, Apache, MySQL, and PHP). The LAMP stack represents a fast growing open source enterprise software stack that more and more companies are using as an alternative to expensive proprietary software stacks (because of its lower cost and freedom from lock-in). While it is nice that the Enterprise edition will function with an Oracle database, it certainly isn’t required to achieve very respectable performance results. MySQL has come a long way from its early days – far enough, in fact, that Oracle acquired Innobase, a key technology provider to MySQL AB, the Swedish firm that produces and distributed the MySQL database engine.

While all of this sounds great, what really sets apart SugarCRM, in the opinion of this veteran technologist, is the fact that the leadership team has completely immersed aspects of online community building within their portal site located at SugarForge. Through the service at SugarForge, users are free to download and share themes (look and feel modifications), language packs, custom plugins, and other information. Also supported are support forums, a project lead database (mined by custom CRM implementors and service providers), and even a live chat (there were 8 or 9 folks in there a second ago chatting about customizing various aspects of the SugarCRM product).

From a cost perspective, there is simply no contest when you start laying out the numbers. According to Corra Technology, an open source software integration services firm, SugarCRM is over 6.5 times less expensive from a total cost of ownership (TCO) standpoint, when compared to rival salesforce.com:

Should Oracle, Seibel, et al, be scared? Not yet. The open source CRM movement is still creeping up from smaller companies to mid-size firms. Eventually, though, it is entirely conceivable that SugarCRM could exert some upward pressure on the aforementioned bellwether players, in much the same manner that MySQL put upward pressure on rival database maker Oracle within the enterprise database market.

Should salesforce.com be scared? You’d better believe it.

The future looks bright for SugarCRM, especially given their unique positioning at the nexus of the CRM wave and the open source movement, as well as their marquis capitalization via Draper Fisher Jurvetson, Walden International, and New Enterprise Associates (NEA). These are storied, lynchpin investment firms, and they made the decision to jump into the enterprise open source market for a reason.

Cheers.