El municipio de Los Angeles vota Google

Un primer paso importante de Google por lograr una porción en el mundo de los negocios y el Estado: el municipio de Los Angeles, en California, acaba de contratar su sistema de aplicaciones de oficina, luego de un año de lucha con otros competidores, que incluían a Microsoft.
En ZDNet, escribe Sam Díaz:

The Los Angeles City Council today voted unanimously to “Go Google,” approving a $7.25 million contract to outsource the city’s e-mail system to Google’s cloud and transition some 30,000 city employees to the cloud over the coming year, according to a report in the Los Angeles Times.

Clearly, this is a big deal for the city of Los Angeles. But this vote is also monumental for cloud computing as a whole, which has gained popularity and widespread interest but still relatively little adoption as companies - and municipalities, apparently - weigh the anticipated cost benefits over the unknown risks that might come with system failures or data breaches.

The stakes are also high for Google, which has stepped up its campaign for Google Apps, its cloud-based suite of offerings, by highlighting how companies who are fed up with breakdowns and costs of maintaining old legacy systems finally decided to “Go Google.”

Both Google and Microsoft had put in bids for the city’s contract and, at one point, it seemed to be a showdown between the two, representing a bigger winner-take-all battle between old school systems and 21st Century cloud systems. In a post last month, I suggested that a win for Microsoft would show that Outlook and Exchange are still big players and that a win for Google would show that the cloud is ready for prime time.

This doesn’t necessarily mean the beginning of the end for Microsoft in this space. Los Angeles is just one city on this planet - and it’s only 30,000 city employees. But Google clearly has its sights set on the enterprise for the next wave of growth, even to the point that it could overtake - or nicely complement - the advertising business.

At the Gartner IT Symposium 2009 in Orlando earlier this month, Google CEO Eric Schmidt said the largest number of seats for Google runs about 30,000 users and that goal right now is to gain users for its enterprise apps. He sees the enterprise as “humongous,” a multi-billion dollar business that has real potential. By Gartner’s calculations, enterprise accounts for about 3 cents of every dollar that Google makes, leaving plenty of room for growth.

That growth could come from the countless other municipalities, agencies and companies that have been toying with the idea of a move to the cloud but have held back, waiting for someone else to jump off the cliff first.

Los Angeles Times agrega:

The Los Angeles City Council voted unanimously today to outsource its e-mail system to Google Inc., making it the largest city in the nation to make the move and handing the Web search giant a major victory in its quest to become a software provider to the world's cities and businesses.

After more than two hours of debate, council members voted 12-0 to approve the $7.25-million contract that would move all 30,000 city employees to Google's so-called cloud over the coming year.

"The City of Los Angeles, the second largest city in the nation, made a world-class decision today to support a state-of-the art e-mail system," said Councilman Tony Cardenas, who made the motion to approve the Google system.

[...] The vote today ended a nearly year-long process during which Google competed furiously with other software vendors, including rival Microsoft Corp., to secure the city's valuable stamp of approval. Parties on all sides believe that if smaller cities see Los Angeles successfully transition to Google's cloud system, they may be more likely to follow suit.

Si bien la votación fue unánime, previamente se expresaron dudas, aquellas que la computación en la nube mantendrá por largo tiempo, desde el punto de vista de la privacidad y la confiabilidad:

Before the vote, several council members had voiced objections to the contract, including whether the city would see any real cost savings, as Google had contended, and when the new system would be ready to store data from law enforcement, where security standards are more rigorous.

Because Los Angeles will be among the earliest adopters of the Google system, council members expressed concern that the city might be signing on before Google's cloud system was fully proven.

"It's unclear if this is cutting edge, or the edge of a cliff and we're about to step off," said Councilman Paul Koretz.

Para usuarios de Plex en castellano: accesibilidad al foro de CA

Para aquellos usuarios de Plex que prefieren hacer consultas a través del foro de CA en español, deben tener en cuenta que se ha restablecido a su ubicación anterior. Su dirección actual es en el mismo sitio de los destinados a desarrollo de aplicaciones: http://caforums.ca.com/ca/board?board.id=CAplex2eespanol

