• Спільнота MySQL запідозрило Oracle в несумлінності. У блозі одного з розробників був опублікований ряд фактів, що свідчать про те, що корпорація, з 2009 р. є власником прав на MySQL, намагається поволі розхитувати відкриту модель розробки знаменитої СУБД.
    Сергій Голубчик, технічний координатор MariaDB, форка MySQL під ліцензією GPL, звинуватив Oracle в навмисному приховуванні тест-кейсів і спробах заплутати історію ревізій. У записі офіційного блогу MariaDB, озаглавленной «Зникаючі тест-кейси, або ще одна частина MySQL стала закритою», Голубчик розповів, що розробники MariaDB виявили невідповідність між кількістю опублікованих тест-кейсів і реальним числом виправлених помилок у новому релізі MySQL.
    Помилки, виправлені у версії MySQL 5.5.27, не супроводжуються описом відповідних тестових ситуацій, стверджують в MariaDB. Прикладами можуть служити помилки #61579 і #60926 в багтрекере на сайті MySQL. Коли розробники підняли цю проблему у внутрішньому списку розсилки MySQL, Oracle відмовилася пояснити, чим це викликано насправді - промахом тестувальників або ж новою політикою розробки.
    Крім того, в тестовому фреймворку mysql-test-run не так давно з'явилися зміни, які демонструють, що тепер він здатний запускати тести не тільки з стандартною директорії mysql-test, але і з якоїсь директорії internal/mysql-test, про яку розробники до недавнього часу не мали ні найменшого уявлення. Директорія internаl/mysql-test не була опублікована разом з вихідним кодом нового релізу, проте один з комітів демонструє, що у неї вже завантажуються тести.
    На думку координатора MariaDB, тест-кейси є «важливою частиною дерева пакети MySQL», які дозволяють розробникам движків баз даних, постачальникам дистрибутивів Linux і просто користувачам верифікувати свої патчі до MySQL. MySQL завжди дотримувалися такої політики, що кожен закритий "баг" повинен супроводжуватися тест-кейсом, який підтверджує працездатність заплатки. Oracle навряд чи може відмовитися від цієї впевненості просто так, тому причина приховування тест-кейсів лежить набагато глибше, вважають в MariaDB.
    Що стосується історії ревізій, то Голубчик вказав на недавнє повідомлення Стюарта Сміта (Stuart Smith), директора по развитию в Percona, медждународной компанії, що займається підтримкою MySQL. Сміт відзначив у своєму блозі, що вихідний код доступний з BZR-дерев MySQL, не синхронізований з архівами і виконуваними файлами СУБД, які постачає Oracle.
    Так, остання ревізія пакети в дереві MySQL 5.1 позначена номером 5.1.63, однак Oracle тільки недавно випустила MySQL 5.1.65. В дереві MySQL 5.6 аналогічне розбіжність у версіях: Oracle вже випустила версію 5.6.6-m9, у той час як код дереві BZR знаходиться на стадії «де-то після 5.6.5».
    Стюарт зазначає: «В принципі, Oracle може не публікувати код в дереві BZR взагалі, у неї є на це право. Неприємно, що при цьому вона відмовляється виходити на зв'язок».
    Інші розробники MySQL поскаржилися на те, що помилки, які раніше були загальнодоступними, тепер заносяться Oracle в категорію «приватних» без пояснення причин. Однією з таких стала помилка, що викликає відмова сервера БД, яка була виправлена у версії 5.5.27. Інформація до версії не містить жодних згадок про те, що ця помилка взагалі виправлена.
    Марк Каллахан (Mark Callahan), член команди MySQL в Facebook, який брав участь у розробці плагіна InnoDB в Google, підбив підсумок поточної ситуації з MySQL словами про те, що популярна СУБД стає «все менш відкритою». «Набагато важче покращувати MySQL, коли не вистачає тестів, а BZR не оновлюється, - висловився він. - Команди Facebook і Google зробили MySQL набагато краще. Я радий, що тоді мені не довелося зіткнутися з такими проблемами, які загальмовують весь процес».
    Незважаючи на те, що Oracle внесла продуктивний внесок у розвиток MySQL, заслуги співтовариства Open Source аж ніяк не менше, нагадав Каллахан. Розробники сподіваються, що Oracle візьме на себе зобов'язання прокоментувати несподівані зміни.