[os-infrastructure] The infrastructure

[Joe Abbate]

Hi Andrew,

Andrew Ross wrote:
> AR - I felt this way based on precedent and the fact I didn't see anyone seriously working on it. There's good discussion happening now. I still suspect it's going to take some time to come to consensus, put together a plan, revector resources, and execute on the plan. It's possible this may get done by the end of 2009. Unless something unexpected happens I'd expect it'd be more likely in mid to late 2009. This is up against other business priorities and when something exciting comes along, it's going to be harder to revector resources.
>   

See, you're admitting there are other business priorities.  So is your 
plan to subvert (pun intended) those priorities?

> AR - Perhaps it's just an opinion but for what it's worth, it is working as a strategy to develop geospatial, CAFÉ, bootcamp and more. External companies, people, and institutions have given us money & resources based on my opinion & track record. From what I see, the other partnerships (Jaspersoft, Alfresco, Rpath, etc.) we're working are doing much the same thing. Who says open source and commercial have to be mutually exclusive?
>   

I presume those are worthwhile activities but how do they mesh with the 
long range plans of the company?  For example, contrast the rhetoric in 
the "Ingres Puts the Community First" press release with the "About 
Ingres Corporation" blurb that appears in that release and others:

"Ingres Corporation is a leading provider of open source information 
management services to the /enterprise/. Built on over 25 years of 
technology investment, Ingres is a leader in software and service 
innovation, providing the /enterprise/ with proven reliability combined 
with the value and flexibility of open source. The company's 
partnerships with leading open source providers further enhance the 
Ingres value proposition. In particular, Ingres is working with leading 
/business intelligence/ providers to deliver appliances that combine the 
benefits of open source with advanced reporting and data analysis 
capabilities."  (emphasis mine)

Or consider this from the latest press release:

"Roger Burkhardt understands the needs of organizations in various 
sectors that demand reliability, scalability, and security."

I am *not* saying that commercial or open source are mutually exclusive, 
but I do believe that open source cannot exist, first, without 
commerce.  If thousands of enthusiasts helped Linus in the early '90s, 
it was because the modern economy provided most of them with gainful 
employment and afforded them enough leisure time to devote some of it to 
Linux.

> AR - These are good questions, and we'll get the chance to ask them. The timing will have to be right. I know some had these questions on their mind but didn't say anything at the summit for fear of putting the execs on the spot. Add this to the potential delay factor I described above.
>   

I don't see why "the timing has to be right" unless you want to ask the 
questions when there is a de facto infrastructure in place to constrict 
the answers.

> AR - It's hard to ignore the fact Linux, Windows, and MacOS are platforms that are growing rapidly and absolutely dominating the industry while other platforms are barely growing at all or are shrinking. Even our staunchest VMS or Solaris customer would likely think us foolish if we were ignoring Linux, Windows, or MacOS.

I doubt very much whether customers care about whether Ingres is running 
on any given platform, open or closed.  As in Roger's quote above, they 
care much more about whether Ingres and the platform are reliable, 
scalable and secure, and they care about costs.  As an example, 
currently VMS customers are clamoring for Ingres on Itanium because they 
have the HP Damocles' sword that Alpha will no longer be supported past 
2011.  And they don't do that because they love Itanium or because they 
think it's a superior technology or because they think VMS is the way of 
the future, but most likely because they have an "investment" in people 
who know Ingres and VMS and in software that runs their business and 
allows them to service *their* clients.  I always recall a presentation 
given by Michael Stonebraker where IIRC he was talking about POSTGRES 
(the UCB project), the Ingres "Intelligent Database" 6.3 (which added 
some POSTGRES technology to Ingres), RISC processors and RAID, and he 
argued that all these technologies would make it much easier for 
companies to literally throw away their old software and quickly move to 
implement with the new technologies, supposedly on the basis of a 
cost-benefit analysis.  It certainly has gotten better, but I'm afraid 
that companies still don't react as fast as Stonebraker anticipated, and 
with good reason.

>  The fact remains that we brought in some interns and asked them to follow our instructions to build on Windows and Linux and it took weeks to get a build going. Roger mentioned similar experiences on this list. I've heard the same comments from many other people. Clearly it's a low hanging fruit problem and worth fixing.
>   

I have no dispute with the fact that our build procedures are not easy.  
Back at CA, I had to help two separate VMS customers who wanted to build 
Ingres from source on VMS (some of it is probably still in the forums).  
They eventually were able to do it.  Unfortunately, I don't know if they 
continued to build newer releases, but once you have done it 
successfully once I doubt one needs much guidance a second time around.  
Now there are two ways to deal with this issue:  document the existing 
build procedures so that even a neophyte can get it right from the 
beginning, or throw it all away and use a different procedure.  Four 
years ago we went through that process with Jam (previously Unix used 
ming, Windows nmake and VMS used MMS and DCL scripts).  It was not easy 
(73 revisions to Jamrules in the first five months) and it may be argued 
we're still trying to get it right (for example, SE had to adapt the VMS 
procedures to their needs).

> AR - Perhaps a difference between me and those who haven't been through the same experiences is that I'm privy to the reaction to the items I proposed. I've helped/commiserated with a few others around the company as they went through the same process. I'll share it's never been easy. Everything is scrutinized, prioritized, and justified. Even if it's a good idea, there's still no guarantee it'll happen. There's just more things we'd like to do than we can afford to do. (typical everywhere frankly, probably tighter in a start up) I perceive that evolutionary changes revectoring existing budgets or leveraging outside money like grants, etc. tend to tip the balance to get things started. 
>   

My main concern is that without some clear position, right now, from 
people like Roger, Bill, and Emma, as to what direction they see the 
Community Edition taking, the infrastructure efforts may cause more 
damage than benefit.

Allow me put forth a straw man so that others can poke holes through 
it.  Say Bill and Emma were to announce that a group of six Ingres 
employees were to be devoted full time to the Community Edition while 
the rest of Engineering would go on supporting Enterprise Edition work 
while allowed to spend, at their own discretion, up to 10% of their time 
on "community" work.  Say they also stipulated that Community Edition 
would be targetted only at Linux, Windows and OS X, i.e., specifically 
excluding VMS, Solaris, HP/UX, AIX and other Unix variants.  Further, 
that two of the employees would be devoted to OpenROAD/Empire on those 
three platforms.  Conversely, that EA and EDBC would not be part of any 
community work.

Given a position statement like the above, infrastructure discussions 
can be much clearer, since we've eliminated platforms like VMS where 
there is no Subversion client or with antiquated GNU tools.  It also 
makes it easier to look at issues and prioritize, e.g., if someone is 
working on a customer problem on RHEL, they're helping Enterprise, even 
if it indirectly helps Community.  The Community team can then come up 
with specific proposals as to how they will maintain their codelines, 
how changes from Community will be fed back to Enterprise and vice 
versa, and (for example), choose to stay with Trac as their bug/issue 
tracker, without worrying about feedback to and from Bugs and Service 
Desk.  In other words, the Community team would be mostly an independent 
entity within the company.

Again, this is is just a straw man, not a proposal.  Contrast it to (a) 
the status quo and (b) the discussion of keeping Subversion and Piccolo 
in sync, and Bugs/SD and Trac/JIRA/etc. in sync, and almost everything 
that Ingres does moving inexorably in the open source community direction.

Joe