Apuntes sobre Factorías de Software, II

De lo comentado antes, queda la impresión de que durante la época temprana del desarrollo del software, múltiples líneas de acción tendieron a darle sustento sistemático a su concepción y construcción, y en este contexto, la idea de aplicar el concepto de factoría fue una vía consistente de trabajo; primero iniciada en Estados Unidos, luego tomada con fuerza por Japón, y finalmente continuada en Europa. Tanto M. Cusumano como Y. Matsumoto señalan la conferencia de la NATO sobre Ingeniería de Software en 1968, como el punto de partida de los intentos de construír el software a modo de una factoría desde la Ingeniería de Software.
Ya se habló de Bob Bemer y M.D. Mcllroy, cuyos antecedentes se remontan a fines de los 60, y cuyas afirmaciones van en el sentido de mejorar procesos y procedimientos, medir, estandarizar herramientas de productividad, y establecer técnicas de reutilización del código.
Cusumano recoje a Mcllroy sobre reutilización de código, tan temprano como 1968:

The most important characteristic of a software components industry is that it will offer families of routines for any given job. No user of a particular member of a family should pay a penality, in unwanted generality, for the fact that he is employing a standard model routine. In other words, the purchaser of a component from a family will choose one tailored to his exact needs. He will consult a catalogue offering routines in varying degrees of precision, robustness, time-space performance, and generality. He will be
confident that each routine in the family is of high quality--reliable and efficient. He will expect the routine to be intelligible, doubtless expressed in a higher level language appropriate to the purpose of the component, though not necessarily instantly compilable in any processor he has for his machine. He will expect families of routines to be constructed on rational principles so that families fit together as building blocks. In sort, he should be able safely to regard components as black boxes.

[Citado por Cusumano en The Software Factory: Origins and popularity in Japan: M.D. Mcllroy, "Mass Produced Software Components," in Peter Naur and Brian Randell, eds., Software Engineering: Report on a Conference Sonsored by the NATO Science Committee, Brussels, Scientific Affairs Division, NATO, January 1969]

En este y otros papeles, Cusumano recoje a Bemer sobre métricas y factorías:

[A] software factory should be a programming environment residing upon and controlled by a computer. Program construction, checkout and usage should be done entirely within this environment, and by using the tools contained in the environment... A factory... has measures and controls for productivity and quality. Financial records are kept for costing and scheduling. Thus management is able to estimate from previous data... Among the tools to be available in the environment should be: compilers for machine-independent languages; simulators, instrumentation devices, and test cases as accumulated; documentation tools -- automatic flow-charters, text editors, indexers; accounting function devices; linkage and interface verifiers; code filters (and many others).

[Cusumano, en The Software Factory: Origins and popularity in Japan: R.W. Bemer, "Position Papers for Panel Discussion -- The Economics of Program Production," Information Processing 68, Amersterdam, North-Holland, 1969, pp. 1626-1627]

Objetivos semejantes impulsaron el desarrollo de las fábricas de software de Hitachi, Toshiba, NEC, Fujitsu, a partir de la década de 1970, y las de SDC de Rand Corporation en Estados Unidos. Estas acciones fueron analizadas detalladamente por Michael Cusumano, que entrega también una buena bibliografía sobre los esfuerzos dedicados desde los 60 hasta los 90. Particularmente destaca el trabajo de Matsumoto en Toshiba:

An RD group responsible for industrial systems software in Toshiba, led by Dr. Yoshihiro Matsumoto, introduced an organization and process in 1977 integrating tools, methods, management and personnel systems with a physical layout for work stations (...). The strategy for utilizing this infrastructure centered around four policies: (1) standardize the development process, to reduce variations among individuals and individual projects; (2) reuse existing designs and code when building new systems, to reduce redundant work and maximize productivity; (3) introduce standardized and integrated tools, to raise the performance levels of the average programmer; and (4) provide extensive training and career-development tracks for programmers, to relieve the shortage of skilled engineers.

