Give us a call 203-379-0773
Back our Angular 4 Book on Kickstarter.

I wrote a training course on AngularJS

I know this is a bit different than the Flex content I would usually write about on this blog, but I've spent a lot of the past year putting together a training course that teaches AngularJS to Flex Developers. It is finally available.

The base of this are two books that work together, one builds an application in Flex and the other builds the same application in AngularJS. For me it was a great way to compare and contrast the two technologies; and I'd like to think that approach can also help others.

The main books are available under a pay what you want scheme; but I made a lot of extras available including bonus articles and a full screencast series.

Check out the packages; and choose one that works for you. I'd appreciate the support. You can use the discount code 'flextras' to get a 10% discount.

How does the Apache License affect Flextras?

Way back in 2008, Adobe announced that Flex would be available as an open source project under the Mozilla license. I was wondering how that would affect the work I was doing to create Flextras; and I poured through the license and blogged my interpretation and how things affected me.

Now that Flex is being moved to Apache, new releases of Flex will be through the Apache Foundation and will be available under a brand new license. I thought it made sense for me to go through the Apache license in the same style to review the implications that the license change would on the work I'm doing with Flextras.

The Wikipedia article on the Apache license generally says everything we do w/ Flextras is okay, but I thought it would be beneficial for me to read the legalese myself.

Remember that I am not a lawyer and you should not take anything in this post as legal advice. But, let's see how I interpret everything.

1. Definitions

Definitions are common in legal contracts; they intend to define certain terms and what they relate to. The terms are used throughout the rest of the document. It makes sense to have a common vocabulary, and this is the legal way of defining that. Here are the definitions from the Apache License

  • Licensor: This is, for the most part, the person who submits the code. As initial contributor, it could be me. Or it could be any other Apache contributors.
  • Legal Entity: This part was obviously written by a lawyer. It refers to an "acting entity" but never defines what that is. For all intents and purposes, I believe this here to define what a company is-such as DotComIt-and that the company is different than an individual-Jeffry Houser.
  • You: This is the person (or legal entity, see previous bullet point) that wants to use software/code licensed under this agreement.
  • Source: This refers to modifications made to code under this license.
  • Object: This refers to, in essence, any transformation of the source. I think it is primarily intended for binary compilations (Such as a SWC or SWF), but I believe that ASDocs generated from Apache Flex code could be considered an object under this translation.
  • Work: This refers to the two previous bullet points; either source, or object, made available under this license. I believe this would be a catch all for the Apache Flex SDK along with related documentation.
  • Derivative Works: Derivative works are works that extend or modify the 'work which in turn refers to the source or object. I'm unclear exactly if Flextras components are considered derivative works under this agreement, or not. Flextras components clearly represent an "original work of authorship." But, I'm not sure if Flextras components are "separable from the work". You'd be able to easily use the Apache Flex SDK without using a Flextras component, but would not be able to use a Flextras component without using the Apache Flex SDK. I'm pretty sure that Flextras components fall under derivative works. I'll have to swing this one by a lawyer probably. The documentation that Flextras provides-such as the manuals and release notes-are clearly separable from the work, though and would not be derivative works.
  • Contribution: A Contribution is anything that is intentionally submit to Apache, either through mailing lists or SVN Repositories. I think it's funny they specify intentionally; but in this digital age it is probably easy to submit stuff unintentionally, especially if you include an accidently CC in the email to a dev list.
  • Contributor: This means anyone who submitted code, whether directly or indirectly.
So, a lot of these definitions refer to me, depending on which hat I'm wearing. First, as an initial contributor to Apache Flex, I could a Licensor, which in turn also makes me a contributor. As someone who wants to use Apache Flex code, I could be a "You". And finally, as a company that wants to use Apache Flex code, I could be a "Legal Entity."

Flextras components are a mix of derivative works (our components and sample apps), and non derivative works (our manuals and release notes).

2/3. Grant of Copyright/ Patent License

These sections tell us that anything released under this license can be used, sold, or modified without fear of retribution or IP lawsuits from the people who contributed said IP to Apache.

4. Redistribution

This says you can redistribute the code as long as you provide a copy of the license, document your changes, and retain the source.

The important text that draws my attention is "copies of the Work or Derivative Works...in Source or Object form." It makes me believe Flextras can distribute a compiled version of the Apache Flex SDK (AKA Object form) without distributing the source. Flextras must retain the source, but it does not require us to distribute the source or source for my changes.

In the case of Flextras, we are neither distributing the source nor compiled form of the Adobe Flex SDK, but I believe we are distributing derivative works (and source for those distributed works).

Nothing in this requirement requires that 3rd party companies use the Apache License when distributing the source. A business could use a custom license to release their version of the software. (Flextras has no current plans to do that, BTW).

