Monday, 29 January 2007

Debugging Flex Applications

Today I received this email:

Now that Flex 2.0.1 is out the door, the Flex product team is deep in planning for future releases. To make sure we’re focusing on the right things, we need to hear more from the community, so if you’re using Flex please take a few minutes to fill out a short survey.

The survey can be found here: http://www.surveymonkey.com/s.asp?u=801873200349

As always, we appreciate your valuable feedback.

Thanks, The Flex team

Okay so I filled this out. I have no doubt I'll be getting a call asking me to buy some 10k-15k/cpu FDS license (nearly all surveys by all big companies are by the sales/marketing department with ONE PURPOSE: lead generation), but.. I had to fill it out and put things like this in the comments:

LINUX SUPPORT!!!!! Especially, Flex Builder for Linux -- mostly I want the dang debugger...my beard isn't long enough to use a line debugger. I'm going nuts trying to get this stupid combo box working.

If you're like me or if you even like me...or hold me in polite ambivalence...I wouldn't mind if you added your voice too. I mean sheesh, Linux may not be the worlds most popular desktop client, but I would bet that a disproportionate number of uber-geek software developers use Linux! Shake these suckers up and maybe whine about Apollo too (we can whine about WebKit vs Gecko later ;-) ).

Posted by acoliver at 11:08 PM in Meldware

Friday, 26 January 2007

Apollo version of our Webmail client

Check out Adobe's Apollo. Want to see a version of our Meldware Webmail running on it? It could help with offline functionality. Guess what? TOO BAD! James may add it to the build, but it won't be part of the mainstream distribution and the core developers in general won't be testing it or building it or whatever. Instead we'll probably be building a Java-based offline backend (basically a trimmed "dummy" version of Meldware CS) installed with Java Web Start. Why you ask? Well most of us can't actually run it or build it or test with it for the simple reason that we use Linux. Adobe's Linux commitment continues to leave something to be desired. It is too bad too. Apollo looks like it might be a good idea.

Technorati Tags:

Posted by acoliver at 7:08 PM in Meldware

Wednesday, 24 January 2007

IETF, open source and the Internet under attack

David Berlind, who is quickly becoming one of my favorite columnists, writes about the efforts of Larry Rosen in regards to the Internet Engineering Task Force. IETF is the standards body that holds the spec on IMAP, SMTP and many other Internet standards.

Generally, the Internet standards that you use are free of patent encumbrances. This has allowed them wide adoption in both open source and proprietary software. Your browser communicates nicely with this open source blogging software running on an open source application server as well as IBM.com presumably running on WebSphere. It is Royalty-Free standards that have driven the tremendous growth of the Internet. However a select group of patent-rich companies with short-sighted views of the world have continually tried to get standards bodies to switch to "RAND" (reasonable and non-discriminatory...which under NDA is up to the patent-holder to decided what is reasonable and non-discriminatory) and other even less equitable policies (in the case of IETF).

Additionally, there has been some discussion on the license-discuss list at OSI about how these patents are even disclosed. If I understand correctly, it is even worse than Mr. Berlind describes, it sounds like in the "MUST" section of an IETF RFC you can reference "something else" which might allow you to require implementors to implement a patented technology, yet you can probably *not* disclose the patent. Since patent searches are expensive, in part because the patent office has a horrible database index system, this could make a great business for someone at the expense of the rest of us. It is a great scam no?

on the Adware vs Open Source front

Meanwhile, TheServerSide has a long discussion about Terracotta's claim to be open source. I'm concluding my efforts at OSI to formalize the arguments against Social Text's adware license provision submission. You can read the draft and participate in the discussion. If socialtext does not revise their license (which has sentence structural issues) then I plan to "formally" submit this to the board next Tuesday. The paper also contains links to help you acquaint yourself with the issue of "badgeware" aka "adware" which inaccurately is sometimes referred to as "attribution" (though that confuses the issue with more innocuous BSDish licensing).

A similar controversy does not exist in Free Software as there is a clear stance against "advertising clauses" which goes well beyond open source. Meldware uses a license that is both Free and Open Source.

UPDATE

Ross Mayfield, of Socialtext, writes:

Socialtext will submit the Socialtext Public License next week that includes MPL and a modified GAP. I look forward to the discussion.

I'll revise or reconsider the anti-GAP position paper as appropriate. I'm pleased that Ross is reworking the submission.

Posted by acoliver at 2:38 PM in Open Source

Thursday, 18 January 2007