Perhaps the most delicate feature of Toshiba's Factory was its organizational structure, a matrix imposed over product departments from several operating groups and divisions, all located on one site, Toshiba's Fuchu Works. Established in 1940 and set on 198 acres in the western outskirts of Tokyo, the Fucnu Works in 1991 had at least 8000 employees working primarily in four areas: Information Processing and Control Systems, Energy Systems, Industrial Equipment, and Semiconductors (Printed Circuit Board Division). Operating departments within the divisions corresponded roughly to 19 product lines, including systems for information and control in public utilities, factories, power-generation plants, and various industrial and transportation equipment. Each department contained sections for hardware and software design as well as for manufacturing, testing, quality assurance, and product control.

Similarities in the type of software the Fuchu Works built from project to project allowed Toshiba to deliver "semi-customized" programs that combined reusable designs and code with newly written modules, rather than writing all software from scratch. Toshiba also relied heavily on a standardized tool and methodology set, the Software Engineering Workbench (SWB), developed gradually after 1976and modelled after AT&T's UNIX Programmers Workbench. Toshiba utilized its customized version of the UNIX operating system as well as a full complement of tools for design-support, reusable module identification, code generation, documentation and maintenance, testing, and project-management. Important features of the Toshiba methodology were the design of new program modules (ideally limited to 50 lines) for reusability, the requirement that programmers deposit a certain number of reusable modules in a library each month, and the factoring in of reuse objectives into project schedules and budgets (Matsumura et al., 1987).

Software productivity at the Toshiba Software Factory rose from 1390 delivered equivalent-assembler source lines or EASL per person per month in 1976 to over 3100 in 1985, while reuse levels (lines of delivered code taken from existing software) increased from 13% in 1979 to 48% in 1985. The 3130 lines of EASL source code per month per employee translate into approximately 1000 lines of Fortran, the most common language Toshiba used in 1985 -- considerably more than the 300 lines or so of new code per month commonly cited for U. S. programmers making similar real-time applications. Quality levels (defined as the number of major faults detected after final testing) also improved dramatically after the opening of the factory, ranging from 7 to 20 per 1000 lines of delivered code converted to EASL to .2 to .05 in 1985 (the range depended on quality-control practices as well as the reliability requirements and the amount of testing customers contracted for) (Cusumano, 1991: 240).

Toshiba data indicated that reusability was the major reason for productivity and quality improvements. The organization Toshiba created to promote reuse and overcome short-term concerns of project managers and development personnel (such as the longer time required to write and document reusable software) relied on Software Reusing Parts Steering Committees and a Software Reusing Parts Manufacturing Department and Software Reusing Parts Center. The factory formed a steering committee for different areas (with different members, depending on the application) to determine if customers had a common set of needs suitable for a package, and then allocated funds from the Fuchu Works' budget for these special projects. Some packages were usable in different departments, although most served specific applications. The Reusing Parts Manufacturing Department and Parts Center evaluated new software (and documentation) to make certain it met factory standards; after certification, engineers registered the software in department or factory reuse
databases (libraries). Registered items required a key-word phrase to representthe functionality of the part or correspond to a specific object, as well as reuse documentation that explained the part's basic characteristics.
[Cusumano, The Software Factory: An Entry for the Encyclopedia of Software Engineering]

Al documento mencionado en la nota anterior, se agregan otros tres consultados del mismo autor, todos en el mismo sentido:

The Software Factory: Origins and popularity in Japan, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working Papers (WP2036-88)

A quantitative analysis of U.S. and japanese Software-Engineering practice and performance, Cusumano y Chris F. Kemerer, en Management Science, Volumen 36 , número 11, 1990

The Software Factory: An Entry for the Encyclopedia of Software Engineering, Cusumano, Massachusetts Institute of Technology (MIT), Sloan School of Management, Working papers, (WP3268-91)

