Open Source software plays a big role in the Java ecosystem (just think Maven, all the libraries in Maven Central, Gradle, OpenJDK, Ant, Ivy, Eclipse, Ant and so on). There is also a periodic “oh sh*t” moment when people deride OSS and declare it unreliable, risky and other things (perhaps the most recent one being
the discontinuation of GlassFish by Oracle).
Because of this I decided to write this post to show how Open Source is a great idea (if you keep your expectations in check) and why you should use it.
First, lets quickly run trough what Free/Libre or Open Source Software is and then delve into each of the points and see why they are important:
- You have access to the source code and you can build the functional end-product yourself
- Accepting the license gives the user some rights usually not granted by proprietary software
- There is a community around the software which accepts contributions (bug reports/fixes, documentation, new features) and all the processes (like bugtracker, discussions, etc) are in the open, accessible to every user
Note how I didn’t say anything about money there: F/LOSS is about freedom (“Libre”) not price. It is perfectly fine (and legal and in the spirit of the license) to sell a F/LOS software for money – although it is rarely done.
1. Access to the source code and a way to build the final product
This is what most developers think when they hear “open source” and the advantages are clear to all of us: looking at the source code makes it easy to understand the functionality and debug problems. Yes, you get documentation, but that can be outdated, hard to understand, plain wrong or missing your use-case. Also, you can debug
any software using tools like decompilers or system-level debuggers, but the effort to do so without the source is much greater.
Compare this to proprietary software: you get documentation (which may or may not be usable) and some support which usually has a 24 hours turn-around time and needs a couple of back-and-forths until they can solve your problem (if that can at all – and yes, I’m talking from experience here using tens-of-thousands of dollars worth of “enterprise” software).
Also, in the 60′s and 70′s (until the paranoia of “intellectual property” set in) much of proprietary software was distributed as source code exactly for this reason – to lower the support costs and make customers happier.
Note: the a way to build the final product part is important (and codified in the F/LOSS licenses). Otherwise companies could just give you a bunch of source files without the Makefile / build.xml / pom or even worse: say “sorry, we compile this with our in-house compiler which you can’t get”, circumventing the spirit of the license.
2. Using F/LOSS products grants some rights not found in proprietary software
But first talk about your obligations: as with proprietary software you have some obligations if you use the software – you accept not to hold the producer of the software liable for any damages and usually you wove not to sue the producer for patent infringements.
Compare this to proprietary software: you still accept such (or even more draconian) terms and you must do so before even taking a look at the software and before knowing if the software is fit for your usecase at all. Look up shrink-wrap license.
In addition to these restrictions F/LOSS licenses give you some freedoms not present in proprietary licenses:
- To use it for any purpose (some proprietary vendors prohibit you from doing benchmarks of their products for example!)
- To study how it works (the most important for developers)
- To redistribute it and
- To redistribute modified versions
3. Transparent community
This is the final part of the puzzle. A project which doesn’t accept changes and the discussions are not done in the open is not truly open-source. Conversely, for really open projects you have a vibrant community and a very good chance that someone else already encountered and solved your problem (no, we are not unique snowflakes – probably someone else has already struggled with our usecsae).
So we’ve seen what open source is. Now let me say a couple of words about it being capitalistic / market friendly: you can pay for the level of service you desire. You can even get support form different, competing companies (something which is not really possible with commercial software).
And what happens if the main entity (developer or company) behind the project stops supporting it (like it happened with GlassFish)? It is unfortunate, but if the project is valuable to the users, somebody else will come along and continue it. If it isn’t – it isn’t.
Compare this to proprietary software: if the company stops developing it, you’re out of luck and there isn’t even the hope for somebody continuing the development.
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.