Why the "attribution debate" aka Adware is important and Matt Asay is wrong

Today Matt Asay continued to use his Infoworld Blog to push his adware agenda. First as political think tanks have shown us, is the necessity framing of the debate. Mr. Asay frames this as "attribution", snubbing even the very positive sounding "badgeware" and our prefered "truth in advertising", "adware". He then presents us with a false delimma: GPL or MPL+adware-clause. There are other licenses. It is possible that none of them achieve what Mule wants from a business perspective. In that case they should just call their software what it is "shared source" with their partners and customers, or create a license without the adware clause that meets the definition of open source.

First off, this has NOTHING to do with BSD style "attribution". And Mr. Asay, as I mentioned in a comment to his blog, knows very well that the licenses in question violate the definition of open source. Let's look at the license in question:

This License does not grant any rights to use the trademarks "MuleSource", "Mule" and the "MuleSource", "Mule" logos even if such marks are included in the Original Code or Modifications. However, in addition to the other notice obligations, all copies of the Covered Code in Executable and Source Code form distributed must, as a form of attribution of the original author, include on each user interface screen the "Powered by Mule" logo and (ii) the copyright notice in the same form as the latest version of the Covered Code distributed by MuleSource, Inc. at the time of distribution of such copy. In addition, the "Powered by Mule" logo must be visible to all users and be located at the very bottom center of each user interface screen. Notwithstanding the above, the dimensions of the "Powered by Mule" logo must be at least 130 x 25 pixels. When users click on the "Powered by Mule" logo it must direct them back to http://www.MuleSource.com. In addition, the copyright notice must remain visible to all users at all times at the bottom of the user interface screen. When users click on the copyright notice, it must direct them back to http://www.MuleSource.com

First off, this is a horribly written license which contradicts itself. It actually can be seen as prohibiting redistribution entirely as first I have NO permission to use the trademark, but must use it prominently! However it also very clearly violates the open source definition as explained by the people who coined the term "open source":

10. License Must Be Technology-Neutral

No provision of the license may be predicated on any individual technology or style of interface.

Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.

The Mule license requires me to have a UI. However, there are more practical issues. Let's pretend that Buni licensed all of its source under Mule's license and you used Buni's source in your product (with our logos in their stead). Let's also say that if you were to take this JNDI code from Mule and use it in your code. Now you are required to display BOTH the Buni and Mule logo at the same spot on the screen. That is how these prohibit redistribution. Add to this the impracticality of excessive adware display.

However, Mr. Asay probably knows this if he's been paying ANY attention at all to the 9 times it has been explained on the license-discuss list at OSI where is is a board member. I can only suppose that he chooses NOT to understand it. I don't mean to be salty, I just believe he is being disingenuous as an argumentative technique in using influence to push through the idea that these licenses and projects are open source. Mr. Asay is also characterizing us all as a "vocal minority" -- yeah...like the open source movement, registered voters and people who recycle. In actuality the number of companies with these adware licenses that are advertising themselves and their software as open source is quite small at the moment.

Moreover, my agenda is simple:

Agenda for posting here instead of my personal blog: differentiate Buni, push traffic here instead of there (besides my personal server is a bit measly). Some people "called" me on this (I thought it was completely obvious). I replied: duh.

Keep open source "open". Meaning Buni builds on a wide array of existing open source. We could NEVER build everything we depend upon (nor could Mule). We depend upon the "open source ecosystem". As a practical matter, we could never advertise every little library in our UI. If Mr. Asay succeeds in expanding "open source" to include "adware" then a slow tilt will happen.

Educate people on the subject against the misinformation being spread by those with a vested interest in expanding the defintion of open source and the damage it will cause if they succeed.

Links to get up to date:

update: Mr. Asay has responded to my comment in his blog:

Actually, Andy, I really do not know it. Nor does the OSI know it. In fact, there's still a lot of discussion and disagreement on it, but I personally don't buy the argument based on #10.

Here's #10, which you cite:

No provision of the license may be predicated on any individual technology or style of interface.
I assume that you cite this to say that if a license requires a graphic, it can't be used in headless environments, or mobile screens, or whatever. I don't buy this. It may mean that the licenses, as written, need to allow for other forms of attribution (not sure what it would be in a headless environment - perhaps it reverts to header files with attribution?), but it does not mean that attribution, itself, is not OSD-compliant. This is just a matter of editing these licenses, not throwing them out.