En resumen, las décadas de los 80 y 90, en estos y otros papeles, se revelan como un laboratorio precursor tratando de elevar la productividad especialmente en la industria japonesa: un aspecto fundamental es el papel motor de sus empresas, y la colaboración con instituciones de investigación universitaria. De paso, merecen un comentario aparte (será otro día) las observaciones de Cusumano sobre las diferencias de enfoque entre Japón y Estados Unidos.
Visto en perspectiva, este esfuerzo por plasmar factorías de software colaboró, junto a otras líneas de acción, a prefigurar áreas de investigación que ya nos son mucho más familiares: el impulso del análisis y diseño orientado a objetos, y el desarrollo de componentes. Digamos que desde el punto de vista histórico, las factorías están lejos de representar un retroceso en la forma de encarar la construcción de software. Matsumoto por ejemplo, muestra en la continuidad de su propia actividad cómo este pensamiento siempre estuvo en primera línea de la investigación acerca de mejores vías para la construcción de software.

Papeles sueltos sobre factorías de software

A partir de un incidente con la definición en Wikipedia para Software Factories (en ese momento, la única versión publicada de factorías de software) durante mayo de 2008, comencé a recopilar materiales sobre el tema, con la idea de consensuar con otros colegas una mejor, que abarcara lo que realmente designa el concepto. Durante unos meses reuní papeles, pero las dificultades de todos los participantes hizo que fueran quedando sin modificaciones. Pasando el tiempo, la propia razón que motivara el trabajo desapareció parcialmente, ya que, debido a las críticas levantadas por el artículo inicial, así como por el trabajo de depuración de los administradores de Wikipedia, el artículo fue desdoblado en una versión principal que habla del concepto histórico y de negocios de las factorías, y una segunda interpretación que se dedica al concepto de Jack Greenfield y Microsoft.
Para quien no hubiera visto el contenido original, motivo de polémica, una versión elemental se puede encontrar en The internet Archive, 2006 y 2007.
En fin, además de habernos permitido un trabajo reflexivo sobre el tema, también pudimos ensayar las facilidades de Google Docs (versionamiento, trabajo colaborativo).
Ahora, para cerrar el tema (o no), van aquí papeles y acotaciones surgidas durante estos meses que pueden tener algún interés para valorar las fábricas de software.
Las fuentes: tres publicaciones fueron la base para trabajar: Concepto y Evolución de las Fábricas de Software, de Mario Piattini (que revisó también el trabajo en curso) y Javier Garzás; Software Factories, de Ivan Aaen, Peter Bøtcher, Lars Mathiassen; y Shifting Economies: From Craft Production to Flexible Systems and Software Factories, de M.A. Cusumano. Los tres documentos fueron de mucho interés; los dos primeros proponiendo definiciones basadas en el estado actual, y Cusumano analizando la historia.

Las factorías de software son vistas con cierta animadversión en muchos casos, asimilándolas al establecimiento de un sistema de producción taylorista; en la discusión sobre la misma definición que en éste momento existe en Wikipedia, uno de los intervinientes afirma:

The concept of a software factory is not related to libraries within any IDE, or even the factory design pattern; but rather the organizational implementation of composite application building software engineering concepts. A software factory is a business operations concept of developing software applications through assembling components per specification. It utilizes assemblers, like any factory, who specialize and repeat their assigned tasks. This means that software is made primarily by unskilled labor, rather than engineers. It's more closely related to WYSIWYG web-pages built in DreamWeaver than anything that requires an understanding of code. Unlike that example, however, it implies a a job-floor filled with unskilled labor performing specialized tasks using tools that are designed to facilitate their jobs. You don't need the conveyor-belt maker, the torch engineer, or even a master welder, to repeat a single specific weld all day on cars moving through a factory. Likewise, not everyone involved in the software development process needs to be a software engineer. All they need are an understanding of their job, and useful tools. The requirements gathering, component/tool engineering, and similar jobs are handled elsewhere. The reason I know this is because I worked at a company with a software factory that quickly churned out fully functional applications. They used serious assembly tools and a set of components that meant no one had to even know how to read code

