Levy and Griver - Why not complete transparency?

Well, I don't care about having those sources. In my daily work it is not that important. What would be nice though is complete transparancy in how they will market their secret weapon (VFP) in the foreseeable future. OK, OK, I know, doing absolutely nothing is quite clear as well but that is not what I talk about.
Something like "such and so is our plan , we will have management magazines writing about VFP in this and that manner ..." You will find more and intenser campaigns in country ABC etc etc...

This is great.   I feel like I am able to talk to "The Microsoft." 

I'd scrap the argument that goes "people probably won't do anything with [insert whatever here]". I don't think it's fear of competition either. It's a revenue thing. Supposing MS released the source for Windows or VS.NET and the "community" actually contributed lots of bug fixes and new features -- how could MS then turn around and sell the OS or IDE to anyone?

I think it's both - yes, revenue is a component of this (as far as sources go), but I really do think that we can get to pretty complete transparency without making source openly available. For instance, bringing customers in on things like specs, bug tracking, enhancement requests, etc. is a great start. Having wider community tech previews should help as well.

FWIW, I'm also interested in seeing how this goes - I've subscribed to the threads about the videos that I've done - so I'll be keeping up (love that RSS)

   As a c# developer coming from the java world.  I have taught myself to be better at reading the code then documentation.  The only way to be really sure what is going on is to go to the signature and read the code.  

   From that stand point having the source for a lot of the .Net framework libraries, would really improve my understanding of what really is going on with the program.  Especially in the case of obscure bugs where you're just not sure if the framework classes are holding up their end of the bargain. 

  With the incomplete and often buggy nature of the framework libraries, this is not as trivial as it might appear at first glance. 

Competetive advantage is not created and sustained by semicolons and angle brackets, but rather through innovation and the ability to execute and maintain a strong vision.

I'm sick of hearing this argument... it's so 90's.

I think you've maybe missed the Pink Elephant in the room. the transparency that would help most developers is the API, even the beaurocrats in the EU seem to grasp this singular point, sure some MBA will say that having hidden APIs for your own apps is a competitive advantage, the rest of the IT world looks at it and bells sound and people start exploring other software solutions, sure maybe you maximise some short term gains, but do you want to risk the medium and long term future of the corp?

Ken Levy and YAG are the right people to comment on transparency.  Ken has created some truly awesome tools as part of VFP, and the code is all available.  As for YAG:   Codebook, 'nuf said. 

VFP has a great community and the VFP development team is truly responsive to the requests of the community.  That is the kind of transparancy that matters to me.  Who are the people responsible for the tools that my livelihood depends on, and do they care about my needs? 

VFP 8 rocks!  It is full of developer driven features plus great innovations from Ken and his team.  I haven't even begun to reach the limits of this tool ( if there are any).

It's a shame I fell I need to spend my evenings studying C# in order to insure my future marketability.

From my own personal perspective, I couldn't care less about the source code for tools such as VS.NET - however, I do feel that the full source code for the various System namespaces in .NET should be made available as with the JDK.

Moreover, they should be released under a completely non-restrictive license (possibly BSD style) so that projects like Mono and dotGNU could make full use of them.

Should revenue even be an issue? Can't an evolved revenue stream be envisioned in a completely transparent model?

Really its all about Developer Relations and developers love code. Especially those migrating from JAVA/UNIX.

Besides, its REALLY annoying and counter-productive to have to 'guess' how an algorithm operates through trial-and-error, reverse compilation or other devious means. And I find we do this on a daily basis: which sort is being used, how is HSL color computed, what method of serialization is employed, etc.

Please, spare us.

aq
 

Doing commercial software these days is like doind battles in old times: small advantages leads to the victory. Keeping core technology code undisclosed is undoubtedly one important advantage that Microsoft must keep.
As a developer, I was almost always wandering how that feature is done, why that option didn't work how I expect to, why they don't publish examples of using the last design interface features and so on. The truth is that we couldn't have them all for free.

Since .Net comed up, Microsoft changed his policy regarding community support. Non Microsoft comunity and open source projects proved that community is the key. Thanks to few open minded people inside, they will recover the lost market shortly.
In web development, I have started as a PHP developer. At this time, as you know, PHP community is still larger than ASP.NET community. Some time ago, when Zend boys started to design Zend 2.0 engine, I have asked them why they don't include modern features like namespaces and coherent OOP implementation. In return their response sounded like: the purpose of PHP as scripting language is not to do that. That makes me to embrace .NET definitely. And I was never wrong till now.

So helping developers through community support is enough for me these days. Who whants more must rise the stake: go inside Micrososft and work at the source of all sources. 

Thanks,
Lucian

Our first .NET component back in Dec'2000 shipped with full source code, as have all our components since.  I'd like to think that that set the agenda for the remainder of the component market, certainly many .NET components ship with source these days and that wasn't the case in the COM market.

Why a developer might want source to components;

Source is the ultimate documentation for software behaviour.

Being able to step into the Source of components during debugging is just another debugging opportunity to track elusive behaviors.

Source provides control over the component, so if say an asteroid hits vegas and vapourizes us our customers will still be able to extend their controls and maintain them themselves as necessary.

I suspect the most important reason is that developers reputations are on the line with their customers.  As a developer with the source to all components you use, you can not only verify the quality of the code, you can confidently assert that it contains no nasty surprises. 

From our point of view making all our source available is a risk, we are showing our competitors how we did some things that are unique to our components.  But if they implement them they will have to find a different way to do that.  All you need is time to replicate a feature from a black box component - source actually makes it harder for our competitors to steal our ideas.

Someone taught me long ago to always think about revenues when talking about Microsoft.
It was a quite right perspective.
Steve Ballmer point of view is pretty much like "why should we waste billions spent in R&D to give them to competition for free?".
We cannot expect Microsoft to fully release the sources to anyone like open sources, because it would cripple their source of revenue.
Let's take a look at the linux like philosophy:
Software is not the source of income, but it has to be bundled with additional services like support in order to generate income.
In fewer words, software developed by the community and services sold by the companies. That's it.
Would anyone spend large R&D budgets in this environment? I don't think so.
The best we can expect to Microsoft is to extend the shared source initiative and to release older/non critical sources in some occasions, keeping hidden the critical stuff.
Is it so bad?
I come from the Java community, where they thaught us at university one principle: Information Hiding, or "don't look at the code, look at the documentation".
Is it so bad to follow this principle?

This is my first post - be gentle.

I'd just like to say that while it's more or less true that "Source code IS the ultimate documentation," there are some downsides to this approach.  For starters, I don't have time to go through every piece of source when looking how to use a library.  As part of a "Code Factory" organisation, what I need is complete and reliable documentation on what to use in which situations, and how to use some of the more obtuse options in otherwise well documented libraries to solve real world problems.

Knowing how to make complete use of all of the functionality available in a given tool is more important to me than knowing how the tools were written.  Microsoft pays a large number of people who know what they're doing to handle bug-fixes and tuning.  I'm pretty certain that (as a casual client-side coder) any attempt I made to fix or tune the CLR would create more problems than it solved.  And ultimately, in a large corporate applications factory, you're only as good as the last crisis you caused.

Of course, this is only my $0.02.  YMMV.

Cheers


Ged

It is a shame that we don't live in a perfect world, eh.

It is a shame that we don't live in a perfect world, eh?
In real world (as ram very well stated) sources are very valuable for us, programers.