Visual FoxPro DevCon 2005 Interview with Alan Griver and Ken Levy
editor David Stevenson interviewed Microsoft’s Ken Levy (VS Data Product
Manager) and Alan Griver (VS Data Group Manager) about the Visual FoxPro
Roadmap and upcoming project for enhancing VFP code named Sedna. The interview
took place on June 14, 2005 at the VFP Advisor DevCon conference in
Interview: June 14, 2005
Published: August 2, 2005
David Stevenson: VFP9 is on the scene now and seems to be getting a great response from VFP developers who have tried it so far. What are you hearing from the community so far?
Alan Griver: We’re hearing pretty much the same thing. About a third of the community has upgraded so far, which is very much in line with expectations. People are saying it’s the most stable version of VFP. People are thrilled – you know you talk to any four or five people and you get four or five different responses on their top feature, whether it’s the reporting enhancements, the new data types, the SQL enhancements, etc. So, I think we hit a home run with this. I didn’t think we could beat 8, but we actually did.
Ken Levy: The other thing is that people haven’t quite tapped into the full extensibility model. At the same time, you have things like GDI+ and other features that we included that aren’t necessarily highlighted. I think there is a lot to be discovered over the next 6 to 12 months from samples, articles, and so forth, that will surface quite a bit more functionality in VFP9 that people haven’t read about or don’t even know exists. The BindEvent [enhancements] are probably still an untapped area of power. There are a lot of things that we can do with 9 that we haven’t done yet.
David Stevenson: There were some comments made the other night at the meeting about there being surprise from the time you started working on VFP9 until you finally got feature-complete. I know the community was surprised, but you indicated that some of the Microsoft people were surprised too. How do you think that will play into the new plans for Sedna? You have some parameters laid out right now for what you think Sedna will include, but it looks like two years is a long time, and people could come up with a lot of cool things.
Alan Griver: Well, if you think about it, VFP9 took about two years also, so that’s about on the basic schedule. What happens is that you go ahead and set a number of core pillars for a release, and then you do some executive reviews where you say, “Here are types of things we are looking at.” They tend to be kind of architectural concepts, and the way you know that you’ve nailed them right is because as you’re developing, it suddenly leads to a bunch of new things that can be done down the road.
I used to see that all the time when I was developing using Fox and using VB6. Here it’s the same case. We went ahead and said, “Well, we know we want to enhance the report writer,” for instance. Here’s an idea architecturally for how we want to do it, and all of a sudden, multiple detail bands fell out of it, and multi-pass reporting fell out of it, and all of these other things came just because we had architecturally designed it properly.
That’s what we believe will
happen also with Sedna. We’re setting some core architectural approaches, and
we’re saying that we’ve engineered the product for extensibility. I think
Ken Levy: I think with all these new technologies coming, and the extensibility that gives us the ability to glue these things together, I have a pretty good belief that we can come up with some stuff that will be pretty exciting. Just here in the keynote, I was excited about some of the demos and I could feel it in the reaction of people. Like, the potential – where are they going to be two to five years from now. So, we’re just scratching the surface and there’s a lot of potential – such as FoxPro’s extensibility and data-driven aspects of programming.
David Stevenson: One thing that people are wrestling with now is how to interpret the new style of update that Sedna seems to represent. You described it in the keynote as being like an SP2 plus some add-ons, saying that it’s more than just a service pack. But, if that’s the case, why isn’t it being called 9.1 or 9.5 or even VFP 10?
Alan Griver: First of all, we haven’t given it a name yet. Right now it’s called Sedna, but we haven’t said whether it will be a 9.1 or 9.5 or whatever.
David Stevenson: Right, but you described it as a service pack plus add-ons.
Alan Griver: If you think of, for instance, Windows XP SP2, that added a lot of functionality to Windows as well, similar to how Sedna will do that for Fox. We’re finding that we may not have to heavily touch the core bits – that additional DLLs, just like any application you write might have one core EXE but a bunch of different DLLs, additional Fox extensibility can give us a wide range of features. And it keeps us on a really stable base, so that also helps with people migrating, and et cetera. If it worked on VFP9, it will continue to work because it’s the same code. So, you get the enhancements and you get the stability.
Ken Levy: One of the things we did after we shipped version 9 is we stepped back and said rather than following a traditional path, we looked long-term. I don’t mean a year from now, I’m talking three to ten years. What’s our path. Where do Fox developers need to be, what kind of things will they demand, what will their users demand. With our team’s limited resources, just like with 9.0, we had to be very meticulous in what we prioritized. We can’t just do everything. If we were to spend a whole lot of time, for instance, on the grid control, it could take a huge amount of time in planning, development and testing. It’s not that easy to just crack open something and make changes.
If we took all of that effort and put it into something that had to do with Longhorn (Windows Vista), for example, it might benefit users and their applications far more. So it’s like the quote from Spock in Star Trek, “The needs of the many outweigh the needs of the few, or the one.” That’s something that we think about on occasion when we’re thinking about these features. We have to sit back and try to decide what are all of our options, and let’s think out of the box. What are the options of what is it, how do we package it, how do we distribute it. We’re keeping all of our options open and we’re thinking that having regular betas that will allow people to see what we’re doing and know way in advance exactly what we’re thinking. So, it’s not this big surprise in six months – what did they announce. And it’s like this big letter with all the new features and hardly anyone knew what was coming, and then they wait six months until the product releases – that type of thing. Here [with Sedna] on a monthly basis they see the evolution of it and have input and the community becomes more an extension of the FoxPro team itself.
Alan Griver: This is something that we’ve seen be very successful with Visual Studio, with the feedback center and also the CTPs, the Community Technology Previews. Visual Studio has been providing a release that says it may not be up to beta quality, but you can see everything that we’re doing on a month-by-month basis. Now SQL Server has taken that on, and now Fox is looking at doing it as well. It’s something that I think you’ll see more groups do.
Ken Levy: This is not a marketing plug, but it’s a true technical tip for software developers. Look into getting a very inexpensive program called Virtual PC. It’s a great way of running beta software and experimenting with things, so you can keep up to date, put a little time in there and give us some feedback. I think that will go a long way in our efforts in building Sedna.
Alan Griver: I do want to make one thing pretty clear for people who are worried about how to keep up with these monthly releases – something that the Visual Studio community went through – and the answer is that you don’t have to pick them up every month. When you find you have some extra time, you go and download the latest version, play with it, run your current app on it and report bugs.
David Stevenson: Do you plan to be releasing that often – monthly?
Alan Griver: That’s one of the things we’re looking at. With the size of the team, it may not be quite as often, but we’ll see. We’d like to be a lot more transparent and a lot more open about what we’re doing, because we’re part of the community and the community is part of the team, and we’re always leading the way, or closely following in this case, in how we can bring the community closer into the product. We’ve always taken enhancement lists – we led the way there – and here we’d like to see if we can do something more than one public beta, which is what we’ve been doing.
Ken Levy: The two most common questions are, “What are you doing with FoxPro?” and “What are you not doing with FoxPro?”. People really want to be able to make decisions and plan things out based on good information. We want to increase that dramatically on a more rapid basis.
David Stevenson: Well, on that note, I have noted in some of the discussion online that people are trying to understand what the (VFP) Roadmap really says. There is a set of words there and there’s an FAQ entry that points right back – they point to each other. The one comment I’ve seen people react to the most is that the Roadmap contains “all of our plans” for enhancing Visual FoxPro.
Ken Levy: All of our current plans.
Alan Griver: All of our current plans.
David Stevenson: Does it actually say “all of our current plans”?
Ken Levy: On the FAQ page it says all of our current plans for enhancing Visual FoxPro are located in the Roadmap. That’s subject to change at any time.
David Stevenson: The obvious follow-up question is, “What are the chances that there will be further enhancements beyond Sedna?”
Alan Griver: It’s something we’ll look at towards the end of Sedna, just like we looked at Sedna toward the end of VFP 9, we looked at 9 toward the end of VFP 8, and 7 toward the end of 6. With the team that we have we basically can look one version up. Right now, Sedna is actually probably one of the bigger bets and efforts that we’ve taken in a while. If you think about it, the last time we’ve had an architectural shift in the underlying environment was when we moved from DOS to Windows, or maybe from 16 to 32 bits.
What we’ve got now is essentially a new platform on Windows and we need to play well on that platform. We know that it’s coming over the next couple of years and Sedna is the release where we have to start taking that into account. So, all of our efforts are involved in that. Just as a simple, simple example, Longhorn (Windows Vista) has how many new APIs, Ken?
Ken Levy: Over 3,500 as it stands now.
Alan Griver: So, that means we have to look at all of those and figure out which ones do we want to make really drop-dead easy to work with in Fox, how do we want to extend it, and that’s just … work! So, right now we’re focused on Sedna and we’re not focused on anything beyond it. We can’t say anything about anything beyond it, but that’s no different than it has been every release.
David Stevenson: I think the thing that would most concern people is whether the door is actually closed to further enhancements.
Ken Levy: A big direct answer the best we can on that question is that there is a possibility that there won’t be any enhancements after Sedna, and there is a possibility that there will be. We would have answered the question the same way after we shipped 8 and people asked about what’s beyond 9. We’re being totally honest and we’re just not dancing around it in any way. There is no one at Microsoft who has had meetings or decisions, and we’re waiting for two more years to plan that out.
Alan Griver: The short answer is that the door is not closed to there being enhancements beyond Sedna. The other side of that is that we don’t know what’s behind the door yet.
Ken Levy: Our two objectives around a lot of things in Sedna are, we obviously would like Visual FoxPro developers and their users to use more .NET technologies when it’s possible, and to eventually upgrade to Longhorn (Windows Vista). That’s kind of an obvious thing. The other side of it is, as FoxPro developers and solutions do leverage .NET and have needs in that space, and as they do upgrade to Longhorn (Windows Vista), we need to make sure they succeed as much as possible and that they don’t have any roadblocks. So, it’s a mixed thing. We’re trying to encourage people to use other products and technologies to make better applications, and at the same time help them along the way and not let them be left behind.
David Stevenson: How did you arrive at the idea of this type of packaging of enhancements? This is clearly different from what we’ve seen in the normal product development in the past.
Ken Levy: To be directly honest, it was in discussion with upper management, including Eric Rudder. It was a collaboration of ideas and options where we all hashed out what were all the things that we could do, and it seems that everybody agreed that this was the best option for the long-term result. We’ve stated clearly that our goal is not to add FoxPro directly on the .NET platform, but we’re going to enhance FoxPro as an evolutionary base, and then add more Visual FoxPro-like features into Visual Studio (.NET). We have to keep both those things in mind.
Alan Griver: I have a slightly different answer. It all depends on what makes up a release. We can ship a product – and I think this is changing in multiple places – here’s an example. If you look at the Linux world or if you look at the open source world, you’ve got all these different releases going out at the same time, and you pick one from column A, two from column B, and et cetera, and it’s really confusing and hard for people to keep up with.
What we’re saying is that we have a pillar for Sedna. That pillar is interoperability. The minute you say that, it means you’re not going to be changing the grid control. You’re not going to be touching textboxes. We’re not going to be doing more to the SQL engine – we did a ton in VFP 9. We can do things one of two ways. We can say, it’s all going into the EXE, which will now grow by X hundreds of bytes or megs, and you have the possibility of introducing new instability into the code that existed.
Or, you can say, you know what, architecturally, we did a great job with 9, and what we’d rather do is create satellite DLLs that don’t affect the core stability of the product, which we know is unbelievably strong. Let’s just go ahead and see how far we can get in adding these features without touching the core. Does that mean we won’t touch it. No, that’s why we said an SP-type of thing. There may be some things where it will work architecturally a lot better with a different type of hook in there, so let’s add the hook into the core product and make it available to the entire Fox community, and we’ll use it, too.
People always talk about programming languages being written in themselves. The .NET framework was written in C# and in VB. More and more parts of Visual Studio are now written in the managed (.NET) languages. It’s the same reason that anything that we add for ourselves benefits our customers. This means that if we add new extensibility capabilities in Sedna and we prove how much can be done – you know, if we can do half the things we defined in Sedna without touching the core product, you know what, Fox is a hell of a product.
So, I think that’s really the core, and by not touching the EXE, it also makes things a lot easier and, frankly, it cuts down on some of our expenses, too. It means that our testing doesn’t have to be enhanced as much, and we can run the VFP 9 tests and assure that everything continues to work. It means training and support costs. It means that all the case studies – we’re about to have five new case studies up about VFP 9 on the web – it means that those case studies stay current. The moment you release a new version based on a new EXE, all of those case studies go into archive and you start over again. It just gives the people who have worked with us on the case studies more time for the advertising potential for those case studies. So, I think it’s actually a big win for a lot of people.
Ken Levy: I’ll follow up on two things that YAG said. On a technical front, we may be doing a lot of things as additional DLLs written in C++, the same way you’d code a component native to core VFP. For instance, we might expose a lot of APIs for Longhorn (Windows Vista) and try to treat it like natural language extensions. We could easily put those into some kind of DLL and say SET LIBRARY TO and once that one line of code was executed, you would have an extended language. And we have all these other components that do all these other things, and you’re building on the VFP 9.0 platform, so to speak. One other benefit of that is that when Sedna comes out, there may be a whole lot of things across the board in Sedna, and there may be some people who only need 30 to 70% of that capability, and they get to pick and choose which components they use mostly without even touching the existing application because it’s already on the same base. The upgrade process and the flexibility in testing should be even better for them. It makes the management of the solutions and the deployment a lot better.
Alan Griver: The other thing is that this isn’t anything that we haven’t done before. I go back really far, right?
David Stevenson: Really far!
Alan Griver: Really, really, way too far. For those of you who don’t know me, my first version of Fox was FoxBase 1.21. One thing that a lot of people may not remember is that when you first wanted to access SQL Server from Fox, you got the connectivity kit, where you essentially did a SET LIBRARY TO and suddenly you had access to SQL Server. It didn’t actually make it into the product for two or three releases, so at first, that’s what you used. You had COMUTIL (VFPCOM.DLL), and in order to get access to a lot of the COM events, you actually used a library – a separate file. We’re going to continue in that proud tradition.
Ken Levy: And when we need to update these components with evolving technologies, we can update just these little components and not the entire product. Rather than like, service pack 1, 2, 3 and 4, just with core features that relate to external technologies, now we can have components that you just plug into, whether they’re FFC components, DLLs, .NET wrappers, and so forth.
David Stevenson: There has been some talk about how you’ll have the betas progressively over the next couple of years and let people see what’s being worked on, but the final release of Sedna, however it’s packaged, will probably be something that people will pay for.
Ken Levy: The way we generally work on packaging, is that I’d say around six to eight months out from the release we start working on the packaging, the distribution, pricing and a name. It all comes together at about the same time. In the case of Sedna, it will be about the end of 2006. The other thing is, that we need about another year and a half just to figure out what Sedna is. We will be deciding things early, but it will continue to evolve, and it could be April of next year that we have an epiphany and come up with something we hadn’t even thought of.
Alan Griver: One other thing about the pricing and the beta – it’s not different. I think in some cases, people are freaking out because we have a Roadmap where we’re saying these things. VFP 8 had a public beta that was free to everyone, but once the product shipped, if you wanted to keep using 8, you paid for it. VFP 9, public beta, free to everyone. Once it shipped, you paid for it. All we’re saying here is Sedna, public beta. What’s going to happen when it ships. We’ll find out, but you know what, yes, there will probably be a way for us to gain revenue from it.
David Stevenson: There has been a public statement, I believe by Ken, in response to someone’s question, that decisions about VFP’s future are not tied to the sales of VFP. What are those decisions about VFP’s future based on?
Ken Levy: To be clear about that, if for some reason the graph of the sales changes in some way, it’s not like we’re going to stop and say, I guess we’re not going to do Sedna. We don’t want people to feel insecure about our plans and commitments around the Visual FoxPro Roadmap as they relate to VFP 9. There may be some people who wait a few months to upgrade – maybe building on VFP 8 or VFP 6, or whatever, and we’re very committed to help FoxPro developers and the users of those applications move forward on new Microsoft products and technologies. So, this is a very strategic release of additional FoxPro functionality.
Alan Griver: We’re always looking at revenue, right? But once we’ve got the budget for a new version, revenue becomes less of an issue. Before we had the budget for Sedna, before we had the commitment for Sedna, part of the issue was, indeed, are we making money off of this thing. Could we better utilize some resources elsewhere? You know, that same discussion happens about every product every time. Can we get enough people to upgrade to be worth the massive effort to do the next version of X?
David Stevenson: That brings up the question of the VFP team. I think a lot of people are very interested to know what is happening inside the VFP team. We know that some of them are working on things for other projects with part of their time. How does the team look and how will it look over the next several years in terms of size, and what percentage of their time is going to be devoted to Fox?
Alan Griver: I made a blog entry a few months ago – not in much detail – that basically talked about Visual Studio Data, which is the team that reports to me. It’s a team that is made up of multiple groups, if you will. Fox is one of them, and the Data Tools in Visual Studio is another. I don’t believe that there should be a wall between the two teams. To that end, some of the Fox people are bringing some of the great capabilities of Fox to .NET. But at the same time, there are people from the Visual Data Tools team who are working now on Fox. It’s not a question of resources going only one way from Fox to Visual Studio.
I’ve taken a program
manager named Milind Lele, and hopefully, when we get back, we’re going to
start introducing some of these people to places like the Universal Thread.
Milind is now working with
For me, that’s really
important that there not be any kind of boundary between the two. To that end,
also, if you look at my management group, some of my managers, such as my test
manager, a guy named
Ken Levy: People need to remember that we’re still part of one team, and that’s the Microsoft team.
David Stevenson: That sounds like a typical marketing answer.
Ken Levy: An example is that our team helped drive and sponsor the XML tools that went into Visual Studio 2005. That was a small part-time effort during the development of Visual FoxPro 9. But there’s a lot of other work with the documentation and all these other factors that is across multiple teams. So, yes, there is a core team that works most of the time on Visual FoxPro, but there is a bigger aspect to the whole development and shipping of FoxPro and other things that relate to it. That’s why I say it’s one big Microsoft team – it’s not completely isolated groups.
David Stevenson: You mentioned SP1 for VFP 9, due somewhere around the end of this year. What should we expect to see addressed in that service pack?
Alan Griver: That’s going to be a more common type of service pack that you’ve seen which will just address any critical bugs that we’ve seen.
Ken Levy: It will be more like SP1 for Foxpro 8 – there will just be one for version 9.
Alan Griver: The reason for waiting we think until the end of the year is because we just haven’t had enough critical bugs reported to us yet to make the rollup worthwhile. It’s kind of an interesting balancing act. A service pack requires a lot of testing, right? We have to test it on multiple operating systems, installed with multiple other applications. We have to make sure SP1 won’t break Excel or Visual Basic or whatever. There is a big matrix of testing that goes into it. If you ship it too early and then you start getting feedback on other critical bugs, you then have to do a second service pack and that will blow out my test resources, which will affect Sedna. So, we like to make sure that we’re on a downward slope and that we’ve got a good batch of critical issues to address. The number we’ve gotten compared to 8 is so much lower that we’re waiting to make sure we hit it right.
David Stevenson: There has been some talk of your wanting some input from the community on what they would like to see included in Sedna. Someone made a comment in the keynote to “give us some scenarios and we’ll go after the technical side of it.” What do you really need from people and what’s the best way for them to express that to you?
Ken Levy: Right now, what we’re putting online for the community is a lot more in-depth thoughts and ideas and parameters around what we plan to do with enhancing Visual FoxPro than we have done with any previous versions. So, on a regular basis we’re disclosing what are our boundaries, what are our overall objectives, almost like buckets or areas that we’re going to prioritize on. Over the next few months, we’ll drill into each one of those to determine more specific features – what’s the impact, what’s the scenario that drives it. We have to justify each thing we do and how it compares to something else in impact.
We want to have the community follow along with us with almost monthly releases of information about what we’ve planned – new ideas – and then give us feedback on each. It doesn’t mean that there will be random ideas that have no context to our goals and objectives – we want the community to follow along and see, OK, this is what we’re trying to do, and interact. Just like the whole grid thing, if someone wanted a new column type feature for the grid, we probably would say that’s not on our priority list – can you give us some features and scenarios around the goals that we’ve outlined?
We want a lot more interaction with the things that we release on a regular basis, just like in the Sedna section of the VFP Forum on the Universal Thread.
David Stevenson: How should people do that? Should they send an email to you or to Randy, or post something on the Universal Thread or the wiki?
Ken Levy: Direct email is hard because there is no way for it to be easily discussed with multiple people. Right now, for a little while, go into that Sedna section on the Universal Thread, but we are researching other avenues online to have input, discussion and feedback. We’re going to evaluate a feedback center later this year.
Alan Griver: To make it really clear to people – we have published the pillars for Sedna. They are .NET interoperability, Longhorn (Windows Vista) interoperability, SQL Server 2005 interoperability, and Office 12 interoperability. So, the best thing that people can do is give us some scenarios. How do you plan on using it? You might say, I have a major VFP app I’ve been working on for years, my company just merged with another one that has a .NET app, and we need to get the two to communicate. Here are the issues that we’re finding based on VFP 9 – it would be so much easier if there was a way to automatically do this. Or, I hear that Office 12 is storing all this data in XML format – wouldn’t it be wonderful if we now had a new export type called Word 12 or Excel 12? It’s things of that nature – kind of the high-level scenarios for things that will really help people if we make it available.
Ken Levy: One of the really important pillars to add to all of that is the area of extensibility in FoxPro – what we call internally the “Xbase components” that are written in FoxPro. In the keynote, two of the exciting demos were of a new extensible “My-dot” architecture based on Visual Basic 2005, which is like speed-dialing into common or uncommon functions to discover things. The other one is the report functionality that was demoed, that basically extends the VFP 9 report system, where you hook in and declare things easily with no code, and then report listeners get turned on and executed automatically. All of that is written in Visual FoxPro, and we believe that there are many, many aspects of enhancing core VFP that relate to no other external things, that we can package up in Sedna. So, it’s kind of like the best of both worlds: interoperability and great new features in FoxPro.
Alan Griver: But I do want people to be clear. When we say scenarios, we want to understand what they’re trying to accomplish. We may accomplish it using Xbase, or a DLL, or cracking open the bits and making careful changes to the executable. We’ll figure that out, but if we have a lot of good scenarios and we do our job right architecturally, we may find that half of the scenarios get solved by doing on architectural change in Fox – that’s really what our job is.
David Stevenson: YAG, you mentioned earlier that it’s important to get this feedback early in the design process while there is still time to potentially affect the other technologies, and you mentioned that there are things in Visual Studio 2005 that were changed due to some problem relating to Fox. Can you be more specific about that?
Alan Griver: One of the nice aspects of owning VS Data and being responsible for the data story for both Fox and VS, is that we could do certain things like making the Server Explorer and much – I can’t say all – of the data access itself in Visual Studio 2005 data-driven. The data happens to be XML files, but it means that, for instance, if you add a SQL Server 2005 database to Server Explorer, you create a connection to it, you now see more things than just Procs and Tables and Diagrams, which is what you had before. You now get things like User-Defined Types, Assemblies, and et cetera. We added that feature through the extensibilities that we created.
That means, for example, that we can partner with IBM or Oracle, and when you click in Server Explorer, you see not just Procs and Tables, but with Oracle you see packages. We allow IBM or Oracle to define for themselves what kind of views they want to make available to developers, that are appropriate to their backend.
We can also take that same mechanism when Visual Studio 2005 ships and provide that type of capability for FoxPro DBCs, and also we use a lot of the information in there to enable things like drag and drop form creation, and so forth. Anyone who has tried to create an Adapter against a VFP DBC in Visual Studio 2002 or 2003 knows that it requires a lot of hand-coding because a lot of the wizards wouldn’t work. We have started to take care of a lot of that – I can’t say we’re 100% there, because we do have to ship Visual Studio 2005 as well – but we’re committed to using that type of extensibility across the entire data area in 2005 and in the one after that, Orcas.
You will see that Fox DBCs just interoperate better in Visual Studio 2005 because of things like this. As I said before, when I took over the team, we didn’t want it to be just OK, now we’re going to support Fox in Visual Studio. No, we said what can we architecturally do that will allow us to solve this problem of supporting N databases, and that’s what we did. Part of the Fox background that so many of us have, is that we think more at that level in terms of data-driven capabilities.
David Stevenson: Should we expect to see more data-driven capabilities in future versions of Visual Studio?
Alan Griver: I would expect to see a lot of things that you’re used to from Fox make it into Visual Studio over time. Another example, for instance, is when I talk about drag and drop form creation. There is a data source window where you specify what portion of the database you’re going against to work with in your WinForm application. For each of those things, you can specify what control should be used when you drag and drop onto a form, including custom controls, very much like Fox. You drag and drop and it all just works, and you can use the exact same data source to create your reports, very much like Fox. So a lot of those ideas are available – Fox is sitting on the computers of a lot of the Program Managers who are responsible for data.
David Stevenson: The Sedna blog that was shown in the keynote – will that be a primary communications vehicle for the team?
Ken Levy: No, that was just a fun prototype demo. It’s more like a demo test blog, and what we’ll focus on are the team member blogs that exist today and the monthly online letter as the vehicle for getting more formal things out. We probably won’t use a blog called the Sedna blog, but will leave it like it is today – the team member blogs and the FoxPro home page.
David Stevenson: You made one comment earlier that I want to follow up on. You said, obviously we would like to see people start using Visual Studio .NET more. Why?
Alan Griver: Because it is the core of all the future platform work at Microsoft. It’s the same reason that where companies had a large investment in DOS, we said we’d really like to see people using Windows more. .NET is the underlying platform for everything we’re doing over the next 10+ years.
David Stevenson: So, customers who have an existing resource and investment in years and years of well-debugged code, that they’re dependent on for mission critical applications – you’re saying to them, eventually you’re going to need to re-write that.
Alan Griver: No, we’re saying it will continue to work, just like in Windows today you can still run VisiCalc from the CPM days, all the way to DOS apps, all the way to Windows 16-bit apps – they all run on Windows today and they’ll run on Longhorn (Windows Vista). We’re saying we’ve got a set of well-debugged code that we are continuing to enhance with .NET – we’re doing the same thing we’re recommending to people. We have this great code base, and now let’s enhance it using .NET – that’s what Sedna is.
Ken Levy: Especially with Sedna, we plan to add a lot of functionality and capabilities, in some places leveraging the .NET framework, which will require some time spent in the Visual Studio development environment, to build an application with functionality well beyond what FoxPro can do alone today. So we believe there will be a lot more capabilities for Fox developers to use these tools – like a little more than half the Fox developers use SQL Server with FoxPro. We project that over half of the Fox developers will use .NET programming along with Fox programming, as complementary tools in the overall package.
Alan Griver: This is nothing that we haven’t been through before. I remember going from Fox DOS to Windows, and I remember the screams when VFP first shipped. A lot of developers have been using VFP for the past 10 years – they may not remember that there was a huge group of people who said I’m not moving to Visual FoxPro because Fox DOS and Fox Windows 2.6 does everything I need. Eventually, people saw the capabilities, and I think the same will happen here.
Ken Levy: To summarize, the Visual FoxPro team is just as enthused, if not more, about the potential for Sedna as when we started on Europa (Visual FoxPro 9).