Esta es probablemente una realidad en muchos casos, particularmente para aquellas factorías construídas en países que explotan las grandes diferencias de costo, cuya principal actividad es el outsourcing de empresas localizadas en el otro extremo del mundo: son frecuentes las quejas de los contratantes sobre problemas de comunicación y entendimiento, y sobre la real calidad del proceso usado. Quejas frecuentes para empresas radicadas en India, por ejemplo. Sin embargo, la lectura de Cusumano, y de trabajos precursores de las décadas de los 70, 80 y 90, acercan las investigaciones sobre factorías, a los intentos por formalizar, medir, optimizar, las vías empleadas para la construcción del software. Sin negar la realidad de la visión anterior, es este aspecto, también existente desde su desarrollo temprano, el que ofrece más interés, y el que les da valor a las factorías desde el punto de vista de la ingeniería de software. Bob Bemer, McIlroy, a finales de los 60, proponen trabajar sobre la actividad de medición, mejora de la calidad de los procesos, reusabilidad, utilización de herramientas de productividad. Hitachi y Toshiba, durante la década de 1970, trabajaron ampliamente forjando herramientas y procedimientos de mayor calidad y consistencia, lejos de la imágen del taylorismo de factorías de software dedicadas a obtener contratos con el menor presupuesto posible. Una revisión del progreso del concepto a través de los finales del siglo anterior, muestra una estrecha relación entre la idea de factoría de software y las investigaciones que fueran forjando principios de la ingeniería de software. En buena medida, la idea de CASE, componentes, y la orientación a objetos, aparecen en papeles que relacionan los dos mundos. Más recientemente, la idea de Software Product Lines aparece claramente relacionada con las factorías de software. Hace algún tiempo, y en el curso de esta tarea, se ha comentado aquí el trabajo de Matsumoto, largamente vinculado al desarrollo de factorías, desde la organización de sistemas de producción hasta el desarrollo de líneas de producto. Nada de todo esto da la idea de una visión taylorista del negocio, salvo para aquellos que todavía creen que es posible el desarrollo del software como una artesanía, ni parecería que una organización de este tipo fuera posible con un equipo reducido de planificadores inteligentes, y una masa de ensambladores no calificados.
Fin por hoy. Volveremos sobre esto, quizá analizando bibliografía visitada.

Fotos: Yoshihiro Matsumoto, Michael Cusumano, Bob Bemer.

Sidekick-Danger-Microsoft: lo que queda

Richard Waters, en Financial Times, dedica unas líneas al fallo de Sidekick ya comentado, destacando las consecuencias para los intervinientes: probablemente un daño irrecuperable para Sidekick, y sombras de dudas sobre la capacidad operacional de Microsoft.

It leaves some uncomfortable questions for Microsoft, though. Such as: Why did it take nearly two weeks to work out that that most of the data hadn’t been lost after all? And: How did the company let this issue spiral into a public relations disaster, casting a shadow over two of its most important initiatives: mobile and cloud computing?

This is what Microsoft has to say about the recovery:

We have determined that the outage was caused by a system failure that created data loss in the core database and the back-up. We rebuilt the system component by component, recovering data along the way. This careful process has taken a significant amount of time, but was necessary to preserve the integrity of the data.

It’s a bit late to reassure customers about this painstaking process when they’d been left pretty much in the dark for so long, and actually encouraged to believe their information had been lost.

With Microsoft providing little information, partner T-Mobile stepped into the vacuum nearly a week ago to tell Sidekick users that their data “almost certainly has been lost” and the chances of recovery were “extremely low.” Imagine how the Microsoft engineers working on the recovery felt when they read that one.

In an apology to its customers, Microsoft now promises it has “initiated a more resilient backup process.”

The message is signed by Roz Ho, corporate vice president, Premium Mobile Experiences. No kidding.

El fallo muestra otro frente débil para la empresa: así como llovieran las críticas sobre el largo proceso de desarrollo de Vista, este nuevo problema "hecha sombras" sobre su confiabilidad en un área que será de mucha importancia en el futuro próximo: cloud computing. Microsoft sigue dando la impresión de mantener una conducción errática sobre sus negocios.

El fallo de Sidekick-Danger-Microsoft: otra cara del problema

