Tuesday Jun 23, 2009

Contributing to MySQL

If interested in contributing code to MySQL, you should attend the MySQL University session on contributing code to MySQL.

(Live broadcast with Q&A will be held on Thursday, June 25, 2009. You can still have access to rebroadcasts afterwards.)

Monday Apr 27, 2009

More Code Contributions to MySQL

MySQL has deep roots in open-source software development communities and code contributions to MySQL keep flowing in, being reviewed and integrated into the MySQL. 

During our BoF at the MySQL Conference and Expo, Lenz Grimmer talked about our work to make MySQL (even more) contributor friendly, with some more focused effort starting on February 1, 20091.

The desire to contribute code to MySQL remains as strong as ever as evidenced by this year's MySQL Conference and Expo, where I had an opportunity to speak with some contributors and partners who wish to contribute to MySQL. Of course, there are a lot of strong and varying opinions in this area.

As I said above, code has been contributed and absorbed in MySQL (according to either the MySQL CLA or SCA contributor agreements) for years now.

Examining just the patches and contributions submitted through the MySQL Bugs database, some 16 pieces of code contributions to MySQL have been absorbed into some version of the MySQL server in the first 4 months of this calendar year, and there are some 17 SCA signatories who are intent on contributing to MySQL.

As examples of code contributions being currently reviewed, one may point to two thread on "internals," one involving a review by Konstantin Osipov (contributor: Antony Curtis, WL#820) and another a review by Guilhem Bichot (contributor: Erik Ljungstrom). 

[1] February 1, 2009 was exactly 10 years from the day I started working for Sun Microsystems Inc., February 1, 1999, when I started in the J2EE RI development team.

Friday Apr 17, 2009

A BoF on Community Code Contributions to MySQL

The BoF schedule for MySQL Conference and Expo (2009) is now published. Lenz Grimmer, Sergei Golubchik, Tomas Ulin and myself will be available during a BoF which focuses on MySQL Community Code Contributions. Lenz will be moderating. For background material, you may start here.


Tuesday Mar 31, 2009

MySQL Ideas for Google Summer of Code (GSoC)


Check out the ideas from MySQL for Google Summer of Code 2009!

These are specially-selected projects for students who are looking to do some coding in a real, open-source, highly-adopted software environment. 

The learning experience will be tremendous given that MySQL engineers will be mentoring them. 

Some student stipend is provided by the Google Summer of Code. It is intended for students to gain "exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits."

Friday Feb 13, 2009

Contributing Code to MySQL -- Some Simple Guidelines

If you would like to contribute to MySQL development, you can read the relevant top-level page on the MySQL Forge.

This page has some useful links to various forms of contributing to MySQL, including contribution of code to MySQL. (The MySQL|Sun team have recently simplified some of these pages in order to make them more useful to community members and potential contributors.)

Note that after some simple paperwork submitted to Sun ("Sun Contributor Agreement" or "SCA"), any signatory can contribute to any Sun-sponsored open-source project, including to MySQL.

It is a common parctice to require initial paperwork to clarify rights to the contributed work. This practice is also used by other open-source communities such as the Apache Software Foundation.

It is worth quoting, from the the master document, that

As we gain more experience, absorb more contributions and receive feedback from the contributors, please expect some modifications to the contribution system described here.

Thursday Feb 05, 2009

Golden Rules for Contribution-based Communities

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having contributed to the ideas and practices behind these rules.

A) Transparency.
1.Often, this openness can span all the way from development (architectural specification, implementation design and planning, implementation, code review and walk-through) to testing, qualification and release.
2.It may be possible to move towards greater transparency over time but openness in development is often the minimum starting point. 

B) Dialog.
1.It should be possible to conduct open dialog and conversation regarding any aspect of the development (and other aspects of) work.
2.When mailing lists and other archive-able communication channels (such as wikis) focused on development work are opened up, it becomes easier to conduct open dialog and conversation regarding the development work. 
3.Of course, when a corporation or business concern contributes (either as a major contributor or a minor contributor) to the development of an open-source product, it is to be expected that some aspects of the development work (e.g. those related to specific customer needs) may remain obscure through mechanisms such as withholding of a customer's name. 

C) Pace.
1.It should be possible to track the fate of any contribution and have a public archive of the conversation conducted regarding that contribution—recording decisions made and various feedback loops in time for the purposes of learning and further work.
2.For this purpose, it is often sufficient to have a time record of the conversation conducted with respect to the given contribution.
3.These records can be searched to determine the fate of the contribution.
4.These records help provide a learning platform for the future contributors.

