MySQL: Forked beyond repair?

One month afterOracle announced its takeover of Sun Microsystems,the future of MySQL remains up in the air. Can the leading lightweight open source database still thrive when it's controlled by the leading proprietary commercial database vendor? So far, the prognosis doesn't look good.

Even before the Oracle buyout, there were signs of strain within the MySQL community. Not long afterSun acquired MySQLin 2008, keyMySQL employees began exiting the company, including CEO Mårten Mickos and cofounder Monty Widenius. Widenius, in particular, wasvocally critical of the MySQL development processunder Sun's stewardship, citing rushed release cycles and poor quality control. Another MySQL cofounder, David Axmark, left out of frustration with the bureaucracy and tedium ofSun's buttoned-down corporate culture.

[ Some analysts predict thatMySQL could thrive under Oracle ownership| For more on theOracle-Sun merger, see InfoWorld's special report. ]

In the wake of this exodus came another ominous development: Forks of the MySQL codebase began to appear, including Drizzle and MariaDB, offering users and contributors ways around Sun's control of the main branch.Drizzle is an attempt to shed some of the feature bloat that has crept into recent MySQL releases, in favor ofa lightweight database serveraimed at cloud computing and Web applications.MariaDB, on the other hand, aims to be feature-compatible with MySQL, but it uses a brand-new, transaction-capable storage engine by default. And perhaps even more significantly, MariaDB is spearheaded by none other than Widenius himself.

If that wasn't troubling enough for MySQL's new minders at Oracle, Widenius has since dropped the other shoe. Last week, he announced the formation of the Open Database Alliance, a "vendor-neutral consortium" whose stated aim is to become "the industry hub for the MySQL open source database, including MySQL and derivative code, binaries, training, support, and other enhancements for the MySQL community and partner ecosystem." Notably, no one from Oracle is listed among the Open Database Alliance's contacts.

If all this leaves you scratching your head, you're not alone. In March, former MySQL employee and Drizzle developer Patrick Galbraith wondered aloud justwhich branch of MySQL should be considered "official"these days. The ultimate answer to that question will determine the fate of the MySQL database.

Can Oracle keep the MySQL product relevant?
Of course, there can only be onereal,official version of MySQL: It's the one that was originally developed by MySQL, was later bought by Sun, and was finally acquired by Oracle. Oracle now owns all the copyrights, trademarks, and other intellectual property associated with the MySQL name -- and that intellectual property has always been defended vigorously. MySQL had even been known tosend trademark-violation notices to partnersthat had the temerity to call their service offerings "MySQL support" instead of "support for MySQL databases."

While that's all well and good, however, the MySQL brand alone isn't likely to comfort customers who worry that an open source database won't get the attention it needs from one of the world's largest commercial software companies. Already some customers must be questioning Oracle's commitment to a low-end product like MySQL, when it has a lucrative, proprietary database to sell. And as the MySQL community fragments and begins turning to alternatives, the economics of Oracle's MySQL business become steadily less attractive.

But if MySQL's approval ratings are slumping, all the more reason for Oracle to move decisively. Oracle must work to regain the trust and support of the MySQL community or risk losing mindshare to a fork, such as Drizzle or MariaDB. To do that, it has to avoid making the mistakes that Sun made when it acquired MySQL. In a sense, to succeed with MySQL, Oracle will have to stop acting like Oracle.

Open source customers are a notoriously fickle bunch. If one project doesn't deliver what users need, the users go elsewhere -- and the same goes for developers. Forks are a fact of life in the open source community, and arguably an entirely healthy one. Oracle just better hope it doesn't end up on the wrong side of the fork.

When projects fork, there are winners and losers
Coincidentally, a similar drama is playing out elsewhere in the open source world right now. This one concerns glibc, the Gnu standard C library that is used by practically every piece of software running on Linux systems. Earlier this month, the Debian Project opted toswitch its entire distributionfrom using standard glibc to a fork calledeglibc. Ostensibly the new fork works better for embedded systems programming, but the community scuttlebutt says the switch was really the result of ongoing problems with glibc's notoriously obstinate maintainer, Ulrich Drepper. (One contributor even went so far as to filea bug report describing the problem.)

The name eglibc is surely no accident. It echoes an earlier, contentious incident in which a group of developers working on gcc, the Gnu C compiler, frustrated by the project's restrictive contribution model, split off to forma new fork called egcs.Freed from excessive bureaucracy, the fork thrived, while development on the main gcc branch stagnated. Eventually it died off completely; all that was left was for egcs to formallychange its name back to gcc.The fork became the main branch -- and according to some egcs developers,that had been their intentionfrom the very beginning. It seems likely that the eglibc maintainers have something similar in mind.

There's a real lesson to be learned here for Oracle and other maintainers of open source projects. Creeping authoritarianism in the development and contribution processes is something that many users of open source software are simply unwilling to tolerate; quite naturally, the contributors with the most to offer are the most likely to become frustrated when they feel stymied by red tape (or simple pigheadedness). Projects that are maintained by commercial entities are particularly susceptible to this tendency. Twelve years after Eric S. Raymond published his landmark essay, "The Cathedral and the Bazaar," too many projects -- and companies in particular -- can't seem to let go of their cathedral mentalities.

That's why the best course of action for Oracle would be to join the Open Database Alliance and take an active role in the ongoing development of MySQL in an open, community-driven way. Oracle acquired MySQL as an asset of Sun, but Sun never knew what it had in the first place, nor how to manage it. If Oracle can't figure out how to do what Sun couldn't, it will still own the MySQL name; unfortunately, however, that name won't mean much.

内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值