El comentado fallo del fin de semana de Sidekick es visto desde otro punto de vista por Mary Jo Foley en ZDNet:
Folley intuye que el fallo podría tener que ver con una operación asociada a la instalación de servicios de Pink, un proyecto de telefonía de Microsoft a cargo de Danger: el problema no estaría vinculado a la "computación en la nube", sin que deje de representar un gran descuido en su servicio.

Sidekicks aren’t running from/on “the Microsoft cloud.” In fact, there is no such thing as a single Microsoft cloud. Microsoft has lots of different remote servers in different data centers running lots of different services.

The Microsoft Azure cloud is what many Microsoft watchers think of these days when someone says “the Microsoft cloud.” But the Azure environment provides the underpinning for very few Microsoft services so far. The Sidekick services don’t run on Azure. Microsoft’s My Phone doesn’t run on Azure. Hotmail, Xbox Live, Microsoft-hosted Exchange — nope, nope and nope. None of these are running on Azure yet.

The Sidekick outage, to me, says more about Microsoft’s Pink than it does about Azure.

The Danger team, which Microsoft acquired in 2008, is largely responsible for the Pink “premium mobile experience” (PMX) software/services on which Microsoft has been working on secretly. There have been a few recent reports that Microsoft has decided against launching the Pink phone(s) that were going to run these services, but I haven’t heard from any of my sources whether this is true. Sharp supposedly is the manufacturer of the Microsoft-branded/co-branded Pink phones, which Microsoft is said to be planning to market primarily to teens and 20-somethings.

(Microsoft officials have denied repeatedly assertions that Microsoft is making its own smartphone. They have not denied that Microsoft is working with a hardware partner to build Microsoft-branded or co-branded phones.)

What was Microsoft doing to the back-end Danger services that resulted in such a catastrophic outage? Microsoft isn’t talking. There are rumors the problem stemmed from a storage-area-networking debacle but Microsoft isn’t confirming that, either.
Because Microsoft hasn’t yet launched Pink, company officials have refused to talk at all about which premium services it will encompass and what kind of back-end platform they’ll run on. Is Microsoft designing the Pink services to run on its own servers? Is/was Microsoft intending to allow the Pink services to remain hosted on the existing Danger back-end? Did this past week’s Sidekick outage result from Microsoft (or Hitachi Data Services, or whoever) attempting to move the Danger back-end off the existing servers and onto Microsoft’s own servers? Microsoft officials won’t say.

Sea una u otra la base del problema, el resultado para los usuarios no difiere: pérdida de confianza en un proveedor y un servicio:

Now that more everyday users know that Sidekick is connected to Danger and Danger to Microsoft, this week’s outage will cast a shadow over any kind of Pink phone and/or Pink premium services launch Microsoft may be planning.

Cloud Computing bajo fuego (¿o un sistema de responsabilidad?)

Publicado el 11 de octubre en New York Times: "algunos" usuarios de T-Mobile y Danger, subsidiarias de Microsoft, perderían la información personal en sus cuentas (agenda, fotos, listas de tareas):

The cellphone provider T-Mobile and Danger, a subsidiary of Microsoft and one of T-Mobile’s partners, said over the weekend that a technical glitch in their computer systems would probably result in some customers losing their personal information like contact names, phone numbers and digital photos.
T-Mobile and Danger operate what has become known as a cloud computing service to store important information for their customers. In theory, such a service should make life easier on people by leaving the management of complex computing systems to the pros and having data held in sophisticated computing centers. But when problems crop up, embarrassment ensues.

[...] Employees at the companies have worked over the weekend to try and fix these problems, but, as of Sunday afternoon, there were still some data and software application service flaws.

“Our teams continue to work around the clock in hopes of discovering some way to recover this information,” T-Mobile said in a statement on its Web site. “However, the likelihood of a successful outcome is extremely low.”

Lo que inicialmente alerta sobre la confiabilidad de la computación "en la nube", adquiere un color más personalizado en otros comentarios: En el curso de una actualización de hardware, no se habrían hecho respaldos adecuados (la hipótesis es algo más cruda: no se habrían hecho, llanamente):