Again, I do not like attribution. I think the GPL is much more effective as a business tool, and as a developer tool. But my dislike of the licensing mechanism doesn't lead me to the conclusion that it's wrong.

I NEVER said "attribution" was not OSD compliant. I said that adware aka badgeware is not. I do not object to a link and a message ala BSD et al. I also don't object to "on any title screen or (c)" banner -- although I don't "like" it. When you start requiring persistent logos on the screen at all times in specific real estate...AND they call it open source (despite two of the same license being unusable together) -- it is clear to me that a line is crossed. Sure it is an effective business tool for "conversion" but it is damaging to the open source ecosystem. Requiring everyone who uses the software to buy a license and restricting distribution of the source is a more effective tool for "conversion" but you would agree that advertising that as open source would be a simple case of fraud would you not?

Technorati Tags:

Posted by acoliver at 3:54 PM in Buni.org

Monday, 15 January 2007

Roy Russo wrong on so-called badgeware

My friend and former JBoss collegue, Roy Russo has come out in the "attribution" aka adware debate in favor of adware. Matt Asay agrees with him and has thus given him airtime on his InfoWorld blog and thus Google news.

Simply put - It stops the Larrys of the world from taking your code, branding it with their big fat "O", making a mint off of it, and never paying you a nickle. Its another method that open source companies have found to create cash from "free" (or "monetizing" - stupid word).

First, I would like to point out, with no disrespect to Red Hat (in fact in tribute), that Red Hat did not write the vast majority of what Oracle has branded as their Linux distribution. Red Hat is not very like JBoss in the sense that while JBossAS has an enormous number of dependencies, the core components that make it an "Application Server" are written by JBoss. Red Hat does write a lot of code by joining employees with existing projects (or hiring from in some cases) that are ultimately packaged into its Linux distribution, but the core of its operating system is written by someone else (albeit Alan Cox is a big part of it). The company that Larry Ellison is the executive of, Oracle, is taking a shorter route by removing Red Hat's branding and selling it as its own Linux distribution. Supposedly they may make changes, this constitutes a derivative work. You can argue that they are freeloading on Red Hat or even open source by only riding on top of Red Hat and maintaining a big fork (which theoretically individual projects could go grab the patches from if they blow a lot of time with SRPMs and diff). However, creating "derivative works" is not supposed to be prevented (as you suggest) by the very definition of open source written by OSI.

In fact, Roy, Matt Asay is the Vice President of Business Development at a company which provides, from what I hear, a very good Enterprise content Management solution built on top of your baby, JBoss Portal. JBoss Portal is built on top of JBoss Application Server, Hibernate and other products. JBoss Application Server is built on hundreds of open source projects including some written by volunteers to Apache, including Tomcat and Xerces. It is also built on independent projects like Javassist and cgLib. I have a lot of respect for Matt Asay and the Alfresco gang, not only as technologists but as business pioneers. However, I think both you and they are being short-sighted here. The reason open source works is because of derivative works. In fact, I think Matt Asay and Co. are shrewd enough to have chosen an alternative to Portal if it had these "badgeware" (adware) restrictions. First, if all of the above projects had similar restrictions that would be a lot of screen real estate. Any kind of licensing scheme would have been more than Alfresco would have been willing to bite off in the early stages, "you want what percentage of our customer's dollar?". If this licensing scheme had taken off in the early days then, depending on the most prevalent terms regarding UI persistence, I think JBoss would have been inviable as a company and Alfresco would have never been a customer. In fact, forget the amount of screen real estate. Some "exhibit B" licenses are requesting SPECIFIC screen real estate. If that happened then it would have been inviable to create aggregate derivative works withusing two packages which use the same licenses.

Back to Red Hat and Oracle: In fact the Oracle thing is so far a big dud. It shaved points off the stock (full disclosure: I do not currently own any Red Hat stock but may benefit from the stated "earn out"), and I mentioned I thought that was crazy. However, the stock as rebounded. As it turns out investors were more concerned in the long term about the effects if Red Hat was unable to capitalize on its acquisiton of JBoss. As news reports started reflecting a positive message regarding the JBoss acquisition and Red Hat's profitability, the stock rose. In fact, that is pretty sensible. Red Hat has a brand, services and this fuzzy thing that Marc Fleury used to call "IK" before he started promoting cosmetic products. Intellectual Knowledge. The idea that the people not working with the inards of a code base on a day to day basis won't be able to provide the same level of support as those that do. Oracle has a brand, but a limiting brand (because they tend to fail at things not directly DB related) in some ways. Red Hat's brand is more effective on their home turf. Oracle's service is also renowned for long hold times and ineffective answers. Red Hat's service is less encumbered.

