Thursday Jul 30, 2009
Wednesday May 27, 2009
By MortazaviBlog on May 27, 2009
Sunday May 10, 2009
By MortazaviBlog on May 10, 2009
On my last count, there are now 20+ Sun Contributor Agreement (SCA) signatories whose names appear on the master list and who are interested in contributing to MySQL. Only this week, three new members signed the SCA.
These 22+ signatories have all been added since mid-February when we launched the new, Sun-compliant SCA signing process. Before the end of 2009, if we proceed at this same rate, MySQL SCA signatories list should grow to about 70 to 90 contributors.
In the meantime, contributions from many of these contributors have already been accepted and integrated. (I had earlier pointed to Armin Schöffmann's contribution as a simple example of how all this works.)
Some people continue to wonder why an SCA is required.
First of all, it is important to note that by signing the SCA the contributor retains copyrights while also granting those rights to Sun as the project sponsor. This granting is very specific to a particular code base and the community around it. (This is a code base that has been available under GPL.)
Second, as I have summarized, in a series of Golden Rules for Open Source Contribution-Based Communities, several important rules for such communities help it to operate well. As part of rule G, "Setting Expectations," I did mention how
2. Anticipating the future and related risk management helps all market participants to reduce transaction costs.
However, I failed to add that an important ingredient in that risk management is the management of ownership claims.
I believe this particular aspect of rule G, which is implicit there, and which perhaps needs to be made more explicit, explains clearly why something like an SCA is required in order to maintain a flow of contributions to MySQL in a form that allows clear code ownership.
Note that other open-source communities, such as the Apache Software Foundation, also require their own contributor agreement. Often, these agreements are there to protect the maintainers of the project/product or the general integrity of the products' ownership.
BSD-based communities seem to avoid this need by posting various clear signs in various places -- in their member-initiation or commit e-mails -- that all contributions are made under BSD. However, these communities have remained somewhat fragmented due to the greater openness of BSD licenses. Don't get me wrong. I love BSD. Note that often, BSD contriutors would rather contribute to a BSD project. The whole objective of contributing to a BSD project is that you are building a based that can be used by anyone for open and closed business with that same base. This is very unique to BSD type or Apache type licenses and forms one of the main reasons contributors contribute to these projects.
So, let's now go beyond the question of SCA and see what else is going on.
The update and simplification of SCA submission process for MySQL, came along with equally important simplification of forge pages for contributors and with an effort to speed up the review of contributions and continuting with greater openness in MySQL development processes. [These apparently fragmented but hopefully useful (and ultimately coherent) steps have all been part of a larger initiative to facilitate openness, community participation and contributions. Again, please refer to the Golden Rules. Hopefully, you can faciliate and help the MySQL community to get more open and vibrant as an open-source community.]
It is important to note, here, that roots of this initiative go back to some years earlier. So, the initiative is related in part to a continuing series of efforts to make MySQL more open and more contributor friendly, including the famous "quality contribution program," which was originally launched by the MySQL community team. (In a sensem the "quality contribution program" has evolved into this simpler, more robust model and many of the lessons learned there have also been applied and used here.)
Under the SCA, contributors can contribute to all MySQL open-source products in open forums and issue tracking "systems"-- internals list, bug tracking system, worklog system. I put quotes around "systems" because there's more to be done to make these systmes work better together in a more open environment. Note that the MySQL team prefers to receive code contributions and bug fixes through the first two modes because those two modes (i.e., bugs db issue tracking and the internals mailing list) better afford two-way communications. Note, too, that contributions can be at the level of bug fixes or features.
Why would anyone contribute?
Well, there's a great deal of challenge to contribute anything to a software as sophisticated and complex as a database.
Besides the reputational effects, there's also this practical effect that once a contribution has been absorbed, the contributor will no longer have to worry about constant merges to get the effect he or she expects form MySQL.
Of course, there are many other reasons as well. For example, there are those who are just problem solvers, and find it exciting to contribute to MySQL. However, let me stop speculating on this any further. Instead, let me point you to an "internals" posting by Stefan Hinz, regarding a "MySQL University" session on replication features in 5.1 and 6.0.
Tuesday Apr 21, 2009
By MortazaviBlog on Apr 21, 2009
Wednesday Apr 15, 2009
Friday Feb 13, 2009
By MortazaviBlog on Feb 13, 2009
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.)
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
By MortazaviBlog on Feb 05, 2009
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.
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.
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.
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.
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.
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.
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.
1.Work is conducted in increments.
2.Each contribution does one thing.
3.Each contribution has a test case that exercises it.
1.Contributor community assets (channels of communications, forums, bug databases, etc.) are developed to improve learning by all participants and contributors.
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.
Monday Jun 02, 2008
By MortazaviBlog on Jun 02, 2008
"The database support in NetBeans allows users to connect to a database and view and modify the database structure and data. These graphs show which database servers users connect to most often."
Thursday Feb 22, 2007
By MortazaviBlog on Feb 22, 2007
In his commentary, "Competitive Cooperation" written to honor the 50th anniversary of the Treaty of Rome, the 2004 Economics Nobelist Edward C. Prescott reminds the readers of the importance of commerce in mutual economic development and growth.
Let's review some historical facts. With the signing of the Treaty of Rome in 1957, France, Italy, Belgium, West Germany, Luxembourg and the Netherlands formed what would eventually become the European Union. For six decades prior to the treaty, those countries were about 55% as productive as the U.S. But over the following 25 years, those countries essentially caught up to the U.S. in terms of productivity.
When that historic economic treaty was signed, three countries were roughly on par with those original six -- Denmark, Ireland and the United Kingdom. However, a funny thing happened in subsequent years -- those three countries started falling behind their former peers. So in 1973 they joined the original group and their economic fortunes improved. It took time, but the U.K. now is as productive as Germany.
...And what of Latin America? Unfortunately, the region provides a case study in the perils of protectionism. Recent research by my Minneapolis Fed colleagues, Lee Ohanian and Jim Schmitz, and two co-authors, shows that from 1950 to 2001, per capita GDP for Europe increased 68% relative to the U.S.; Asia increased by 244%, while Latin America decreased by 21%. This is all the more striking when we realize that Latin America's per capita GDP actually exceeded Asia's by 75% in 1950.
Perhaps, it is time for a Latin American Union.
Some nations use trade policies to punish others. Whether politically motivated or otherwise, policies that raise barriers to potentially beneficial trade or create trade zones or alliances that exclude others are ultimately doomed to lead both groups worse off. Of course, the exclusionists, when powerful, come to believe they represent the house with infinite resources in the trade gamble.
Note: In his Getting it Right: Markets and Choices in a Free Society, Robert J. Barro advances points similar to Dr. Prescott's.
Wednesday Jan 31, 2007
By MortazaviBlog on Jan 31, 2007
Sunday Jan 21, 2007
By MortazaviBlog on Jan 21, 2007
Wednesday Jan 17, 2007
By MortazaviBlog on Jan 17, 2007
The cost savings and efficiencies of Test-Driven Development (TDD) should be clear not just to any hardware engineer but also to software and other engineers, system designers and developers. In fact, even when we imagine we are developing without a test, we implicitly have some kind of test in mind: We build systems in order to elicit specific responses to specific stimuli (tests?) upon those systems. Most software developers know how a good test can drive their work, particularly when the system is complex with multitude of constraints and also when there are volumes of existing tests to detect regressions.
Wednesday Dec 20, 2006
By MortazaviBlog on Dec 20, 2006
Bernard Traversat tells us about a new release of the Looking Glass Project.
Looking Glass is a 3D GUI desktop environment that provides robustness and stability for most of the 3D window effects. The 1.0 release gives the user better performance, support for JDK 1.6 and Java 3D 1.5, ease of installation with the mega bundle distributions for Solaris X86, Linux and wWindow. Bernard says that his team contributed lot of the X extensions to X.org. They also now have a Netbeans module for Looking Glass.
Innovations on the desktop do not come often and this one is worth a close, serious look.
- Oliver Williamson Wins the Nobel Prize in Economics
- LBL, Technology and Life
- At the Mount Whitney Summit
- More on Derby
- Advancing MySQL Open Development One Important Step Forward
- A Prize Well-Deserved
- ADO.Net Entity Framework on MySQL
- How a Differential Gear Works
- Clunkers and Financial Institutions
- Workbench 5.2 Alpha
- Adam Bosworth
- Bryan Cantrill
- David Edmondson
- Edward Felton
- Hinkmond Wong
- His Holiness, The Duke
- James C. Liu
- Lawrence Lessig
- Paul Rogers
- Philip Greenspun
- Richard Friedman
- Richard Sharples
- Roberto Chinnici
- Seyed Razavi
- Simple Signs
- Simson L. Garfinkel
- Tim Bray
- Yusuf Goolamabbas
- / Persian (فارسی)
- /Art (هنر)
- /Sun Microsystems Inc.