By now the word is out on the street. Microsoft/Danger has most likely lost everyone’s personal info including contacts, notes, calendar entries, to-dos, etc. The question remains: How did this happen? Microsoft is a big software company, they’re well versed in the enterprise world and should have systems in place that allow them to weather any sort of issue like this. Of course everyone (T-Mobile, Microsoft/Danger) hasn’t come out with any details on the cause of the failure, but we’ve got some theories and rumors floating around.

Currently the rumor with the most weight is as follows:
Microsoft was upgrading their SAN (Storage Area Network aka the thing that stores all your data) and had hired Hitachi to come in and do it for them. Typically in an upgrade like this, you are expected to make backups of your SAN before the upgrade happens. Microsoft failed to make these backups for some reason. We’re not sure if it was because of the amount of data that would be required, if they didn’t have time to do it, or if they simply forgot. Regardless of why, Microsoft should know better. So Hitachi worked on upgrading the SAN and something went wrong, resulting in it’s destruction. Currently the plan is to try to get the devices that still have personal data on them to sync back to the servers and at least keep the data that users have on their device saved.

We’ve heard this from what appears to be several sources and it seems to hold weight. Needless to say it all boils down to one thing: Microsoft did not have a working backup.

How this happens in today’s day and age is beyond belief. Hundreds of thousands of customers that generate millions of dollars in revenue means you back their stuff up, in triplicate. You test these backups regularly, and you move a copy off site that doesn’t get touched except in case of an emergency (i.e. right now). The head of the mobile division (and person in charge of what’s left of Danger) is Roz Ho, who has been at Microsoft for 18 years. You would think she’d know something about how to run a business.

What does this mean for the future of the Sidekick? Unless Microsoft pulls a miracle out of thin air the Sidekick is dead. People are already jumping ship to other phones with this news, and the exposure of how inept Microsoft is when it comes to the mobile world is huge. If Microsoft can’t continue to run Danger, a company that was ground-breaking and solidly built, how can we expect anything from the Windows Mobile department?

(Comentado en Hiptop3.com, un sitio dedicado a Sidekick).
Otras referencias: Om Malik, y Eric Zeman, en Information Week.
Zeman saca la conclusión genérica: usa la nube, y haz tus backups:

T-Mobile isn't alone in the service they provide. Other mobile companies, such as Google, Apple, Palm, and Microsoft, have cloud-based data management systems that users can take advantage of. I think the bottom line here is pretty clear. Cloud storage can certainly provide for a back-up that's mostly trustworthy, but making sure you back-up data locally can prevent real disasters.

¿La ciencia española es descartable? (La ciencia española no necesita tijeras)

Invitado por algún colega, escribo esto para adherir al reclamo de la comunidad de bloggers de España. Quizá no sea el más indicado, ya que mi experiencia en el país no supera los cuatro años, por lo que he preferido recordar lo que otros dicen, antes que basarme en mis observaciones.
Quisiera apuntar dos comentarios; uno, de Manuel de la Villa, que afirma que

No se puede hablar sobre la bondad de las ayudas públicas como reactivador económico y, a la vez, disminuir la inversión en el motor económico de los países más desarrollados, la innovación. En España, dado el escaso potencial y capacidad de las empresas en la actualidad para invertir en I+D, es el estado el que debe corregir ese desequilibrio. Hace 20 años las empresas extranjeras invertían en España por su situación en Europa y por lo barato de la mano de obra. Ahora que no estamos tan bien ubicados (pues países cercanos ofrecen una mano de obra más barata, como el norte de África) nuestro factor diferencial debe ser nuestra preparación, actitud y aptitud.

Manuel recopila a su vez, lo que dicen otros, entre ellos Esther Samper:

