Is the only obstactle those 3rd party libraries? If so, you could just release the code you have, and just say "here's what it is, it uses those other libraries and they're not open source, so here are precompiled binaries... under a different license, of course." If the app is nice, other people might pony up proprietary library clones.

(Keep in mind there are two factions at play here. Free Software, and Open Source. The FS zealots, like Stallman, will hate anything an everything closed source. The OS zealots are probably quite a bit more cool with it.)

(any chance you could release the list of shame? (of the groups that reacted nastily))

To do my best to not answer your actual question and ramble on about implied matters (like half of everyone in this thread, heh), as I frequently do:

While I can't speak for anyone else or a whole community, I can tell you what reasons would lead me to being uncomfortable relying upon any product.

Whether it's mostly psychological or not, there's always the fear of lock-in (or any more general restriction of their presumed freedom). In something that's open sourced, it's pretty hard to feel locked in. Unless the distributor of a product is very thorough, lock-in can cause a limitation in the number of available platforms and a risk of future obsolescence or discontinuation of its free availability, ignoring the less relevant issues for the matter at hand such as buggy-ness, security issues, privacy issues, and potential lack of customizability (off topic: is that even a real word?). It's a matter of trust when one cannot take something into their own hands. Even though you know you're trying to perform a favor, the comparative loss of freedom in the worst circumstances is what's getting to certain people.

With a product such as yours, I can see someone's reasons to worry about lock-in being difficult to "escape" due to it breaking away from existing "standards" to an extent. I largely refer to the lack of reliance on the autotools with that. Not to say that the autotools are perfect (even though I use them and have long since ran out of major faults I cannot work around, I hardly think they're perfect), but some are (presumably and apparently) lent some amount of comfort in that. Building on Jam or Ant would probably sooth at least half of the people using autotools would, but that might be no solution at all depending upon why your build system is an improvement. The way I'd solve it, speaking in general terms, is to make the build system available separately (as simply a fork or, preferably, as a different project) "for ever" (likely meaning open source), so that if someone really had to they wouldn't even have to switch build systems to continue on with a project without the IDE.

Personally, I feel an IDE is an IDE; it shouldn't really be possible for true lock-in by an IDE, since the code is still just the code (it better be! :P). But, some people are hypersensitive to certain matters such as any feeling of lock-in and could be (and apparently are) upset by the pseudo-potential that exists. To expound on that, many Linux users are probably the kind of people to be hypersensitive to such matters because of the type of person they have to be or have become before ever trying Linux; on the other hand, many of the "normal" consumers could be desensitized to such matters. Who's correct hardly matters, it's all about appeasing your audience in the end. Who you choose to make your audience is your own choice and I suppose the one you're trying to get help in making in this very thread :).

(Disclaimer: I don't think I wrote that half as well as I could have, but I don't feel like fixing it. Hopefully my point gets across inoffensively and without any tone of "scolding" or anything similarly out of place regardless.)

My only suggestion, when you have time, is to code in a plugin architecture. That'll shut up some of the people that won't work with it because they can't add things.

Hopefully :D.

I dumped Linux because of the IDEs. They aren't just up to snuff with MSVC. I like writing code, not fighting with an IDE to get things to work :)

I use Linux more than Windows and I'm not a GPL freak.

With my coding I'm actually the other way around: my app will be closed-source, but I plan on releasing the underlying libraries I'm using free (not GPL, but open source; maybe LGPL or BSD).

I would love to test your IDE, except that I use C#/mono.

I think the reason most Linux sites are GPL-or-bust is that they are run by the true Linux enthusiasts/zealots. Casual users don't spend the time to get a website running.

[edit] I just read that it supports other compilers. I'll give it a go then; MonoDevelop isn't that nice yet. (It's usable but not great.)

I think it's best to just ignore the people that demand everything be GPLed. Open source is nice, but it isn't a requirement.

[Edited by - nagromo on January 5, 2005 12:05:58 AM]

Quote:Original post by Null and Void
Whether it's mostly psychological or not, there's always the fear of lock-in (or any more general restriction of their presumed freedom). In something that's open sourced, it's pretty hard to feel locked in. Unless the distributor of a product is very thorough, lock-in can cause a limitation in the number of available platforms and a risk of future obsolescence or discontinuation of its free availability, ignoring the less relevant issues for the matter at hand such as buggy-ness, security issues, privacy issues, and potential lack of customizability (off topic: is that even a real word?). It's a matter of trust when one cannot take something into their own hands. Even though you know you're trying to perform a favor, the comparative loss of freedom in the worst circumstances is what's getting to certain people.

This being the crux of your argument, I shall posit the following counterargument: the fear of lock-in as an argument for open source, for the individual, is hypothetical. Corollary to that, I shall further posit that for a class of software that can be considered "infrastructure," provided there is a rough equivalent that does not present a reasonable possibility of lock-in, then the point is moot.

To be more concrete, there are other IDEs in existence, fully open source. Should Yann L's IDE never become fully open source, and should it fall into neglect, the user can transition to other IDEs with minimal inconvenience. In fact, possessing the source of a utility that has fallen into neglect is not valuable to most users, because their interest lies in use of the utility, rather than maintenance/enhancement. Significant effort is required to maintain a utility, and while the general hope is that a sufficiently large community of user-developers forms around it to maintain it in the even of owner neglect, the reality is that it's a rather small proportion of open source utilities - most of them low-level infrastructure effectively required by all - that reach that state.

If I am a user of software package X, which is maintained by an anonymous (to me) collection of developers, X-dev, who one day up and disappear (perhaps because X-owner wasn't charismatic and/or skillful enough in maintaining X-dev interest, and X wasn't mature enough to be self-sustaining), then access to the source of X is of zero immediate benefit to me. If I use X in the process of completing some task Y, X being in a state of neglect forces me to seek an alternative to X to get Y done. Now, when Y is completed, I may have the time and skill to turn to X and see if I can grok the source and update it, but the truth is that relatively few former users of X will fulfill both these criteria and act on them.

Cutting right to the chase, decrying a freely-given project because its source is not available, claiming a "fear of lock-in" is disingenuous FUD of the highest order.

In the end, I think we're really agreeing on all points. I'm not saying such fears are substantiated in this particular case, just what reasoning I feel is behind them as well as a (given, pretty obvious) work around of sorts.

I always knew you were a reasonable sort of fellow. [smile]