[os-infrastructure] State of the onion
Durwin Wright
Durwin.Wright at ingres.com
Mon Jun 9 09:01:17 PDT 2008
David
I cannot agree more completely with your statements. What is missing in
these discussion are the best practice processes that we should be
following in trying to achieve the kind of "open" that is needed to
practice true open source.
The only thing that I have seen senior management state publicly is that
there is a desire to make it easier for people and groups outside of
Ingres Corporation to make contributions. I have not seen anything from
senior management that supports the notion that we will move away from
Piccolo, Bugs and Service Desk anytime soon.
Maybe I missed a meeting when this was decided but so far, I have not
seen anything in my notes, email archives or direct discussion with
senior executives that say we are going to do this. There will be a
cost associated with such moves. These costs need to be accounted in
the budgets. The people who control the budgets are the senior
executives. Engineers can do research and make recommendations but
ultimately the decision lies with management with budget authority as to
whether we are going to spend the money needed to achieve these goals.
Otherwise we risk proceeding with a unfunded mandates. People who know
me understand completely how much I dislike unfunded mandates.
I have joined the WiX open source project. I have done this for two
reasons: (1) I am really interested in this open source technology and
think that I can eventually make contributions and (2) I wanted to see
how other people run their open source projects. I plan to join at
least one and possibly two more open source projects. I want to learn
how successful projects are run.
I would really like Ingres Corporation to be considered one of the
leading open source companies. As it stands today, we have a long way
to go to achieve these ends. I hope we can learn from other successful
projects and avoid the mistakes made by others.
-Durwin
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
David Tondreau
Sent: Monday, June 09, 2008 8:19 AM
To: opensource-infrastructure
Subject: RE: [os-infrastructure] State of the onion
Andrew,
You said: "We put together a plan in January that detailed where we'd
be now. The senior management team supported it."
Really? I'd love to see a copy of "the plan." I never new one existed.
Any reason why "the plan" was not shared with the rest of support, Q/A
and engineering in January when it was presented to and supported by
senior management? Is "the plan" top secret or something? More
importantly, is there any reason why support, Q/A and engineering didn't
have input into "the plan" leading up to its presentation? I've been
though all of my e-mails and can't find any reference to being informed
about an open source plan for this year.
I think this just goes back to my main point in my post: we lack
organization and transparency in our open source efforts. Forget the
community, we can't even get the communication and planning going among
ourselves. This mail list is the first forum I've seen in which anyone
has a chance to actually get a glimpse of what is going on in the inner
circles and even it was cloaked -- with no organization-wide
announcement of its existence to this day! Even now, you have a lot of
people just finding out about it. That just doesn't make sense unless
you are trying to be selective about participation.
The process you seem to want to focus on is all about "source," not
about "open." And THAT is the problem. That we the edict that I heard
from Bill was this: "Go engineer in the open." Engineering starts with
plans and designs, not code. That's where we should be focusing our
efforts. If we did, we could get potentially get community members to
contribute something that WAS higher up the priority pole. We need to
tell the community our direction and then get them to help us get there.
We need to lead. I agree with Alex -- what we lack right right now is
leadership. Where are Ingres products going and how can the community
help us go there? That's the plan we need.
That's why the OpenROAD team has trained its open source efforts on the
wiki, not subversion. That's why we chose (without anyones permission
or direction and in direct contradiction to the current DBMS model) --
to use a Fedora style project for OpenROAD. Thus Empire. We wanted to
show leadership. We wanted to craft the message, develop the community,
and get people participating. So far its working but its still early
on. We have signed up 20 community developers (they have signed a
contribution agreement) and another 22 community members (they want to
be part of the party). What they are all asking for now is how they can
participate -- what projects we need help with and what the plans are
for OpenROAD. That's where my current struggle is. Not a single one
has asked why they can't see the code in an online repository. When we
have 10 code submissions a day from the outside, I'll start the process
of trying to figure out how to solve that problem. Like Durwin said,
that's not going to occur for the next 12 months so its nothing to worry
about.
My suggestion is simple. We're pretty good at "source" already. Let's
figure out how to be "open." Then we can worry about how to be "open
source" in a way that exceeds what other major open source projects are
doing today -- if there is a compelling business reason for that. I
think that's probably what Bill and the board are really looking for.
David
-------- Original Message --------
Subject: RE: [os-infrastructure] State of the onion
Date: Mon, 9 Jun 2008 08:55:05 -0400
From: Andrew Ross <Andrew.Ross at ingres.com>
To: Alex Hanshaw <Alex.Hanshaw at ingres.com>
CC: David Tondreau <David.Tondreau at ingres.com>
References:
<21C3E073B82EFE4F8A76536D9066FE5601F49A77 at USINVMAILB01.ingres.prv>
The direction has been set by Roger, Tom, Bill, Emma, Deb, the board,
and others long ago. Agreed they haven't stated specifically which tools
to use and how to use them. Frankly, that isn't their job, it's ours.
Regarding a brighter future with an open source community (or not): Look
at open source from the point of view of an external company deciding
between Oracle, DB2, Informix, SQL Server, etc. and Ingres. Why choose
Ingres if it is just another closed source RDBMS with statistically
insignificant market share, a mild feature deficiency compared to the
industry leaders, and comparatively few resources? Being open source
differentiates us. Successfully developing an open source community
gives us a shot at competing with the market leaders. If you disagree
here, please explain why as I would like to understand.
Previous to Ingres, I worked at Nortel where over 70K people were layed
off. Nortel was the multi-billion dollar leader in digital telephony. In
a matter of years, global competition, deregulation, and commoditization
of the telecommunications industry brought them to their knees. This is
relevant to us in two ways. The big 3 are not immune, and secondarily
we're much smaller and things could go south for us much quicker and
easier. What would happen if a significant portion of our VMS customer
base decided Oracle on Linux was a good enough deal for them to move off
Ingres on VMS?
The point is there are plenty of business reasons to go open source and
that the leadership team clearly did state that is our direction.
Given that we set a direction to go open source, and pretty much next to
nothing happened, my work and presentation was an empirical look at what
it means to be open source, what deficiencies we have, and start
addressing them. My approach was to start with the things we know we can
realistically accomplish in the short term. Look at this as my 10%+. In
that light, I can't understand why the criticism. Would it be better I
did nothing? How precisely is this "Gosh we need to use open source and
use open source tools to do it?"? That's a bit derogatory don't you
think?
I am not saying the plan to open source success is plotted in fine
detail and available in PDF form for review. Quite the contrary, we have
just gotten started.
We put together a plan in January that detailed where we'd be now. The
senior management team supported it. We then executed on it and got it
done. We now have tools, infrastructure, a core team of people helping,
and more engagement in the community than we've had in a long time. It
isn't perfect, but it is something people can rally around and improve.
Again, for my 10%, I see this as pulling my share and then some.
What I'm suggesting to people is to get involved, help define what's
left to do, and we'll review/approve/execute again. Be specific stating
what's missing, propose options, propose who needs to be involved, etc.
Andrew
-----Original Message-----
From: Alex Hanshaw
Sent: June 9, 2008 7:48 AM
To: Andrew Ross
Cc: David Tondreau
Subject: FW: [os-infrastructure] State of the onion
Hi Andrew
"gosh we need to use open source and use open source tools to do it"
pretty much summarises your presentations at the dev summit and Emma
backed up that message by saying "We must be open source and you should
all dedicate 10% of your time to Open Source."
This was THE message of the summit. I'm baffled by your response. If
this was not the message why are we looking at svn at all?
My own feeling was that the message also included an under tone of "Get
on the open source train or else". I'm OK with that. Business is
business. I'm a paid employee that likes getting paid. We all do what
the business wants us to do because it pays the bills. David has bravely
asked difficult questions despite the under tone in the development
summit message. I take my hat off to him for doing so. As long as the
difficult questions are being asked constructively, it's all good and
this should be encouraged. More importantly answers should be given. I'm
not sure your response does that.
I do agree that a good Open Source policy will be good for us in the
long term. The problem is we don't have a policy to implement, good or
bad. The questions are bigger than lone developers. They need senior
management input from Sales, Marketing, Product Management and
Development. Who's driving that input and policy process?
I'm happy to have hopped on to the open source train. Doing so did not
erase my memory. I still know who waved the open source flag at the
start of the summit. If between the lines you really didn't say "gosh
lets be open source" then what were you saying?
I believe our biggest problem at the moment is that the game plan is
not more refined than "Gosh lets be open source". If there is a more
detailed plan no one's told me the detail. To me this was the important
point that David had raised. Saying that what have we done so far was
done by interns does not tell us that we actually have a more refined
game plan or what the details are if we do.
Regards
Alex
-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: 06 June 2008 19:40
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
--
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
More information about the opensource-infrastructure
mailing list