[os-infrastructure] State of the onion
Andrew Ross
Andrew.Ross at ingres.com
Fri Jun 6 12:57:19 PDT 2008
Bodo,
It isn't how many contributions we've had.
Incidentally, a handful from Marty Bowes, OGR driver support enabling
GIS applications to run on Ingres from Frank Warmerdam, a couple from a
team in China, a few contributions from interns in
Ottawa/Warwick/Ilmenau, an EXPLAIN command from Kai-Uwe Sattler from
Ilmenau U., a joint contribution Chris Dawe did with Alex Hanshaw, some
Google summer of code projects, etc. These are the ones I know about off
the cuff.
More importantly, how many people have WE brought into the community and
mentored to get them started. That's the key.
In terms of your comments about DBMS core developers. Two weeks ago I
sat in a room with over 200 PostgreSQL community members at pgcon. Not
all are core mind you, but not all need to be. It was the same thing at
osbootcamp6 for the PostGIS talk. Building a community around an open
source DBMS is entirely feasible.
If anything, we have a huge advantage in our dedicated employees and
resources.
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Bodo Bergmann
Sent: June 6, 2008 3:42 PM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] State of the onion
So, if we take out Karl,
how many community contributions have been provided to the Ingres
codeline within the last 6 month (I'm not asking how many did we
integrate)?
And how many changes have been submitted by Ingres staff.
DBMS core developers are not falling from the trees like Java or VB
developers.
So, I think the 95% is a good guess.
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Friday, June 06, 2008 8:40 PM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Subject: RE: [os-infrastructure] State of the onion
David,
I would like to point out that the work to develop Ingres' open source
infrastructure such as svn, trac, lxr, and more started in January and
was largely done using free interns and thus cost us very little. The
work ahead is being scoped and will have a calculated price range as
part of the business plan. I think you're being unduly harsh for
something that is a few months old. Moving forward, I'm asking you to
help ensure the list is complete, and size up any items on that list.
This would be most helpful.
I'm not sure who you were referring to about the part gosh we need to be
open source & use popular open source tools. I haven't hear that myself.
I hope that wasn't the message you felt coming across from me.
>From a business perspective, there are very real benefits that arise
from open source:
- lowered development costs
- reduced risks
- reduced transaction costs doing business with others
- faster trust
- improved time to market
- reduce marketing & sales costs (via. Mindshare)
- increased innovation
(I could go on, and others could add to this list)
This is how a graduate student's project evolved into something that is
challenging multi-billion dollar companies and how open source is a
multi-billion dollar business in its own right.
If indeed 95% of the work will always be Ingres employees, meaning we're
open code, but not open source. It also likely means nothing much is
different from our closed source days and draws into question what we
expect will change for the business. Is this what you truly believe?
Andrew
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
David Tondreau
Sent: June 6, 2008 12:35 PM
To: opensource-infrastructure
Subject: Re: [os-infrastructure] State of the onion
[snipped]
4. Perhaps most important, from now until the end of time, 95% or
more of the code changes made to our product base will originate
from engineers within these walls. You can even put the code in
subversion, make it publicly available, make everybody in the
world a committer and still, 95% of the contributions will come
from within. Personally, I would be surprised if it were ever
more than 1 in 250 but 1 in 20 serves the purpose of this
exercise.
So why, pray tell, are we trying to wrap ourselves around a tree at an
unknown cost and unknown level of disruption to the business to satisfy
5% of the engineers working on the code? That simply doesn't make any
sense To hear some talk about it, the answer is "by gosh, we have got
to be an open source company and we have got to use subversion because
we need to use the most commonly accepted open source code management
tool or we will be the laughing stock of the world." Not to be unkind,
but this is all just plain BUNK. Lets take a look at some /_*big*_/
open source projects -- projects that Ingres compares to (mission
critical, huge code base, enterprise class solution) that /noone in
their right mind/ would accuse of not being "true open source":
*Mozilla*
Publicly accessible /read/only/ repository via CVS. Internally, they
decided in late 2007 to use Mercurial. Encourages download of source
code via tarball. From the Mozilla web site, here is the Mozilla
process for externally submitting a bug (read this entire thing):
"CVS is used to manage the documents on our web site. To submit
changes to a current document you can either use CVS to check out
the document <http://www.mozilla.org/contribute/writing/cvs#access>
and create a patch with cvs diff -u or you can click the "Edit this
page" link at the bottom of the document you are changing to make a
patch with Doctor.
Once you have a patch, submit the file to the owner of the document
by attaching it to a Bugzilla bug report and asking the owner to
review (and check in the changes, too, if you don't have access). If
the document doesn't list its owner, click on the "Document History"
link at the bottom of the page to see who has recently updated the
page and ask them. If all else fails, mail webmaster at mozilla.org
<mailto:webmaster at mozilla.org>.
As with the source code, if you establish a track record of good
work then you may be granted access to the repository, especially if
you contribute documents and become their official owner and
maintainer. To get access, you'll need to submit a CVS Contributor
Form <http://www.mozilla.org/hacking/form.html>. Read mozilla.org
Content and CVS <http://www.mozilla.org/contribute/writing/cvs> for
CVS information specific to our doc tree. The document Source Code
Via CVS <http://www.mozilla.org/cvs.html> explains where to get a
CVS client for your platform and has pointers to CVS documentation."
*OpenOffice.org*
Publicly accessible /read/only/ repository via CVS. Source available by
tarball. Submission process from the web site:
"How to submit code to OpenOffice.org
We ask that all code submitted to OpenOffice.org be submitted via
Issue Tracker
<http://qa.openoffice.org/issue_handling/project_issues.html>. In
your submission please list "Issue Type" as PATCH. Your code will be
sent to the committer for the appropriate project."
*MySQL*
Primary downloads are tarball snapshots. There is a read/only
subversion repository. Community contributions? Not really. From the
web site (note the word "envision" in the first sentence):
"This is how we envision the contribution process can flow:
1. Contributor suggests to work on new or existing WL, or Bug,
not in the list below.
1. This happens by emailing community-contributions <at>
mysql <dot> com.
2. We review and accept co-operation and include this
suggestion in the list below
2. . Contributor suggests to work on a WL or Bug in the list
below.
1. This happens by emailing community-contributions <at>
mysql <dot> com.
3. We sign up the Contributor, and assign the WL or Bug to
him/her.
4. We assign a MySQL mentor to the Contributor
5. The MySQL mentor will advice the Contributor on the work
process, and provide design and implementation guidance.
1. For WL's and more significant Bugs we might request to
understand your solution approach (or even design) before you should
start implementation, to ensure you don't spend time on something
that needs significant rewrites later
6. The Contributor provides patch for code-review, and MySQL
Mentor ensures timely feedback. This step might be repeated some
times as required.
1. Contributions should be provided under the Contributor
License Agreement (CLA), which the Contributor needs to approve of:
CLA
7. MySQL Mentor (or the Mentor's lead) approves the patch for
inclusion in Community Preview.
1. This Community Preview comes as snapshot binaries from
our build and test environment (called: Pushbuild). Main platforms
are supported (Linux, Windows, Solaris, perhaps Mac OS), other
platforms needs to be built from source.
2. MySQL is committed to providing regular snapshot updates
to this Community Preview, so that patches provided to us are made
available in a short timeframe.
8. Bugs towards the patch is filed in a normal fashion to
bugs.mysql.com (version = Community Preview) and by default bugs
will be assigned to Contributor.
9. After the patch has been seen successful in the Community
Preview, MySQL will decide on to include it in the appropriate MySQL
Server version. The default assumption is the current available
alpha version for WL's and the oldest relevant MySQL server version
(and forward) for Bugfixes.
The net-net here is that of these three well established open source
projects, all primary source download options are tarballs, two use cvs
and one uses subversion (hardly a quorum on subversion), all
repositories are read only and all use their bug tracking system to
allow external developers to submit code changes.
All this angst about public read/writable source repository and energy
expended to ensure our two copies of the truth are in sync is, in my
opinion, downright silly. I am fine if we want to figure out how to
make piccolo constantly refresh a publicly accessible read only
subversion or cvs code repository. That would put us on par with
Mozilla, OpenOffice.org and MySQL. But lets try to solve this public
committer thing when our inability to respond to public contributions to
the source code is eating our lunch (and stopping us from making money).
Until then, it seems to me that we are as open source as everyone else
-- just not very organized or transparent about it. And THAT, my
friends, is the bigger problem we should be trying to solve.
David
David Tondreau
Architect
*Ingres Corporation*
_david.tondreau at ingres.com <mailto:david.tondreau at ingres.com>_
*PHONE* +1 703.738.4811
*FAX* +1 650.587.5550
*_www.ingres.com_* <http://www.ingres.com/>
This transmission is confidential and intended solely for the use of the
recipient named above. It may contain confidential, proprietary, or
legally privileged information. If you are not the intended recipient,
you are hereby notified that any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you have received this
transmission in error, please contact the sender by reply e-mail and
delete the original transmission and all copies from your system.
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
_______________________________________________
opensource-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
More information about the opensource-infrastructure
mailing list