Bottom line, Roy is that Open Source is writting software "under the gun". If a customer doesn't think that you're doing a good job they will fork it and go into business themselves or someone else will (i.e. Oracle). The market then decides. Matt wants to "let the market decide" what "open source" is.

But it's a thorny issue, and one that OSI prefers to move slowly on. That said, I agree with you: the OSI needs to act or risk irrelevance. I, personally, can see both sides of the attribution debate, and I think the market is largely deciding the issue for us. The market seems to be quite happy with SugarCRM, Zimbra, Alfresco, SocialText, and other companies that use attribution. Perhaps the OSI's vote won't matter much in the end?

This is a very dangerous thing for an OSI board member to say. OSI considers itself the abitrator of what is and is not open source. Matt is trying to negate that (while on the board) and say "its up to the market". Well if I put an ad in the phone book that says "Heavy Tractor Sales" and send you a used jet ski, I have committed an act of fraud. I can utter a Clintonian, "let the market decide what a 'heavy tractor' is", but I still shipped you a used jet ski and he still... There is a long dispute over whether OSI owns "open source" as a trademark or not. I question whether it is still in a position to assert it, but "come on!" you guys are potentially creating a class software that can't be aggregated together even under the same license! A class of software that you wouldn't use in your product for practical reasons (every screen has millions of pixels dedicated to ads). You want to call that open source?? Get real! (BTW none of their licenses have been approved by OSI YET)

Guys, why are you trying to redefine open source to include this new economic inefficiency (aka profit) when your companies depend upon and are built upon this economic efficiency (aka cost-savings/shared resources)! BTW, My bet to any Red Hat employee that will take it: first million dollar deal that Oracle nearly blows with its Linux...they start reselling Red Hat support and become just another channel partner (probably with a fat NDA at first). I bet it happens inside 3 years.

BTW, Buni Meldware Communication Suite including the Webmail component are both open source and free software. We like it coding with a gun to our head. We are actively seeking partners for our upcoming business launch for our multi-platform groupware product (which enables email, calendaring, and webmail in an easy to administer package). Those partners may rebrand the webmail client if it makes them happy :-).

Technorati Tags:

Posted by acoliver at 6:50 PM in Open Source

Thursday, 4 January 2007

Marc Fleury's new blog on Blogspot

Not strictly Buni or Meldware related, but related in spirit. CNet and clan are now saying that Marc will leave Red Hat. Meanwhile I've been reading Marcf's new Blogspot blog entitled "Thank God For Internet Porn" (now I will really be deluged with blogspam approval requests). In any case, I wish Marc the best of luck in whatever he decides to do...no matter what he decides to wear while doing it.. He has nearly convinced me to buy a PS3. However, I think I'm going to wait for a few more unique games...

Posted by acoliver at 11:31 PM in Open Source

OSI and General Attribution Provision

I've attempted to heat up the license-discuss list at OSI in order to see a bit more lively debate before advertising licenses are approved. Rick Moen has written a very detailed Linux Gazette article on some of the issues. Once minor nit:

By the way, I mean no disrespect towards Web 2.0 companies generally. In fact, Andrew C. Oliver of Buni.org has, to the great credit of himself and his firm, spoken eloquently against Socialtext et alii's GAP initiative, as clearly contrary to core notions of open source. (Oliver predicts that OSI will approve GAP or some similar mandatory-advertising proposal. I sincerely hope he is mistaken.)

While we haven't launched the firm yet, buni.org is merely an open source community, I'm not sure Bunisoft will be considered Web 2.0 in my mind. A key differentiator is that most of the R&D money of Web 2.0 companies goes into UI leaving you with that unsatisfactory Dorito feeling. Buni is about making groupware that doesn't suck. Not sucking means:

  • Groupware that works on Linux...or whatever your OS may be (some limitations apply)
  • Groupware that lets you achieve SARBOX compliance
  • Groupware software that lets you reuse your existing infrastructure: database, LDAP (including Active Directory), etc
  • Groupware that a mere mortal groups of mere mortals can install, maintain and configure
  • Groupware that scales
  • Open Source groupware
  • A calendar with freebusy
  • Email with NO PST FILES

