Wednesday, July 17, 2013

Bountysource Open-Source Crowd-Funded Software : Mini-Review

Bountysource : Show me the Bounties!

Crowdfunding for OSS : Where are the "funds"?

Bountysource, which is being promoted as "the first crowdfunding platform dedicated to supporting open-source software" (OSS) in news releases today (about their seed round funding), is perhaps a semi-interesting concept, though from my quick look at the site has me questioning its merits on a few levels.  Being "first" does not mean it will succeed or even be useful.

The whole point of this site is supposedly to "accelerate open-source development" by offering "bounties" to get desired OSS project(s) or project-feature(s) implemented or OSS-issues/bugs fixed quicker.  Well, what I saw when quickly perusing the "projects" is that there is a large list of "projects" (where Bountysource probably just loaded a database with a list of popular OSS projects from Github and other places), but hardly any "funding" available for any of them.


No Global Search-Available-Bounties Feature?

Maybe I just cannot locate such a feature (if it exists), but it seemed like for a site called "BOUNTYsource" (key word: bounty) you'd be able as a site-user (potential developer) to quickly search all projects to see which ones had active bounties so that if you had skills to apply in hopes of being rewarded by those bounties that you could find such projects quickly and see if any were a "fit" for your skills. I could find no such search-by-bounty feature on Bountysource.  Seems quite odd.

Sure, you can "search" an individual-project for a bounty, but what is the point?... any bounties on a project are easy to see at an individual level, but the time to go through a bunch of projects one-by-one is just ridiculous (especially when that list of "projects", is like I mentioned earlier -- and apparent "dump" of popular project names, where most have no issues to work on listed anyhow).  I'd go further: what would really "accelerate development" of OSS projects would be the ability for a potential developer to search for all projects with bounties that required certain skill(s), but good luck with that for now -- such functionality apparently does not exist.

Not Much Bounty-Money Available

I suspect the reason for this (apparent) lack of search functionality is a simple one: they (Bountysource) do not want you being able to quickly see that there are VERY LOW TOTAL BOUNTY dollars available (in total) for all these supposed "bounties".   Maybe that will change over time, maybe not.  But, quickly perusing the most popular "featured fundraisers", the highest bounty amount I could find for anything was just under $10K USD, and that is a *standout*.

The Bigger Issues with this Concept

Aside from the bounty money thing, the site itself was super-slow (perhaps due to the press-release today?  search speed was terrible and/or timed-out for me) and the "chat" feature was useless... I saw a list of (supposed) logged-in people (perhaps 20 or 30) and asked a question or two... waited... waited... NOTHING.... useless.

But, the biggest issue has to do with whether this "bounty" approach to accelerating open-source-software development is even a "good thing" to begin with.  I understand that many OSS developers could sure use any funding they could get to help offset their invested time/cost (I for one develop OSS for "free" otherwise), but I can also see this leading to Bountysource becoming the next eLance or oDesk or such in its own right: i.e., pure garbage! Don't over-analyze that comparison too much as I realize this will be a bit different, but I do think it could end up with similar issues.

For one, I think there is likely to be a group of people that search the web for existing-code to simply copy/paste (with perhaps minor alterations) where possible to make a submission toward a bounty (in hopes of quick cash), and bring into question all sorts of copyright mess.  Hopefully I am wrong about that, but it seems inevitable.  There is going to have to be some code-plagiarism-detection of sorts or this will likely happen (and the day other developers find their code posted as a "solution" to a Bountysource item without their consent, things will get ugly).  The bottom line is that I can see how simple it will be for money to "corrupt" the entire open-source-software paradigm; hopefully that is not the case.

Either way, you may want to check the new service out and decide for yourself whether it is "good or bad" for OSS software development.  Who knows... maybe Bountysource will implement a useful search feature for developers to locate projects that may be something they'd consider working on for money, and in tandem maybe they will find a way to (try to) ensure that submissions are not substantially-copied-source-code/fixes/etc that others have published or own already.  I will admit there are times where I would gladly pay a "bounty" to get an issue in certain OSS software fixed, or a feature implemented quickly, if I could... but, most of the time I am able to fix things myself, submit the fixes, and/or simply be patient and wait for a reported issue to be fixed or implemented by the developer(s).

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.

Wednesday, July 10, 2013

Google Dart vs. JavaScript Debate

Dart vs. JS : Objective Reactions?


Google Invests in Dart to Improve Upon JavaScript.
Brendan Eich tries to Reason Why Dart is Not "Right" Approach

