Looks like there isn't going to be an easy answer dealing with the Visual Studio 2005 SDK distribution EULA. I guess we'll see what happens when VS2005 is RTM, but honestly, I just saw one screenshot of the Resharper IDE from JetBeans...
JetBean's IntelliJ allows for open source plugins, so I can say with strong hope that the Resharper IDE will, also.
That's probably where I'll set my sights for a real IDE-integrated Boo addin. Its true that I could use Java and do one for Eclipse or X-Develop, but to be honest I want real .NET integration. Automatic adding of web references. Automatic winforms designer. ClickOnce deployment.
All that stuff is only going to be possible with a "real" .NET IDE, rather than me having to recreate all that from scratch because the host platform didn't support it.
The guys at JetBrains seem really smart, so the API might be just what I'm looking for... managed and loving it. ;)
Monday, July 25, 2005
Saturday, July 09, 2005
And so, he scratched his beard and said...
...this is going to be different.
I will admit that I am suprised that *two* people responded this time about the issue of the distribution EULA suddenly popping up barring our (someone else; they're freakishly secretive about their project at the moment) way.
I know its a totally glib attitude to take, but I ain't gettin' paid in money, so I was hoping to get paid in fun and source code. ;)
Well, we'll see how this all plays out.
I will admit that I am suprised that *two* people responded this time about the issue of the distribution EULA suddenly popping up barring our (someone else; they're freakishly secretive about their project at the moment) way.
I know its a totally glib attitude to take, but I ain't gettin' paid in money, so I was hoping to get paid in fun and source code. ;)
Well, we'll see how this all plays out.
Monday, July 04, 2005
I think I thunk a thought.
I'm starting to wonder if I should abandon the Visual Studio 2005 package: I'm not sure I will get a response without lots of hoping and hollaring and blog-linking. Its not that there's been no reply yet; that's understandable, as its the 4th of July week, and people are busy. Hell, I'm not even in state anymore, and I won't be for another few days.
What worries me is the simple lack of communication between the VS2005 SDK team and the rest of reality. The Visual Studio Extensibility Forum, for instance, is a very good indication of their lack of participation: the documentation is pretty poor, so the forum is the first place people go to ask questions, which are completely ignored by the VS2005 SDK team. They're not easy 'oh, don't be a newb' questions, either; they're the kind of tough stuff you either slough through the heaviest of documentation to scrabble for tiny tidbits of information for, or you need an SDK developer to give you a quick leg-up.
The Microsoft MVPs are doing their best, though, but they can't do it all themselves, and the many forum posts that have no reply is testament to that. Hell, most of my forum threads have replies only because I replied to myself for the sheer benefit of other people. You know, keeping them up to date on the information I've found about the particular subject.
However, the issue about the old EULA being applied to the new Visual Studio SDKs is something that cannot be ignored simply because I can't work around it. This issue has to have definite action taken to it or I simply cannot work on the project any longer. Naturally I don't want to work on the project until the issue is cleared up, as it might be much wasted time and energy if I'm met with silence all the way up until the release of the SDK in conjunction with VS2005 gold releases, at which point I realize they're going to stick with the old EULA and I've got a large but relatively worthless code-base.
Its not even entirely the issue of open source here, either: the license is fucking crazy. It looks like a strange composite of marketing - MARKETING - and a bunch of random demands that go with it.
But back on topic:
I am honestly sort of suprised: creating an SDK is not instant magic, and you would think that someone working at Microsoft would know that best. Sooner or later you're going to have to interact with people when the documentation isn't cutting it or other issues pop up. The lack of visible interaction from the group is astounding. Your product has its own forum that nobody from the product team posts in. Crazy.
I mean, at least the guys at SharpDevelop fake it: they'll post a completely worthless URL ('check out this three year out of date ebook on Addin architecture!') or babble something incoherent ('SharpDevelop's codebase is self-documentating!') but at least they pretend.
C'mon. Fake it. Fake it for me, baby.
What worries me is the simple lack of communication between the VS2005 SDK team and the rest of reality. The Visual Studio Extensibility Forum, for instance, is a very good indication of their lack of participation: the documentation is pretty poor, so the forum is the first place people go to ask questions, which are completely ignored by the VS2005 SDK team. They're not easy 'oh, don't be a newb' questions, either; they're the kind of tough stuff you either slough through the heaviest of documentation to scrabble for tiny tidbits of information for, or you need an SDK developer to give you a quick leg-up.
The Microsoft MVPs are doing their best, though, but they can't do it all themselves, and the many forum posts that have no reply is testament to that. Hell, most of my forum threads have replies only because I replied to myself for the sheer benefit of other people. You know, keeping them up to date on the information I've found about the particular subject.
However, the issue about the old EULA being applied to the new Visual Studio SDKs is something that cannot be ignored simply because I can't work around it. This issue has to have definite action taken to it or I simply cannot work on the project any longer. Naturally I don't want to work on the project until the issue is cleared up, as it might be much wasted time and energy if I'm met with silence all the way up until the release of the SDK in conjunction with VS2005 gold releases, at which point I realize they're going to stick with the old EULA and I've got a large but relatively worthless code-base.
Its not even entirely the issue of open source here, either: the license is fucking crazy. It looks like a strange composite of marketing - MARKETING - and a bunch of random demands that go with it.
- You shall ensure the quality of reproduced Licensed Software is equivalent to the quality of the Licensed Software as provided by Us. We shall be entitled to periodically, upon reasonable notice, inspect the quality of Your reproduction. Should we be dissatisfied with the quality, We shall notify You in writing and You shall promptly correct such deficiencies;
But back on topic:
I am honestly sort of suprised: creating an SDK is not instant magic, and you would think that someone working at Microsoft would know that best. Sooner or later you're going to have to interact with people when the documentation isn't cutting it or other issues pop up. The lack of visible interaction from the group is astounding. Your product has its own forum that nobody from the product team posts in. Crazy.
I mean, at least the guys at SharpDevelop fake it: they'll post a completely worthless URL ('check out this three year out of date ebook on Addin architecture!') or babble something incoherent ('SharpDevelop's codebase is self-documentating!') but at least they pretend.
C'mon. Fake it. Fake it for me, baby.
Sunday, July 03, 2005
Exploiting SharpDevelop.
"If it goes badly, I'll have to drop back down to SharpDevelop; basically, mutilating BooBinding and exploiting the text editor to do refactoring stuff (things it was NEVER meant to do)."
Let me expand on why I view this as a Very Bad Thing:
Documentation:
SharpDevelop's Addin interface is not poorly documented: it is completely undocumented. No, sorry, your three year old completely out of date book does not count. It is ironic that they have the time to churn out Addin after Addin after Addin, but can't take the time to documentation the interfaces: something that opens up SharpDevelop to a much wider audience of plugin makers rather than the few that already know how to do it.
There have been many posts on the forum about 'how to get started' with Addins. They're all pointed to the ridiculiously out of date eBook or told to browse the source code. Source code is not documentation.
This is a hobby, not some bizarre obsession: I've got stuff to do, and browsing through your source code because you're lazy is not one of them. I'm sorry if that was harsh, but its the truth. SharpDevelop isn't popular or good enough to attract hard-core developers like those. It is the best free .NET IDE available at the moment, but its not that good. It is not a rock-star application; people are not willing to struggle through bad/poor documentation to make magic happen.
SharpDevelop 2.0: Codename 'Corsavy.'
Here is a serious, serious problem the Sharpdevelop team has made for themselves: these are all the features SharpDevelop 2.0 are supposed to support:
So, why would I want to do a refactoring plug-in for an already obsoleted SharpDevelop 1.1? The minute 2.0 comes out it will support these features out of the box, and propbably in a nice integrated manner. You can rest assured that almost everyone will upgrade, because SharpDevelop is trailing edge and about to fall from that fine line. I'm not willing to invest effort in something that will be completely depreciated a few months later.
Concrete information about SharpDevelop 2.0 needs to hit the newstands before its something I'll even begin to consider seriously again.
Let me expand on why I view this as a Very Bad Thing:
Documentation:
SharpDevelop's Addin interface is not poorly documented: it is completely undocumented. No, sorry, your three year old completely out of date book does not count. It is ironic that they have the time to churn out Addin after Addin after Addin, but can't take the time to documentation the interfaces: something that opens up SharpDevelop to a much wider audience of plugin makers rather than the few that already know how to do it.
There have been many posts on the forum about 'how to get started' with Addins. They're all pointed to the ridiculiously out of date eBook or told to browse the source code. Source code is not documentation.
This is a hobby, not some bizarre obsession: I've got stuff to do, and browsing through your source code because you're lazy is not one of them. I'm sorry if that was harsh, but its the truth. SharpDevelop isn't popular or good enough to attract hard-core developers like those. It is the best free .NET IDE available at the moment, but its not that good. It is not a rock-star application; people are not willing to struggle through bad/poor documentation to make magic happen.
SharpDevelop 2.0: Codename 'Corsavy.'
Here is a serious, serious problem the Sharpdevelop team has made for themselves: these are all the features SharpDevelop 2.0 are supposed to support:
- Refactoring support.
- 'Go to Definition' and 'Find all References' support.
- Built-in debugging support.
- Slick user interface.
- Better Addin API.
So, why would I want to do a refactoring plug-in for an already obsoleted SharpDevelop 1.1? The minute 2.0 comes out it will support these features out of the box, and propbably in a nice integrated manner. You can rest assured that almost everyone will upgrade, because SharpDevelop is trailing edge and about to fall from that fine line. I'm not willing to invest effort in something that will be completely depreciated a few months later.
Concrete information about SharpDevelop 2.0 needs to hit the newstands before its something I'll even begin to consider seriously again.
Saturday, July 02, 2005
Keeping a careful eye on Microsoft.
Keeping a careful eye on Microsoft.
Announced on the Extensibility forums, a new "tech preview" for the VS2005 SDK has been released. However, this release heralds a new problem: it links to the old, old, very old version of the EULA that explicitly forbids open source along with a myriad of other stupid restrictions - I mean that in the most literal sense. They are pretty odd-ball restrictions, and I'm not sure who was smoking what when they were written. I can't "agree" with the this new-old EULA, so I can't produce any valuable feedback on the tech preview. I don't want to invalidate the Novell Forge project for this.
So now I've got a problem: if this situation isn't rectified and remains in place for the duration of the SDK's lifetime, then that immediately aborts this Boo package (VS2005 SDK's call plugins 'packages'), because I'm not interested in maintaining this chunk of software by myself till the end of time. God forbid something happen to me and then someone has to start over from scratch for no particular reason.
I'm just one guy: I'm not a friggin' army of coders. I need to leverage the ad-hoc nature of open source to deal with the 'long run' issues: maintence, etc.
We'll see how Microsoft handles this.
If it goes badly, I'll have to drop back down to SharpDevelop; basically, mutilating BooBinding and exploiting the text editor to do refactoring stuff (things it was NEVER meant to do).
Announced on the Extensibility forums, a new "tech preview" for the VS2005 SDK has been released. However, this release heralds a new problem: it links to the old, old, very old version of the EULA that explicitly forbids open source along with a myriad of other stupid restrictions - I mean that in the most literal sense. They are pretty odd-ball restrictions, and I'm not sure who was smoking what when they were written. I can't "agree" with the this new-old EULA, so I can't produce any valuable feedback on the tech preview. I don't want to invalidate the Novell Forge project for this.
So now I've got a problem: if this situation isn't rectified and remains in place for the duration of the SDK's lifetime, then that immediately aborts this Boo package (VS2005 SDK's call plugins 'packages'), because I'm not interested in maintaining this chunk of software by myself till the end of time. God forbid something happen to me and then someone has to start over from scratch for no particular reason.
I'm just one guy: I'm not a friggin' army of coders. I need to leverage the ad-hoc nature of open source to deal with the 'long run' issues: maintence, etc.
We'll see how Microsoft handles this.
If it goes badly, I'll have to drop back down to SharpDevelop; basically, mutilating BooBinding and exploiting the text editor to do refactoring stuff (things it was NEVER meant to do).
Subscribe to:
Posts (Atom)