mechanicalSPIRIT

Always Check for Open Source First!

This is a lesson I've learned the hard way. Typically, when we engineers approach a problem, we are excited about the prospect of solving it. That is, we almost immediately begin imagining how the code might work, or what sort of algorithm we might use. This is a hard habit to break, but if we don't force ourselves to gain a bit of discipline, we will often end up wasting a lot of time solving problems that have already been solved (sometimes many times over!) by other people. It is a very disappointing feeling to spend days or weeks implementing a partial solution to a complex problem, only to discover too late that somebody already wrote a solution years ago that does far more than yours ever will. I've often had to ask myself "Why did I bother with this?"

The simple fact of the matter is that before you start laying down code, or even writing up a design, you should take 15 to 30 minutes and search the Internet for open source implementations of the functionality you need. You should try to get in the habit of doing this consistently, so that it becomes a normal part of your thought process. Some sites that you should always include in your search:

SourceForge
Google Code Search
Java.net (if it's a Java project)
freshmeat

In addition to those sites, you should do some basic Google searches for the functionality you need. You will probably end up being surprised at just how much useful stuff you find. Many projects, had they taken this approach from Day One, could probably have built themselves almost entirely out of existing open source components, shaving development time to a tiny sliver of what it had been, and therefore saving money and making time available for the addition of truly new features.

Loading mentions Retweet

Java's Future Lies In FOSS

I wrote this back in 2004 while living in Australia. It was published in CNet's Builder AU. It predated Sun's decision to release Java as an open source product, and in the end, many of the claims I made in this article turned out to be spot on.

Recently, much of the buzz in the software development community has been about one question: Should Sun Microsystems release Java under a free software license like the GNU General Public License (GPL)?

There are many valid reasons why Sun should. In fact, I predict that if Java is to survive in a world dominated by Microsoft for the long term, it must become Free Open Source Software (FOSS), where "free" means freedom, not zero-cost.

Currently, the source code for the classes that make up Java is mostly available for developers to view, but modifications of any kind are expressly forbidden (see the licence included with the Java SDK, in the "Supplemental License Terms", subsections B and D). This is the key reason why Java is not considered "Free Software". Being able to simply view the source to something does not make it FOSS, since creating modifications so that the software can evolve and adapt is more important to developers than simply reading about how existing code works.

It should also be noted that there are several third-party licences in the SDK, due to the fact that the SDK includes several technologies developed by entities outside of Sun. Converting Java to FOSS will require ensuring that these licences are compatible with a FOSS distribution model, or replacing the technologies with ones that are.

The benefits of a FOSS Java to developers will be enormous. Sun's "Bug Parade" is populated with thousands of unfixed bugs, many of them more than five years old. Even the simplest of bugs often goes unfixed, presumably because Sun lacks the manpower to fix everything, and must prioritise. There are, at the time of this writing, more than 7,500 open bugs filed against the SDK alone. An open source approach will not suffer from this. Bugs will be fixed almost as quickly as they are reported. The backlog of bugs will quickly disappear, as well. The quality of Java as a platform will instantly be boosted.

Not everyone, however, agrees that the benefits are worth the perceived risks. James Gosling, widely recognised as the "Father of Java", has played an important role in the development of this debate. In the April 12, 2004, entry in his blog he writes:

GPL software is not "free": it comes with a licence that has a strong political agenda. Like GPL software, the Java platform is "free" in many senses: you don't have to pay anything for the runtime or developers kit and you can get the sources for everything. Unlike GPLd software, the Java sources don't come with a viral infection clause that requires you to apply the GPL to your own code.

Gosling seems to feel that "freedom" requires absolutely no restrictions be present. On the contrary, those of us who live in modern western societies know that the presence of laws (that is, restrictions) is what enables us to remain free. This is the concept of "greatest liberty". The important thing is what those restrictions are. The same is true with the GPL, which grants very specific freedoms.

Gosling also implies that if Java were released under the GPL, that its so-called "viral infection clause" would require that all Java code written would automatically be under the GPL. This is a complete misunderstanding of how the GPL works. Linux, for example, is under the GPL, but programs written to run on it and use it need not be. Gosling is confusing the concepts of "program linking" and "writing for a platform".

Beyond these technical points, one might ask, "What is the big problem with making Java FOSS?" It's a complex question, and many in the Java community have provided excellent coverage of the issues. Joshua Marinacci is one that has covered this in his blog on java.net. He has covered many of the details, however, I believe he has made some critical errors in his argument, which must be refuted to understand why Java must become FOSS if it is to survive.

Marinacci points out four major "problems" that he claims would result from making Java FOSS. Probably the most important one is the first one on his list, which is echoed by the anti-FOSS Java camp worldwide: Java would become chaotic, and incompatible versions would pop up everywhere. Apparently there is a belief that only Sun's heavy-handed spec enforcement can keep this from happening (though it clearly failed to do so in a timely manner against Microsoft).

We already have good evidence that this will not happen. Linux is a platform under the GPL, and is based on a set of standards collectively called UNIX. UNIX is valuable mainly because of the uniformity of implementation of these standards on all flavours of UNIX, just as Java is valuable for the same reason. We do not see incompatible versions of Linux everywhere, though, even though there are many different and diverse distributions of it available. Most people see this diversity (read: freedom) as a good thing about Linux.

Similarly, the extremely popular database software called MySQL is available under the GPL, and the company makes no secret of this. MySQL is rapidly growing in the industry, and is creating a serious threat to purely commercial databases like SQL Server. Despite the fact that MySQL is GPL, nobody forks the code. Why not? Simple: doing so would create an incompatible code branch, and nobody stands to gain anything by doing that. The community is better served by working together to make MySQL better.

So there we have two spectacularly successful GPL products, both of which are giving Microsoft major headaches, and both of which depend upon standardisation. One has many distributions, the other only a few. This is why the fear that making Java FOSS would cause it to degenerate into chaos is unwarranted. It is more about paranoia than reason, more about control than progress.

FOSS works because it allows software to evolve like a biological organism, changing and improving in unpredictable ways over time to find solutions to seemingly intractable problems. If Java becomes FOSS, it will find ways around threats like Microsoft. If it does not, then those threats may eventually send it the way of the dinosaur. After all, having the comfortable predictability of being big and cold-blooded doesn't help you when the surprise meteor hits. Only being adaptable can keep the species alive.

Loading mentions Retweet

Getting Paid For Free Software

I wrote this back in 2004 while living in Australia. It was published in CNet's Builder AU. Though my views have changed a bit on several of the points I made herein, and I also now dislike some of the arguments I made from a quality standpoint, I do think my underlying point was valid.

In the war of words between open source advocates and opponents, a common refrain can often be heard from the opposition: "Open Source is not sustainable, because you cannot expect people to work for free forever."

Though their argument is not always applicable, they do have a point. Expecting an entire industry to grow and flourish based almost entirely upon donated time is a bit Communist in its expectation of altruism. In a recent talk called "The Open Source Triple Play" given by Michael Tiemann, Vice President of Open Source Affairs at Red Hat, Inc., it is pointed out that more than 90% of open source developers are employed as proprietary software programmers. This tells us that for most, including myself, writing open source software is done "after hours" in a hobby environment.

Read: It's like we're holding down two jobs.

Of course, that assumes the developers put equal time into both activities, which is unlikely. In the event of any sort of financial or familial disaster, which activity do you think would be the first to be removed from the developer's schedule? Obviously the hobby would.

I'm sure this will raise the ire of many a reader, who will point to successful open source companies and projects like Linux that are huge but were done in that same free time, but such an irate reader will be missing the bigger point I'm making. We all know that hobbyists can create amazing software. We know that because it's been done. What we should be striving for, though, is a software development environment in which those same developers can do exactly what they love, with exactly the same quality, and not have to hold down another job as well.

Is there anybody out there, FOSS devotee or otherwise, who honestly believes that if these developers could focus more of their time on their open source projects that the world would be worse off?

Hear me loud and clear: OPEN SOURCE DEVELOPERS DESERVE TO BE PAID. Cash money. In our pocket. Today. Yesterday! Even in a Socialist system, the individual is expected to be able to survive as a result of their contributed work. What sort of system are we building here? A development environment where writing software is like playing Dungeons & Dragons (that is, done mainly by "academic individualists" late at night for fun and no pay)? It's anti-economic intellectual onanism at best, and at worst, a system that makes the most inspired contributors suffer at the hands of Capitalist "daytime owners".

It's all quite tricky in the current environment, in which open source projects are started as grassroots efforts, usually completely unfunded, and perhaps even misguided. Where is the money to pay developers supposed to come from? What happens when the project dies?

I have a proposal. It can be done with existing technology, requiring only a bit more software development to build the infrastructure, and perhaps some legal personnel to make sure everything is fair. I call it "Pay Per Useful Contribution".

The specifics could be determined on a project-by-project basis, but the general idea is that any developer can contribute to any project, just like today, but projects would offer a payment mechanism based on some metric, such as "Number of Source Files Contributed" or "Number of Lines of Code Contributed". This metric value would be applied to a multiplier, and a contributor's score would directly determine his or her payment. Payments would be generated from either a pre-existing pool of cash (if available) or as proportionate percentages of income from eventual sales of the product.

For example: "UltraSoft's BigEngine Project" pays on a per-line basis. Bob Olsen contributes 1000 lines of code to the project, and Kelly Jones contributes 500 lines of code. 200 of Kelly's 500 lines, though, replaced some of Bob's, and this was appro ved by all parties. In the end, Bob has 800 Line Credits, and Kelly has 500. This means the total Line Credits are 1300, of which Bob has 61.5%, and of which Kelly has 38.5%. When the product ships, it has $10,000 of sales in the first week. Assuming there were no other developers involved, Bob would take home $6150, and Kelly $3850.

If you create value, you should be paid based on how much value you create.

Of course I've simplified the idea for this article, but it's only meant to be food for thought. Developers in the open source community need something like this. Desperately. It would not only encourage more contributions to open source projects, but would tend to encourage customer relationships (to increase income) and many of the other benefits of Capitalism.

And of course, it would let us stop holding down two jobs. Then we'd have more time for…Dungeons & Dragons???

Loading mentions Retweet