Your problem is:

"Not invented here."

A common fallacy!

"As with other ailments, the first step in curing NIHS in ourselves is to admit there is a problem. Some organizations and individual developers seem quite content to re-invent the wheel over and over, congratulating themselves on their innovation at the same time."


See, for example: http://www.developer.com/open/article.php/3338791

A common sense (hopefully) explanation I use is the following:
There are libraries/classes/packages out there made by people who
a) have maintained them for quite a while now
b) actually enjoy coding such routines
c) gathered significant experience doing what they do
d) have put a lot of research into their work
e) often offer it for free, submitting it to a community review process helping the product mature

NOT using them will yield:
a) more expenses for additional development time
b) setbacks in developer motivation, since you assign tedious chores to them
c) higher probability of bugs (you were hired for your skills to do project X, not for a library that does Y)
d) sub-optimal solutions, most likely
e) fewer features
f) less compatibility
g) less portability (just think MFC or VCL versus FOX toolkit in C++)

It's true, Open Source software might be 'buggy', especially when you deal with 0.x versions, but you get free updates or you can make them yourself (since the source is open), and while a closed source team are the only ones who can investigate bugs and make patches, in an open source team, everybody can!

Closed source software is often just as buggy, and in those cases, the bugs are usually crippling, because you have no chance to continue your work before the other company decides it's time for a patch. (note that since you already paid for the product, and you won't pay for a patch, they have no economic motivation to do so when it's only regarding you!)

Not Invented Here is BAD!

[Edited by - Thygrrr on November 27, 2004 8:24:02 AM]

People who dismiss open source out of hand are too lazy to investigate the particular product you are trying to use. As Thygrrr said, you have just as much good open source software as bad, the same as commercial products. The big thing to look for is to see if it is actively maintained and how long it has been around. Any open source software goes through rigorous testing by the community that uses it and is usually more up to date than commercial products. You just need to investigate each choice separately before deciding.

On another note, look at the new java.NIO package for better network APIs. Checkout The Java Games Factory articles section. There is an article on how to use it for networking, without threads.

Ah, I almost forgot:
Bummer! "Java itself is Open Source!" ... and it's free, too.

Quote:

Original post by Thygrrr Your problem is: "Not invented here." stuff

Best worded argument for open source I've ever heard.

Just a thought here.

I've used several open source packages and find the whole thing interesting from personal experience. Just for Java I have used the following Eclipse, NetBeans (though I'm not sure if that's open source) Xerces, Xalan, log4j, JUnit, etc. The set of tasks which these technologies provide appear disjoint, but the potential for combination, strictly in my opinion is only limitted by ones imagination. This however is not the virtue saought after during developement or under time and budget pressures. However, interesting nontheless.

What I would suggest is perhaps development of an open source tool that assists the developement team to understand the open source technology they wish to employ, and even build. Something like Posiedon, or Enterprise Architect, but with better round trip from UML to code, and back again. Most critically refactoring that also warns, or updates tests. The idea is to combine these seemingly disparate technologies, that are individually tested and deveoloped in the hopes of combining them into an environment for high levels of productivity.

Though the whole world of code generation is somwhat myth-like. And I would be the first to say that I don't particularly like the route most code generators take with the esoteric code they sometimes generate.

However it would be cool to take something big like Eclipse, or Xerces, or even Nebula2 and run a program that decomposes the entire thing into UML. Sounds fictitious, but it has been possible for years.

Its something I have been working on actually -- on the side, of course.

L-

I've use Open Source products all the time (at home and at work), and don't generally have problems with them. In fact, the people I work for are usually pretty happy when I find a free solution to a problem (remember, an in-house solution is not free, they have to pay programmers). Just like in the commerical world, don't use something without checking its version number, and features. Just make sure that your Open Source solution is

1) The version number is >= 1 (at home you can try v0.x, but at work I'd say stick with stuff that is offically out of beta)

2) There is a good looking web-site with information about the project, and possibly a release schedual.

3) There is some type of community forum that is active.

If you're really worried, just ask your boss. Most likey, the money saved by downloading a ready built solution will outway in possible shortcommings of the software.

Quote:

It's been available for free for some years? There's lots of Eclipse plugins that do round-trip UML programming...and, since it's going into eclipse, you get the benefits of the almost-good-enough eclipse formatting system (which is very good compared to most). Or am I missing something?

