Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

August 25 2011

Five things Android needs to address on the enterprise side

My lovely cubicle by ashley_dryden, on FlickrAndroid has the foundation to support enterprise use, but there's a handful of missing pieces that need to be addressed if it's going to fully catch on in the corporate world. Below I look at five enterprise areas that Google and third-party developers need to work on.

Managing the device fleet

A typical enterprise needs to have a way of managing a fleet of devices, whether personal or company owned. There are currently a number of vendors providing solutions to this problem, including 3LM, Good Technology, MobileIron, and Sybase.

What needs to happen: Google needs to help create a standard for a complete enterprise Android solution, or it must support one from a third party. Until recently, the closest candidates were the Motorola Droid Pro and Photon lines, but Google's planned acquisition of Motorola could yield a full enterprise option. Keep in mind that Motorola already owns 3LM, one of the leaders in Android security solutions.

Enforcing security policies

CIOs need to enforce their security policies, and they also want to be able to wipe a lost or stolen device. Android does provide the plumbing for most of this work and third-party vendors are starting to create solutions on top of it, such as Motorola's Enterprise Device Policy Management API and related MotoBlur solutions.

What needs to happen: This market is getting fragmented, and CIOs will need to do their own research for the right solution for their particular enterprise.

Securing connections to enterprise networks

Most corporate networks are secured with either SSL or VPN solutions. Android supports both, at least on paper. The problem is that corporate America typically uses proprietary VPN solutions from vendors like Cisco and Juniper. That means that most Android devices do not offer any useful VPN options to corporate users. This is a big issue that is slowly being addressed by device manufacturers. Companies like Samsung are entering into licensing agreements with the Ciscos of the world to make sure enterprise-grade VPN is part of their Android product lines.

What needs to happen: Carriers or OEMs need to bundle the right VPN solutions with their devices. We're starting to see this with certain Motorola models on the Verizon and Sprint networks.

Android Open, being held October 9-11 in San Francisco, is a big-tent meeting ground for app and game developers, carriers, chip manufacturers, content creators, OEMs, researchers, entrepreneurs, VCs, and business leaders.

Save 20% on registration with the code AN11RAD

Sandboxing apps

I often hear IT people say they want to control the types of applications and content users can download to their company phones. While it's possible to wall off a company-issued device, it's an expensive strategy that creates a false sense of security. A better approach may be to allow coexistence of both corporate and personal applications on the same device. Android already provides solid application sandboxing, which isolates data so each app has its own data privacy.

What needs to happen: IT departments need to provide enterprise-grade apps for enterprise data. Those departments must also get used to corporate apps coexisting on devices with consumer apps. A good example of enterprise apps is Google's Apps for Enterprise cloud solution and its mobile counterparts, such as GMail, GTalk, and Docs.

Trusted markets for business apps

Google's Android Market is based on reactive testing that basically crowd sources quality assurance. That model won't cut it for corporate clients. The rise of enterprise-friendly boutique markets, like Cisco AppHQ, could provide the needed alternatives for enterprise adoption.

What needs to happen: The free market needs to work its magic. Multiple app stores are a good thing, and eventually consumers will know which brand to trust for certain types of applications. Google could help the process by allowing other stores to list their apps on Google's Android Market. Carriers could also pre-load multiple store apps.

The future of Android in the enterprise

While Android doesn't come with all the enterprise bells and whistles, it's built on a strong and secure foundation. And while Google needs to do more to provide the missing pieces, the company has created the infrastructure for other companies to step in and fill out Android's enterprise offerings. The strategy appears to be working, as research has found Android to be gaining adoption within corporate IT departments. As more employees bring Android devices into their offices, and as Android's corporate offerings mature, I expect enterprise acceptance to accelerate in the years ahead.

Background Photo: My lovely cubicle by ashley_dryden, on Flickr


August 13 2010

Open source givers and takers

Dana Blankenhorn's recent ZDNet blog points to Accenture's "hockey stick for open source" and notes that while 69 percent of the companies Accenture surveyed plan to increase their open source investment in the next year, only 29 percent plan to contribute back to the open source community. That sounds very plausible. But is it a problem? I'm not so sure.

