Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Forking Successfully - or is a branch better?

929 views

Published on

Forking Successfully or do you think a branch will work better? Learn from history, see what's current, etc. Presented at OSCON London 2016. This is forking beyond the github generation. And if you're going to do it, some tips on how you could be successful.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Forking Successfully - or is a branch better?

  1. 1. Forking Successfully Colin Charles, Chief Evangelist, Percona Inc. colin.charles@percona.com / byte@bytebot.net http://bytebot.net/blog/ | @bytebot on Twitter OSCON London, United Kingdom 17 October 2016
  2. 2. whoami • Chief Evangelist (in the CTO office), Percona Inc • Founding team of MariaDB Server (2009-2016), previously at Monty Program Ab, merged with SkySQL Ab, now MariaDB Corporation • Formerly MySQL AB (exit: Sun Microsystems) • Past lives include Fedora Project (FESCO), OpenOffice.org • MySQL Community Contributor of the Year Award winner 2014
  3. 3. Agenda • Forks • GitHub generation • GNU Emacs and XEmacs • MySQL, MariaDB Server, and Percona Server • Drizzle? • Other forks
  4. 4. To fork, or not to fork, that is the question
  5. 5. Fork In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software. https://en.wikipedia.org/wiki/Fork_(software_development)
  6. 6. GitHub generation • Watch: Notifications for active participants • Star: Bookmarking + “light” appreciation • Fork: a copy of a repository; make your changes • Pull request: encouraging to merge your changes with the upstream project
  7. 7. First open source fork… • POSTGRES? • 1986, when Michael Stonebraker wanted the ‘after Ingres’ database • Today this has given you PostgreSQL
  8. 8. GNU Emacs and XEmacs 1991
  9. 9. Copyright Assignment (and Contributor License Agreements)
  10. 10. Last stable release of XEmacs January 2009
  11. 11. Feature Parity (or the death of a fork)
  12. 12. MySQL World’s most popular open source database
  13. 13. GPL MySQL 2000
  14. 14. October 2005: Oracle acquires Innobase Oy (“InnoDB Friday”)
  15. 15. October 2005 - late 2005 • October 2005: 5.0 becomes GA* • Late 2005: Maria project starts
  16. 16. MySQL fast-forward • January 2008: acquired by Sun Microsystems • June 2008: Drizzle — fork of MySQL 6.0 — modular, fast, microkernel architecture, UTF8, etc. • November 2008: Percona Server (patchset ~July) • April 2009: Oracle proposes acquisition of Sun Microsystems (and MySQL) • January 2010: Oracle completes acquisition of Sun Microsystems • October 2009: MariaDB 5.1 Beta release
  17. 17. MariaDB • Developed at Monty Program Ab • February 2010: MariaDB 5.1 GA release • November 2010: MariaDB 5.2 GA release • February 2012: MariaDB 5.3 GA (GIS, replication improvements, optimiser) • April 2012: MariaDB 5.5 GA • November 2012: Announcement of MariaDB Foundation
  18. 18. Community Developed. Feature Enhanced. Backward Compatible.
  19. 19. Community Developed • MariaDB: takes external contributors/committers, Google Summer of Code • MySQL: contributions welcome, commits not • MySQL Community Contributor Award Program • Percona: bug reports/feature requests welcome, commits not (pull requests accepted)
  20. 20. Distribution matters • Being available matters • Linux distributions, clouds, containers, etc. • Security matters - fix those CVEs quickly, and say what got fixed
  21. 21. Branch or Fork? • MySQL 5.5 — Percona Server 5.5 — MariaDB Server 5.5 - drop-in compatible • MySQL 5.6 — Percona Server 5.6 - drop-in compatible • MySQL 5.7 — Percona Server 5.7 - drop-in compatible
  22. 22. Drizzle • Drizzle: 2008 - 2012 (R.I.P.) • Aggressive about standards — utf8 was first class, FRM files were gone, no MEDIUMINTs, etc. • Drizzle - single company open source project (Rackspace). Most went on to work at OpenStack
  23. 23. LibreOffice/OpenOffice.org • LibreOffice started as ooo-build for the large codebase • Document Foundation backed (28 Sep 2010) • March 2015 LWN.net - “LibreOffice has won the battle for developer participation” • Apache Foundation got OpenOffice.org -> Apache OpenOffice • Lack of active developers and code contributions
  24. 24. There are others!
  25. 25. Nagios and Icinga
  26. 26. OpenSSL and LibreSSL
  27. 27. node.js and io.js
  28. 28. Hudson and Jenkins
  29. 29. OwnCloud and NextCloud
  30. 30. SugarCRM and SuiteCRM
  31. 31. OpenBSD and NetBSD
  32. 32. Oracle Enterprise Linux and CentOS and Red Hat Enterprise Linux
  33. 33. To watch • Docker • MariaDB MaxScale
  34. 34. Bitcoin And the hard fork
  35. 35. Android
  36. 36. Those who cannot remember the past are condemned to repeat it. George Santayana
  37. 37. Why are you forking?
  38. 38. Naming • Pick a good one that focuses on values • Beware of trademarks
  39. 39. Takeaways • Community matters • Developers matter • Limit end-user friction • Sustainable development methodology • Fork as a last resort • Clear fork focus
  40. 40. As a user what should you use? • Think about innovation today • Beware vendor lock-in - freedom from vendor independence is crucial • Ensure you are well supported
  41. 41. Thank you! Colin Charles colin.charles@percona.com / byte@bytebot.net http://bytebot.net/blog | @bytebot on twitter slides: slideshare.net/bytebot

×