No weird far-fetched VC-backed ASP model for us. Perhaps that is why it is easy for us to stand up for open source rather than try and expand its meaning to mean software that requires popups and force-fed branding (aka adware) to meet the definition.

Although I know Ken Coar, and Danese Cooper, I was curious who composes the OSI board. Fortunately, it was posted by Matthew Flaschen who also posted this very good summary of some of the issues. While I have considerable respect for Mr. Coar and Mrs. Cooper, as stated I do suspect that OSI will ultimately accommodate the Exhibit-Bers. However, sunlight is the best disinfectant, perhaps more participation from the open source community at large would be in order.

To me one of the most ironic things is that if Meldware were to use one of the "Exhibit B" licenses such as that used by a competitive offering (for our web client), and use the same screen real estate...you could not aggregate code from two pieces of software under the exact same license! We have no plans to do so, Meldware is offered under the LGPL license with liberal policies.

Posted by acoliver at 7:21 AM in Open Source

Tuesday, 2 January 2007

All Hail the Elephant Build

Meldware has a new build which has been called the Elephant Build. Under this build you can do something that you never could do with Meldware before...build it in under a minute. I have to admit something, I fought the Elephant build tooth and nail. I whined about it for like a year before it actually existed. As our codebase grows, our need to manage it grows and our ability to have one src/java and src/flex directory decreases. Our previous build was just a big spaghetti ant script. In fact, I called it the Spaghetti Build.

Simplicity often degrades into stupidity. So now we have a bit more complex file structure, but more productivity...once you get the hang of it (read my many "elephant doesn't work" mails on meldware-dev to see how it took me some time). However, now you can just build the part you're working on... Previously you had a cricket experience every time you wanted to test something. Now while the whole build runs in under a minute on my Duo Core MBP running Linux, the parts compile even faster. Especially useful while working on our upcoming Flex-based administration GUI. So I am growing to begrudgingly love the pachyderm because it is making more more productive (you don't know how it pains me to say that). What newcomers to the development side of the project ask (users don't care how we build our software, only that we do) is "Why is it called Elephant?".

Okay so the project has grown a large lexicon in its relatively young history and pre-history. In part, because of my love of strange phrases and movies which I spring on people, especially our own much abused Hun Ranter, as if they should be fully familiar with them. To understand WHY the build is called Elephant you need to first understand a semi arcane turn of phrase: "White Elephant". A white elephant is a valuable posession that you don't want to give up but that is eating you out of house and home. Legend has it that a Burmese lord that wanted to get you off your land might try a soft approach to driving you out of town by gifting you the sacred creature. You cannot kill the creature because it is sacred, but it is kept at great expense to you and your lands. I doubt the story is true, but its a good story no?

White Elephants in Open Source

In open source, there are many "white elephants". Generally they are "help refactoring the build" into some monstrosity. At first it is a good idea and truly the current build sucks but often the disruption to the project outweighs the productivity gain and the person inevitably leaves the job half done. Then you're stuck taking care of a half broken build. I figured that the "Elephant Build" would be one of these, "White Elephants" that we'd be caring and feeding...

Indeed there are other kinds of white elephants in open source. Often there are code contributions (usually pre-existing code) that seem to really leap-frog the project, but which the presenter doesn't maintain or is no longer available. Thus the project is stuck maintaining something that is a little broken. Worse, such contributions actually discourage BETTER solutions that might have emerged to solve the problem.

The Dirtier Meaning

So the other thing is I tend to make colorful metaphors to describe poor installation or user experiences. One of them was for my installation of gentoo. Basically, installing gentoo is like "receiving" the elephant in the biblical sense. In other words, it is akward and really hurts. Once it is installed it kicks major butt for a server operating system.

In other words...

So in other words, it is a double metaphor for a white elephant and "elephant sex". We use other types of sexual metaphors (boy am I going to get slammed with blog spammers who can't figure out that posts have to be approved to be displayed), monkey sex is inelegant hacking or majick for instance. These metaphors grow more prolific involved and colorful when we're meeting up in Vegas for a conference. It isn't just me anymore, Aron has taken these to a new height and expanded them. The new build may deserve the "elephant sex" metaphor for its learning curve, but once you get there it does make us go faster.

We are really strange...if you are too...maybe you'd like to join us. Maybe the meldware-dev list is a bit much if you're not into exactly the best way to store data and use a 128-bit UUID...but if you're just that way...we may be your crowd. If not, hey, join the forums, you can still play a part.

Posted by acoliver at 10:42 PM in Open Source