If my understanding is correct, then there is no issue with what we're doing for Flextras. If I'm wrong about distributing source then this could have implications on our developer editions or single domain editions.

5. Submission of Contributions

This basically says that anything intentionally submitted to Apache can be licensed under the Apache license agreement. I guess if you unintentionally submit something, you can revoke it. If that is not done quickly, I perceive it is a quick way to anger a lot of people.

The interesting clause here is the preface "unless you explicitly state otherwise." That means you can submit stuff to Apache under a different form of license or agreement. I'm unclear what the implications could be of that. If the Apache Flex SDK had some items not licensed under this apache agreement it could potentially place users in an uncomfortable legal position.

6/7/8/ Trademarks, Disclaimers

Standard legalese that means no Licensor (AKA Person who submits the code) is legally responsible for what you do w/ their code.

9. Accepting Warranty or Additional Liability

This means if someone tries to sell support, or code that they got from Apache, they are on your own in meeting the terms of said sale or agreement. This should make sense to most people. If you and I have an agreement, why would some third party (Apache or it's contributors) be responsible?

I assume any business that tries to sell support or source code or what not should have the relevant procedures in place for dealing with their own customers.

What does this all mean?

My takeaways from my day of research are:
  • Flextras components are a mix of derivative works and non-derivative works from what will be the Apache Flex SDK
  • Flextras components are not obligated to be submitted back to Apache even if they are derivative works of Apache Flex.
  • Flextras components are not obligated to be distributed under the Apache license even if they are derivative works of Apache Flex
So, for the moment, Flextras does not have to change anything to support Apache Flex.

Flextras - A Look Back and a Look Forward

A new year is always a great time to look forward and to look back. This is a modified version of January's DotComIt newsletter to discuss the "State of Flextras."

A Look Back

Flextras launched in January 2009 with a single component to our library. I had the five year goal of generating a half a million dollars in yearly sales and employing 5-6 people all focused on building a line of User Interface Flex Components that save Flex Developers time. The success of Flextras could be calculated in many ways, and I thought I'd share some of the metrics we use internally to evaluate our progress.

First, there is our Mailing List. Entering January, there were 239 people on this mailing list; now there are 662. That is a 277% increase in people interested in the stuff we do. We must be doing something right. I'll count that as a success. You can get on our mailing list by registering on our site and opting in.

Next, I take a look at our Developer Edition Downloads. We had 390 downloads of our AutoCompleteComboBox, and 189 of our DataSorter. While we're happy that 390 people are interested in finding out about the stuff we build, not everyone who registers on the site goes on to download a Developer Edition. We'll have to review our process to make sure it is not causing issues. This is a half success.

In a perfect world, Flextras would be releasing 6-12 components a year. That pace requires more than one developer. I was hoping to release four in 2009, but have fallen short. Building a Calendar has turned out to be a lot less trivial than I thought, and I didn't think it would be trivial. But, I've learned a lot and continue to keep moving forward. This is a half success.

Cash Flow is perhaps the most important indicator of the lifeblood of a business. From that perspective, DotComIt has had a rough year. Flextras has only generated 6 paying customers. Sales have been slowly increasing, though. I have a lot of my own thoughts as to why we don't have more sales, but if you want to chime in with yours, I'd love to hear them.

DotComIt brought in some money through other avenues including The Flex Show Pledge Drive, some small consulting projects, and some one-on-one mentoring. Unfortunately, we're still hovering near a $3K loss this year and I haven't taken any salary in ten months. These are fun times that we live in!

A Look Forward

My top priority is going to be finishing up our Calendar Component and getting that available for sale. I believe this is a big hole in the Flex community that is not appropriately filled; and I think I can be the one to fill it. You can watch The Flex Show video series for a good understanding of how we have approached our development of the component.

I expect to start offering some premium support options; and a subscription service where you can get our whole component set for a single price. I'll need to rework our web site to support such things, and may need another lawyer visit. I believe that selling a mix of support and services is one step to reaching our end goal.

I'm also thinking about our first employee. It will have to be funded by sales, but If Flextras can generate 40 sales a month, and keep up the pace consistently for six months, I'll be looking to add my first employee. It sounds like a big goal, but I plan to make that happen this year.

I'm also working on some non-Flextras ventures that should come out sometime this year.

Final Words

I'm sure that we'll have many other adventures in 2010. My own personal year in review is up on my blog now. The Flex Show's review episode will be released on Wednesday January 6th. So, tell me, what can I do to bring you on as a customer in 2010?

How can Adobe Facilitate a Commercial Ecosystem around the Adobe Flash Platform?

Have you heard of Squiggly?

Have you heard of Squiggly yet? Squiggly is a spell checking engine built by Adobe that works with the Flash Player. It is up on the Adobe Labs site and people believe it will end up on the Adobe Open Source site in some form. Grant Skinner, a well known Flash Platform programmer sells his own Spell Checker component. In a few blog posts he questions what Adobe can do to help to encourage a commercial ecosystem around the Flash Platform.

My favorite quote from the two posts is when he refers to commercial components as "highly reliable, documented, and well-supported" when compared to open source offerings. I believe that support is one of the biggest benefits of going with a commercial component vendor.

As someone hoping to thrive in such an ecosystem, I have my own list of thoughts to give to Adobe. At one point Adobe wanted to hear them, but the person who I was supposed to speak to had a job change and the matter eventually went away. This is the advice I would give Adobe to help foster a commercial ecosystem around the Flash Platform.

Help Build Awareness for Commercial Component Vendors

I believe the biggest problem facing Flextras is obscurity. Very few people know we exist. I do not expect Adobe to do my marketing for me. I do not expect Adobe to spend time making Flextras a success. But, I do think they can help with awareness. Here are some things:

  • Tour De Flex: Make it easier for me, as a component vendor, to list new items in Tour De Flex. Make it easy for me to add new components. Make it easy for me to add new samples. Tour De Flex is the single biggest source of traffic for Flextras.
  • Flex.org: I posted our DataSorter component to the Flex.org component showcase in early January. Our AutoCompleteComboBox never showed up on their site when I posted it. When I tried to repost it, the ability to add new components was removed. There was a typo on the DataSorter listing, but no way to edit it. I think it eventually got fixed. Unfortunately, Flex.org is an abandoned wasteland, which is not to Adobe's credit.
  • Blog Aggregators: The podcast page on Flex.org hasn't been updated in over a year. If I submit my blog to feeds.adobe.com the request disappears to the void. These could be two great resources for helping make people aware of my content. Four months when I tried to get the Flextras Friday Lunch added to the podcast page at Flex.org I'm told the site will be updated soon and they aren't taking submissions. Adobe's version of 'soon' is different than mine. We've released 30 Flex Show episodes since the last feed update, so the discrepancy is frustrating.

Given these problems, I would recommend that Adobe give community members a single interface for managing our content on Adobe related sites. I want to go to one place to update my component listings in Tour De Flex, Flex.org, and The Adobe Marketplace. Give me a single submission process, not 3 separate ones that all ask for different information. Give me one place to update my RSS feeds for podcasts or blogs to get into Adobe community aggregators. Let Adobe deal with the work of distributing that content from my one "Edit" place to their appropriate aggregator sites.

Help my Components Integrate with Adobe Tools

The Flash Platform is an ecosystem and Adobe has a lot of tools surrounding it. The Flex Framework integrates nicely with many of these tools, most prominently Flex Builder. How do I make Flextras components integrate with tools just as seamlessly? This is what I would recommend:

  • Design.xml: Document the design.xml and document the manifest.xml file better. These are the files that help you create your own namespace and tweak how code hinting and the design view work for custom components. It would make my job easier, and my customers happier if I were able to make the use of my components as seamless as possible. While I'm asking for documentation on design.xml, how do I bundle my ASDocs into Flex Builder help and activate them when the user presses the F1 key? That'd be sweet!
  • A SWC is not a SWC: There are issues using Flex SWCs in Flash Professiojnal, and vice versa. There are issues using Flex 2 SWCs in Flex 3, and Flex 3 SWCs in Flex 4. Why? Can this problem go away? A SWC is just a zip file, right? What is that internal binary that causes compatibility problems? If I had to guess, II bet it relates to the classes that are, and are not, compiled into the SWC. Can we have a "maximize compatibility" option when compiling a SWC? I know that Photoshop has it for the PSD file format; why not Flex?

I guess you could summarize all my requests by telling Adobe to provide me with tools that can help me be successful with their products. If they do these things it will not only help component developers, but all developers who are working in the Flash Platform Ecosystem.

Comments to Comments

I wrote the above before reading any of the comments on Grant's post. A few interesting things have come up in the comments which I wanted to weigh in on.

  • SWCs need to be protected: A bunch of people claimed that swcs are too easily decompiled and a commercial ecosystem will never spring up while this is the case. I wonder how many of these people have downloaded a song off the Internet, or how about a movie? Have they circumvented DRM on a computer game or other software? Consumers hate DRM! That includes programmers. It angers customers and does not prevent the pirates from stealing your work. I believe a good long-term viable business model will not focus on selling digital bits to people over and over. There needs to be a reason to buy. Premium support is one option. The ability to create more reliable, supported, and documented components is another. I wrote about this stuff in another post.
  • Free Open Source doesn't compete with a Commercial Vendors: Yes they do! But, If that commercial component vendor wants to stick around he better find a way to offer value beyond the functionality in the open source project.
  • Adobe Should build a real Marketplace: The Adobe Marketplace is poorly named since it is a directory, and not a real marketplace where folks can buy and sell goods. Having a marketplace would help many developers get up to market quicker. It took about 2 months to build the Flextras site and I consider it barely functional. The existence of such a marketplace does not make a business, though. You'll still have issues of marketing and sales and support.
  • Adobe Competes With Me: It is Adobe's responsibility to build the platform by talking to customers and filling their needs. If everyone needs / wants it, it is likely this feature will end up in the main platform somehow. I do not believe Adobe should ignore these customer requests because third party vendors exist. If you fill a hole in their ecosystem, especially an obvious hole, you're going to be trumped. With each Flextras component, I consider them a highly specialized use case. But, it seems probable that our AutoCompleteComboBox or CalendarDisplay will be trumped by Adobe at some point.
  • FOSS is killing commercial ecosystems: Adam Lehman made this comment regarding OEM licensed tools inside ColdFusion, and it is an interesting one. As the ColdFusion Product Manager, I give his experience in this more weight than other commenters. CF has slowly been replacing a lot of their OEM licensed tools with open source alternatives, it's true. However, I wonder if those OEM vendors that no longer exist provided value other than selling "digital bits of software"? I believe any company can thrive if they provide value to their customers, and something worth paying for.

If anyone has a component that they think has commercial value; I'd love to talk to you about turning it into a Flextras component. Please Email us and we'd love to talk to you.

What would you like to see Adobe do to help foster an ecosystem around their components?

Unlimited Goods vs Scarce Goods in the Flex Compoment Economy

I read a lot of stuff over a TechDirt and one thing they often talk about is the difference between unlimited goods and scarce goods in the new economy. this often comes up in relation to music and recording artists. Music files, such as mp3s, are digital, and therefore unlimited goods. They cost next to nothing to reproduce and are easily spreadable. DRM is a push to make these digital / unlimited goods scarce, often at the expense of annoying users. If you've ever tried to play an iTunes purchased track on an mp3 player other than an iPod you'll understand why this is a problem.

With Flextras, I struggle to rationalize the digital goods vs scarce goods in my business model. I, in essence, created some DRM to protect the no cost developer editions of our Flex Components that we give out. I don't believe people will pay for just a swc file; there has to be some other benefit. Most companies in this space offer that benefit in the terms of higher access (AKA support) to the Flextras staff (still just me right now). I'm still trying to figure out the best way to make things work. If you have opinions, I'd love to hear them.

Some tweets this morning got me thinking about this. Rich Tretola tweeted that FlashDen was having a competition to create Flex Screencasts. I've never heard of Flash Den before now; and saw the announcement too late anyway. I understand they are a marketplace of sort. We (developers / authors) create something (components / screencasts / articles), and they provide a place to sell it, taking 50% of the cut. The 50% is on a sliding scale, so the more you sell, the more you keep.

Andrew Westberg responded to Rich by saying that their 50% fees seemed pretty steep for just providing a storefront. I've been doing these live Demo Q&A sessions every Friday at 1pm EST. During the first one, one of the attendees asked me if I would open up a marketplace allowing Flex Developers to sell their components to others. It is an interesting idea, but I've put no real thought into it. Would anyone be interested in a way to sell Flex Components like that? I know solutions exist in other communities I've lived in, such cfxtras for the ColdFusion community.

David Bigelow chimed into the conversation and said that FlashDen is diving into an empty pool. If there was a market for this sort of thing, Adobe would be there. From my perspective, as someone diving into the same big empty pool, I think Adobe is already there. Adobe is the exclusive reseller of the ILog Elixir components. I'm not sure how that arrangement came out, but Adobe wouldn't be making that commitment if they didn't think it filled some need. They also have their advanced data visualization package as part of Flex Builder Pro. In the Flex Builder 2 time frame, this package was available separately, but Adobe stopped selling it separately. Perhaps that does not bode well for the current market. Perhaps they just wanted to push people towards Flex Builder.

I believe if you can save developers time by providing them Flex Components that they would have needed to build from scratch, then you're in good shape as a vendor of Flex Compoments.

Then Andrew said there won't be a market until someone finds a way to protect SWC files. I know that sometimes meaning gets lost in the shortness of a tweet, but I am unaware of any market need that was created because of DRM. I'm very interested to see what the folks at Nitro LM come up with in terms of protecting SWCs. However, I don't believe the existence of such protection will create a market. It may create incentive for some developers to create commercial components. But if there is truly a need, some Entrepreneur is going to find a way to fill it, regardless of whether a DRM solution exists.