I was just reading Brandon Jones's blog entry titled "A Tale of two Web Technologies" today where Brandon put forth a nice call for discussion about Dart vs. JavaScript (JS).  I liked how Brandon summarized his position on this subject as follows:
"For my part I think they're both [Dart and asm.JS] awesome technologies with different use cases. If I were building a new web app from scratch I'd want to code it in Javascript or Dart but would prefer Dart due to its cleaner syntax, built-in libraries, and potential speed."
I am with Brandon all the way on this — there is no comparison between the cleanliness of Dart code and the equivalent (current) JS code (or asm.JS-infused mess): Dart makes writing large-scale, object-oriented, performant applications for the web so simple compared to JS!  Sure, it is not "perfect" and has some areas that need attention (as I have blogged about recently: see areas that Dart needs to improve upon to further adoption).  But, Dart solves a LOT of the issues that exist with JavaScript.

As expected, I noticed that Brendan Eich  (of Mozilla CTO and JS-inventor fame) was quick to jump in to represent and defend the JS camp (by commenting on Brandon's posting), while a few others expressed a mix of opinions about JS and/or Dart.  But, as of right now when I am writing this, I really didn't see anyone aside from Brendan (who has a serious vested interest in being a proponent of JS over most any "competition") really making any substantial arguments for sticking with JavaScript over Dart.  I think that alone says something.

An utterly huge number of JS developers are out there, but I cannot help wondering how many are at least in some part annoyed by the promise of what "ES6" or "ES7" will bring when the wait for such things has seemed infinite.  I personally gave up on waiting (for EcmaScript to get to where I wanted it) when I saw the difficulties the ES parties had even try to agree on how to implement classes (objects) and inheritance, etc.  Ugghhhh.  Like there is anything to "invent"??  How many languages do we need as a reference for a decent object system (plenty exist)?  Well, thankfully Google decided NOT to wait forever and instead created a language (Dart) that included the modern constructs and features I expect in a development language.  And, coming from Delphi, C#, C++, and other programming, Dart felt as natural as anything could be... and now I can code for the web much like how I write desktop applications.

Dart is FREE! Dartium (browser) Exists Now. Why knock it?

Maybe I am just unusual in my thinking.   Personally,  I do not see any problem at all with requiring a variety of Browsers (that may have varied VMs within them — Dart, JS, whatever) in order to access content that relies on applications / scripts written in a variety of languages.  E.g., "Dartium" (Chromium with the Dart VM in it) exists currently and works fine for viewing both Dart-based web applications as well as JS-based pages. We have all seen the "best viewed with XYZ browser" on sites at one point or another, so would it be that big of deal to see "runs faster with Dart" indicators too perhaps? And, what do I care if I need multiple browsers on my system to interact with various sites/services or to have an optimal experience?

Customers (i.e., users) don't seem to mind installing tens (or hundreds) of "apps" on their devices, so why would users care if the "app" called "Dartium" (or FireFox, Safari, etc) is required in order to access some other functionality/content? What I am getting at is that I don't think users care one iota about how their various apps/content are built, etc., so long as all are relatively stable, responsive, and simple enough to use. The rendering-engines in the browsers are what should be important (to users), and that's about it. So long as a browser renders the content of a site/app correctly, I doubt if any user could care less if the underlying scripting language (that augments the HMTL/CSS layout engine and standards) is Dart, JS, Forth, Modula-2, or Assembler... it is irrelevant to me and to most users. As a developer, I can choose whatever works best for me so long as the user has a simple way to use my site/app.

I think that arguing for "backwards compatibility" with JS is also nearly a pointless endeavor.  Users will not care so long as they are appropriately prompted to access content with the required "app" (Dartium, etc) and provided with a way to get that app.   Think about all the websites of old that had links for downloading the Adobe Flash Player that was needed to view content: and, guess what... people did, and did so in a huge way!  Flash became ubiquitous on the web.  Flash provided people with an improved user experience (well, "improved" if you like all those animations that is).  So, if Dart (or some yet-to-be-known technology) offers such an improvement, trust me: people will download Dart, Dartium, whatever in order to experience it! Games certainly come to mind: give gamers a higher frame refresh-rate that is only available through native Dart apps, and a whole group of Dart-aficionados will emerge.  Gamers could give a crap about whether their web-UI or app is "backwards compatible" with JS.  And, do you really think business-applications will be much different?  The only substantial challenge I see is mainstream public-facing web sites, but so what... that will come later.

Is Dart the Future of Web Programming?

Maybe.  I personally think JavaScript is likely ALREADY DEAD (its fate sealed), though there will undoubtedly be many people that will argue til the end that it is not (even beyond Brendan E.), as efforts like asm.js try to keep it alive.  And, regarding asm.JS, I like the comment left by an "EricomGuy" on Brandon's blog, stating:
"[...] I have two concerns regarding asm.js: 
1. JavaScript developers, in particular the "jsPerf crowd" will manually write asm.js code in an attempt to squeeze a few extra cycles out of the VM. This may end up pushing JS usage patterns in the wrong direction
2. JS VM manufacturers will focus on improving asm.js performance rather than on JS in general. I know V8 already stated they will not do it, but they may be forced to once they start falling behind in performance comparisons. 
If both #1 and #2 happen it can create a vicious loop that feeds itself, to the detriment of JS."
I think those are valid points, but moreover I think asm.js is a ridiculous attempt to decorate JS in such a way as to bring Dart's formal language features and benefits into JavaScript instead of simply admitting Dart is the correct way to truly "fix" JS.  I am amazed how long the JS language has held on, and it is starting to remind me of M (alternatively "MUMPS") or other such languages.  Like M, it is bound to hold on a long, long time, but I expect Dart, TypeScript, or some other languages/approaches to start whittling away JS's ubiquity, and soon.  In a way, I see asm.js as a JS version of Intersystems Cache's answer to the shortcomings of MUMPS (and, a way to extend the life of a language and technology that needed a major overhaul.  Don't analyze this comparison too deeply — I realize there are many differences — but, some similar history may come to pass.

Thinking a bit further ahead...

I suspect the Dart-vs-JS discussion is just a total myopic distraction that may obscure us from recognizing the emergence of much more substantial and possible paradigm-shifts (much more disruptive than Dart, asm.js, etc.) that could hit "browsers" and web-based apps in general.  Dart is a welcome nice natural step forward, and one that should have come much sooner.  But, as I contemplate the incredible growth in network bandwidth and processing power and then extrapolate what things may look like in perhaps a mere 10 years or less,... this Dart vs. JS language-choice discussion may look ridiculous in hindsight.  Some company is going to upend things in a way that a simple browser-language/VM change cannot.

I put forth part of a vision of things to come, as I saw it, in a 2006 blog of Software Prognostications (my upcoming sentences will perhaps be more meaningful after reading that), and part of what I foresaw then has come to be since, but things are not yet completely to where I envision them going.  I saw "apps" coming a long time ago.  And in a way, the modern browser(s) have become, to a lesser extent, the "virtualization" environments that I was expecting on the client — they offer at least some degree of sand-boxing and isolation for security (though hackers still find these too easy to break out of) — and, with the advent of the Dart-VM in a browser, or the V8-JS engine in a browser, or SpiderMonkey or any other language-processor in that browser-encapsulated-virtual-environment-for-rendering-HTML/CSS, things are getting closer to what I had hoped for.  I want the option to deploy my web apps using whatever tech-stack makes the most sense, and I want it to be super simple to do.

As I see it, the only thing the distributed client device needs is a hypervisor / hardware abstraction layer and the ability to interact with and "navigate" the web (i.e., find a URL to pull a VM from) and a way to very nicely isolate/sandbox this stuff.  Essentially, I am waiting for the day when end-users have the equivalent of a bare-bones VMware ESXi-like Web-Meta-OS on their devices and that each "site" or connected "app" is pushed down as a VM image immediately when someone navigates to it (perhaps persisted and used by multiple sites too, where it makes sense — as would a common "basic backwards-compatible JS/Dart web browser VM" would be for a while. heh),... and each VM may contain the "optimal software stack" (as determined by the creator/publisher) for its purpose, and that stack may be a minimalist-Linux with Dartium or Firefox or FutureFox or whatever, or perhaps a proprietary OS with custom apps written in god-knows-what.

Cloud-hosting may minimize what all "needs" to be downloaded to the client like this, and for applications that absolutely must run "on the client", my vision may well require a network backbone based on quantum entanglement and zero-latency-at-arbitrary distances, but I suspect that is coming too.  Fact is, Intel and other hardware makers are going to have to figure out some way to keep distributed computing-power a "must have" thing.   So, I have to bet on the further increase in computing power coupled with every-cheaper and ample storage too.

But, I can picture the day where particular to a website/app, the user gets a VM fully loaded and optimized for that site/app, be it browser-based (or maybe even an entire Windows 12 or OSX-15 application), ready-to-go, fully-isolated/secure, and so on.  If that VM is running a Delphi XE5 app on Windows 9, so be it.  If it is a browser-based app written in Dart that requires Dartium, great.   If it is asm.js or JS "classic", fine.  So long as users don't have to know anything the internals of the app, and so as a developer I can choose to write my sites/content/apps in whatever language/stack I choose, great!

In the mean time....

Bottom Line: Embrace Dart (or even TypeScript)

For now: Dart wins, hands down over JS!  TypeScript is a fine improvement too.  And, I'll be darned if I am going to waste time on asm.js — that just sounds nuts (my opinion).  I see asm.js as nothing but a workaround for embracing something like Dart and the DartVM in browsers in order to prop up the JS "side" of this debate.  But, maybe that asm.js code will be more easily and automatically converted to proper Dart-language or TypeScript code by automation tools down the road?  (perhaps there will be value in it after all).

Continue to read this Software Development and Technology Blog for computer programming articles (including useful free / OSS source-code and algorithms), software development insights, and technology Techniques, How-To's, Fixes, Reviews, and News — focused on Dart Language, SQL Server, Delphi, Nvidia CUDA, VMware, TypeScript, SVG, other technology tips and how-to's, plus my varied political and economic opinions.