What I meant was that there are several UML round-trip plug-ins for eclipse, but there is ussually little cross integration between something like JUnit for UML round-trip, or for that matter simply programming from a UML editor with full plotter, or CAD output, or for rendering a program in a more generic version like XML, which I only vaguely suggested, I think.

Though programs like Posiedon, etc, have gotten better at programming at that level, the issue of creating test cases is still open, sequence diagrams are still not fully generated (which is really what I'm interested in, but algorithm visualization is a deep topic.) And full blown interface modelling, this is where people who believe UML is short-hand for describing a program and folks, like me, who want a full schematic of the program, see UML in different ways.

But I believe the things that I have talked about here are all possible from an open-source integration perspective. Which is interesting because it would imply that the perifery of technologies is fleshed out, or at least heavily used and tested. Meaning that only integrating these tools is the real chore.

It kind of reminds me of BTrees (Multiway Trees) where once a node becomes too full it splits and passes a key upward toward the root. In this way the process of open source actually, though slow compared to engineering a specific tool, allows the community the opportunity to integrate, research, and experiment with both the code and the technology to acheive incredible flexibility and integration.

That was my point.
L-

I would be careful about including open source code within your programs. I use open source software often, but I am very leary about letting anything spelled *GPL into anything I do at work. The GPL is not compatible with anything we do here, and to taint our code base with GPL, thus creating a "derivitive work" could be disasterous *if* someone were to know about it. Of course, rewriting the GPLed code would solve the problem, but it's too late if the product has already hit the presses.

If in doubt, talk to the guy in charge.

Thanks to every one for the input. After reading this post the next day, I should have posted somewhere other than the java forum. Sorry, I guess I was just irritated, and since the open source thing was java, this is where I went. I didn't want to start bashing open-source, but being new at getting paid to program, there is a lot I still have to learn. Loops and threads are not enough. I do agree that trying to re-invent the wheel is a waste.

Quote:

Original post by smr I would be careful about including open source code within your programs. I use open source software often, but I am very leary about letting anything spelled *GPL into anything I do at work. The GPL is not compatible with anything we do here, and to taint our code base with GPL, thus creating a "derivitive work" could be disasterous *if* someone were to know about it. Of course, rewriting the GPLed code would solve the problem, but it's too late if the product has already hit the presses.

The GPL is explicitly designed to make sure you don't use it in a proprietary product.

The LGPL pokes a hole that allows you to use the code, however, so LGPL (like SDL) are fine for proprietary products.

Quote:

Original post by smr ... to taint our code base with GPL, thus creating a "derivitive work" could be disasterous *if* someone were to know about it.

To use it, distribute the results, and not provide the source would be illegal, whether anyone knows about it or not.

Quote:

Original post by C-Junkie The LGPL pokes a hole that allows you to use the code, however, so LGPL (like SDL) are fine for proprietary products.

EDIT: this post is intended as a friendly warning. I am bitter that it's all so murky, because it has in the past frustrated my attempts to get certain java libraries used - the murkiness and FUD tolerated (if not actively spread) by the GNU folks was sufficient to ensure decisions were made against *GPL code for no other reason than that we couldn't be sure we were safe.

Going back on-forum for a moment :) the GNU folks have several times stated officially (but via different individuals, who have been discredited, recredited, etc - so no-one is really sure any more) that java is a special case, and tried to patch things up so that GPL/LGPL apply correctly to java (although last time I checked they still ahdn't amended the actual license to make this official).

The LGPL/GPL was written as if by a lawyer who knows little about tech. It's stupid. It's written for the C programming language - nothing else - and basic java concepts such as 100% dynamic (runtime) linking, which were years old by the time GPL was invented, were ignored, along with more interesting (yet still well-established) ones such as runtime compilation.

Literally speaking, I believe it is impossible to make GPL'd java code (I did ask a lawyer about this a long time ago); either that, or it's impossible to make LGPL'd java code - I can't remember which (all to do with definitions of linking, compiling, etc). But it's far from clear and GNU have never bothered to make official guidelines on this that are posted alongside the GPL - I think they are smart enough to realise that by not doing so they spread FUD about what is allowed and what is not and most people then veer on the side of safety, thereby making the GPL/LGPL more effective than if it was all spelled out clearly. But then it is liable to all fall to pieces if it ever gets challenged in court.

This, I believe, is one of the reasons some senior people impose "no open-source products, unless desktop apps only" policies. As long as it isn't used anywhere next to actual code then you have nothing to worry about. If you're a company with no programmers, you have nothing to worry about. For everyone else, there's only confusion :(.