Pese a que en España sólo se destina el 1,27% del PIB a I+D (la media europea es superior al 2%), se anuncian fuertes recortes (15%) en los presupuestos del 2010 para la financiación de la ciencia. ¿Es la salida a la crisis volver por dónde hemos venido?
[…] Ahora sería el mejor momento para reforzar nuestra economía, volverla más sólida, menos centrada en el ladrillo (39% del PIB) y en el turismo (10% del PIB), que no duran siempre, y más en otras áreas que llevaran no sólo a un desarrollo económico a largo plazo sino también a un aumento de la calidad de vida y el bienestar de la sociedad. Apostar por la ciencia, la innovación y el desarrollo es apostar por esta última opción. Por un modelo de desarrollo económico a largo plazo donde toda la sociedad (y no sólo unos pocos) termina beneficiándose de éste.

Sin embargo, en lugar de enmendar los errores, se está optando por cerrar el círculo para terminar en donde habíamos empezado. Mientras los bancos y el sector inmobiliario (los principales causantes de este descalabro) reciben suculentas ayudas para alejarlas de su agonía, la ciencia ve recortada sus presupuestos. De convertirse en una solución pasará (si nadie lo evita y los presupuestos se aprueban) a ser una víctima más de esta crisis. Inicialmente, se anunciaron recortes de hasta el 37% en I+D pero, ante la alarma producida en la comunidad científica, se ha planteado finalmente como un recorte general del 15%. Este recorte será aún más sangrante en los organismos de investigación sanitaria con un 25%.

El otro comentario proviene de la Conferencia de Rectores, y converge al mismo reclamo. Leído en El Confidencial:

El presidente de la Conferencia de Rectores de las Universidades Españolas (CRUE), Federico Gutiérrez Solana, ha asegurado que "no se puede permitir ni un sólo euro de reducción ni en educación ni en investigación si se quiere apostar por un nuevo modelo de sociedad para el futuro".

Gutiérrez ha explicado hoy en rueda de prensa que desde las universidades se está haciendo "una apuesta fuerte por la investigación, el desarrollo y la innovación, que tiene que ser absoluta porque en la educación está la clave de futuro de la sociedad".

Los rectores consideran que "la respuesta en los presupuestos no es satisfactoria" y que las administraciones regionales de las que dependen directamente las universidades públicas "también se están viendo en una situación complicada desde el punto de vista presupuestario". "Si cada vez que en el discurso político se habla de inversión en investigación se pusiera un euro, tendríamos una política de I+D+i milmillonaria", ha añadido el rector de la Universidad Politécnica de Valencia, Juan Francisco Juliá.

La rectora de la Universidad de Illes Balears, Monserrat Casa, ha resaltado que "la universidad española ha hecho mucho con muy poco dinero, solo hay que comparar la financiación que tienen algunas universidades de este país que es inferior a 5.000 euros por alumno con la media europea que se sitúa en torno a los 16.000 euros". Gutiérrez ha insistido en que "lo importante de cara al futuro es que la profesión del investigador sea reconocido por la sociedad como el origen de toda su riqueza" y que "hay universidades en las que al menos se generan tantos puestos de trabajo como los investigadores activos que hay".

Monserrat Casas ha subrayado que la universidad obtiene financiación según el número de alumnos y el único dinero que se reinvierte en investigación es el que ésta misma genera, por lo que "el investigador tiene que preocuparse también de encontrar fondos".

En fin, encontrándonos en la meseta de una crisis que debiera ser una bisagra, quedándo expuestos los puntos débiles de una concepción económica y social; unos puntos débiles que apuntan al sostén económico en actividades de escaso valor agregado, que condenan a España a una recuperación lenta y difícil, no es posible que su clase dirigente se conforme con un futuro de factoría. Es en la investigación científica, la innovación y la apuesta por los emprendedores, donde España encontrará su mejor futuro.

Disponibles las presentaciones de la conferencia de Plex en Fort Lauderdale

Publicado en el sitio de la conferencia, (y avisado también por Lucio Gayosso), están disponibles ya las persentaciones de la conferencia anual de Plex (de interés para usuarios de Plex). Luego volveremos sobre su contenido.
El aviso, y las presentaciones.

Dilbert encuentra el uso perfecto de Twitter...

Visto gracias a Alan Dean (y más de cien otros en Reader)...: Uso estratégico de Twitter.