First, I don't think "all take and no give" is a failure. Or even a problem. If you're giving, you shouldn't be surprised if people take. If you're taking something that's been freely given, you shouldn't feel obliged to give back. If you do, that's great. And if you're a giver, you should be glad that people are taking, whether or not you're getting something back in return.

Second, "how many companies plan to contribute" isn't the right metric. One of the things I've learned from my involvement in industry is that the most successful and effective groups are small. The right metric is "are there enough contributors to move the project forward?" For the key projects (like Apache), clearly the answer is "yes." "Enough" is much more important than "how many." The last thing we need are projects that slow to a crawl because of the bloated development-by-committee that characterizes many corporate environments. In the late '80s, I worked for a startup that developed (among other things) a FORTRAN compiler. We sent our 10-person compiler group up to DEC for a meeting, where they found out that DEC's FORTRAN compiler group had 2,000 people. DEC couldn't understand how we got anything done. More to the point, our guys couldn't understand how DEC got anything done.

Further, I suspect that the extent of corporate contribution is significantly higher than this study reports. Twenty-nine percent is probably correct if you define "corporate contributions" as "contributions made by employees while sitting at a company desk and on company time." A better measure would be "contributions made by someone who develops or uses the software as part of his job." The software is used on the job, but the contribution is often made by the individual, at home. But that's hard to measure; it's not what the projects are set up to track. And yes, it would most likely be better if these guys were compensated for their work. In many ways, they're the heroes of the open source movement. But that brings us back to my first point: what was freely given may be freely taken.

The level of corporate contribution would almost certainly be higher if you limit the question to corporations that have something to contribute. I don't mean that facetiously. Apache is probably the most widely used open source project in the corporate world. How many corporations have actually modified the Apache source code to add a feature or fix a bug? Very few, I'd bet. They use it "off the shelf." And if you haven't touched the code, contribution is a moot point. And that's just fine.

There's one more issue worth considering. If you look at any open source project hosting site, such as SourceForge, you'll notice a few projects that are successful, and a much larger number that have clearly failed: "abandonware." Maybe they once served a purpose (like getting a dissertation finished), but they're buggy, incomplete, and stagnant. Could these projects have been contenders, and if so, what went wrong? It seems to me that projects fail for three primary reasons: bad project culture, poor source code base, and "not really needed." The project scratched someone's particular itch, but not enough people had that same itch.

Would corporate backing have allowed some of these failed projects to survive? Maybe. Corporate projects frequently have culture problems, bad source code, and poorly-defined markets. So it's not clear that corporate participation would be a huge win. I'd really like to see a good study of failed open source projects: what, why, and how. I think we'd learn a lot. And one question worth asking would be whether more corporate involvement would have helped the project to survive (and whether survival would have been a good thing).

To put this in a specific context: much has been written about RedHat's significant contribution to Gnome, and Canonical's much smaller contribution. But that's not the right issue. Would Gnome be better (or some definition of "better") if it had 20 percent or 50 percent or 150 percent more contributors? That's not clear to me. Blankenhorn's comment is right on:

Everyone is free to take just as everyone is free to give, and that is what makes the idea powerful. GNOME is far more valuable to Red Hat than a Red Hat UI could ever be, because it's open source, because it's a commons.

That's precisely the point.

I certainly don't want to discourage any corporation from contributing to the open source community. There are many projects that do need help, many projects that could profitably be started, and many sites willing to host them. And I agree with Blankenhorn's larger point: that by engaging with open source projects, companies engage with their customers, their competitors, and people who can help.

Although giving back to the community is an option, it's a good option, and something from which corporations can profit. But before we gauge corporate participation in open source, I think we need better metrics than the ones Accenture is using: how many projects need more committers, and where are the committers coming from? How many companies have employees who work on open source projects on their own time? And how many employees work on open source on company time, unbeknownst to the managers who fill out Accenture surveys?

September 04 2009

Trevor Potter and Floyd Abrams

Is campaign finace reform unconstitutional?
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
No Soup for you

Don't be the product, buy the product!

YES, I want to SOUP ●UP for ...