D) Setting Expectations.
1.Using available and open information, the contributor community should be able to form and entertain valid expectations regarding milestones, releases, timelines, etc.
2.Anticipating the future and related risk management helps all market participants to reduce transaction costs.

E) Small is Beautiful.
1.While it should be possible to absorb contribution of any size, emphasis should be put on  absorbing smaller and incremental contributions.
2.To create mass and momentum and community and quality, it helps to encourage smaller contributions.

F) Differences.
1.Not all contributions are equal.
Contributions are judged by whether they are well designed, fit into business roadmaps, are well documented, comply with standards, do not produce regressions in the code and improve performance.
2.Not all contributors are equal.
Contributors vary in expertise, skill and experience.
These variations give meaning to the practices and procedures of the contributor community.

G) Places.
1.It is clear where one needs to work.
There are enough branches or trees to serve distinctly different target groups.
2.Trees and branches are well-groomed.
Active code branches or trees are kept at a minimum set in order to keep the product roadmap and expectations coherent.

H) Parallelism.
1.Contributions are added in parallel with frequent synchronization so that community participants can respond to each others' work.Parallel work leads—naturally and out of brute necessity—to modularization, better and faster integration.

I) Incrementalism.
1.Work is conducted in increments.
2.Each contribution does one thing.
3.Each contribution has a test case that exercises it.

J) Learning.
1.Contributor community assets (channels of communications, forums, bug databases, etc.) are developed to improve learning by all participants and contributors.


Acknowledgment

I'd like to thank Brian Aker, Knut Anders Hatlen, Davi Arnaut, Kaj Arnö, Jorgen Austvik, Igor Babaev, Mark Callaghan, Peter Eisentraut, Sergei Golubchik, Shawn Green, Lenz Grimmer, Rick Hillegas, Stefan Hinz, Geir Hoydalsvik, Henrik Ingo, Alexey Kopytov, Mark Leith, Dmitry Lenev, Manyi Lu, Giuseppe Maxia, Paul McCullagh, Mårten Mickos, Chad Miller, Francois Orsini, Konstantin Osipov, Trudy Pelzer, Sergey Petrunia, Jay Pipes, Jeffrey Pugh, Ole Solberg, Georg Richter, Mikael Ronström, Kristian Waagan, Dag Wanvik, Monty Widenius, Jeff Wiss, and more.

Tuesday Mar 20, 2007

John W. Backus

Today, The New York Times carries an obituary to John W. Backus, of the "Backus | Naur form" notation and the lead of the IBM team who brought us Fortran. Many a scientific computing wizard will today salute Mr. Backus for what he and his team accomplished.

While the need for new programming models was dire in the 1950s, a move by Backus to initiate an applied research program to invent a higher-level language led to a revolution in software. The first Fortran team worked on the language from 1953 to 1957. ("The first written reference to 'software' as a computer term, as something distinct from hardware, did not come until 1958," according to The NYT.)

In my experience with Fortran, I join many others who used this first-generation higher-level language to do useful things, including much scientific research.

I wrote my first toy computer program, which calculated the first 1000 primes, in Fortran. Later on, I wrote Fortran programs to calculate temperature profiles in three dimensional body embedded in a heated environment, to study dispersion and diffusion of particles in turbulent flows, to investigate the dynamics of particle-particle collisions and systems, and to perform direct numerical simulations of fluid flow and vortex-vortex interaction in an infinite body. In short, in the mid 1980s, I spent many hours doing scientific programming in Fortran. (Some of this work got its way into my masters dissertation and other to my Ph.D. dissertation. Much of it remained at the level of pure investigation and study.)

Note: For a modern progeny, see Fortress.

Wednesday Jan 31, 2007

All The Uses

All the current uses of Apache / Derby  are truly astounding in the variety of applications. Those who have not had a chance to take a serious look are missing out. Sun Microsystems Inc. distributes Derby as Java DB, independently and with the JDK, beginning with JDK 6.

Thursday Dec 21, 2006

Statistics on Open Source Projects

Now, we have places to go to for open source project statistics.

For example, see the Ohloh statistics for Apache / Derby.

Sunday Nov 12, 2006

Watch It

Watch for Java news as "Sun Opens Java"!

Related reports: Wall Street Journal

About

MortazaviBlog

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today