Atlas: Visual IDE for Cappuccino Applications
280atlas.com
280atlas.com
I admit I'm just as guilty as the next for saying "I won't use X unless its open source" but I really do hope the 280north guys do well with Atlas. As a profession, I think it would be nice if they were able to build great tools and actually, you know, get paid for it.
Case in point is Hibernate--I'm less of a fan of it than I used to be, but the insane number of projects using it for very real higher-productivity/lower-development-cost gains to me means its author, Gaven King, should be very well off right now, not just landing a nice salaried position at JBoss-now-Redhat.
Co-workers and I have occasionally mused about how to help open source developers get income from their work in a non-invasive way. E.g. not having to pin your hopes on being the next SpringSource-type acquisition. Nothing ground breaking yet. Has anyone seen good approaches for this?
What if companies that make money using open source software created an endowment that rewarded developers who produced widely used open source software?
Does the money go to the copyright holder (e.g. the Apache organization for anything org.apache, JBoss/Redhat for anything org.jboss) or the individual developers?
If individuals, how do you partition the money, by LOC, in-project voting/ranking of team member contributions?
- the software's author get money from his work and thus can go on provide good software to people
- only the ones with money needs to pay
- people without money get your product for free... you dont loose money as they wont buy your product anyway and they give you community and adverstissement for free.
http://www.longtailvideo.com/ jw player seems to do well with this schema.
am i missing something ?
The one that makes the most sense, that I've seen, is pretty much what Sun is doing right now. Give the (foundation operating environment) software away for free but charge for the polished chrome and low-response technical support.
It is even more obvious in this case as it is to build web applications, all those applications will have the same 280north look. So trivial to identify any piracy.
selling support is nice but very hard to scale.
Support's easy as sin to scale. Certification programs are a good way to accomplish this; they establish a trust chain and also provide yet another revenue stream to take advantage of.
Maybe your customers would rather purchase a support contract through one of your Certified Professionals® instead for one reason or another. A good use case would be because your customers feel most comfortable dealing with someone who can speak French, but you only provide support in English and German.
You're free to develop apps with their framework for free using your text editor of choice, and if you really want you can write your own IDE and other tools on top of their framework to ease development. However if you want to use their IDE you have to pay.
Lamson and ghostscript have two novel approaches:
Lamson: gpl or paid license without lgpl version
Ghostscript: 6 month delayed OSS release, immediate proprietary license release.
There have been other commercial Java ORM/JPA/JDO/etc. implementations that were quite good (okay, not all of them, but the name of one in particular escapes me) but Hibernate won out because it was free.
That it's primary strength (being LGPL free) also makes it hard to monetize is the conundrum.
I think 280north's price point might be the right idea--anything <$100 (per project, not per seat) should be discretionary income to most any commercial development project and you can make up the low license cost with scale in wide spread adoption.
They should consider going the balsamiq route... ie provide that in-browser/git thingy he talks about in the dev video as a free demo possibly with limitations and with strategically placed upsells. This will allow non-mac people to use the app and provide for a try before you buy. They could of-course charge for this as a product or a service and/or beta charge for it.
I am not a cappuccino or a cappuccino app user at this point. The user base I deal with does seem to react to loading times and loading perceptions quite a bit. The improvements promised by 0.8 mark the first point it seems it could be viable for me to do a mini-app in cappuccino (thanks mainly to the loading related improvements promised). Atlas seems interesting too. Would try if I could.
1. i clicked and failed to find any release. only a video and a mailing list.
2. only a beta will be released and you will have to pay 20$ to get it. To pay to debug their code? the offer is not that compelling.
let hope those are just glitch during the launch
The 280 North guys are the first to admit that CP isn't for every web app, but it serves a specific need exceptionally well. And, personally, I think its' application and adoption will only broaden.
I can't wait to part with my $20! They have to monetise somehow, and if this helps the next year of development - hell, make it $40!
i dunno what the tool worth and i dont plan to pay 20$ to find out if i need this tool.
i dont blame the product, just the moneytisation is broken. Ok to sell a tool, but first convinces potential buyers
We happily admit that a paid beta program is a bit of an experiment, but it's hardly unprecedented. See Mac OS X Public Beta for an example. We do not want to set up the false expectation that Atlas is free. It isn't.
That said, if you wanted to hit the ground running on Monday morning, launching on Sunday allows for the blogosphere to start talking about Atlas on Monday morning.
I can not continue this thread without appearing as a 280n hater and i didnt find a way to reach boucher directly.
Having a paid beta, means that people who haven't used Cappucino probably won't try it and it's a good thing because they would have been harder to support...
"To be fair, I give all the credit in the world to the NeXT guys, but charging $3500 for a microcomputer without a vast application library and that really has no broad adoption is just not worth it."
That said, here's how I see things.
(1) 280 North took a broken environment and tried to apply a not-entirely-broken substrate atop it. Is it going to be slow? Sure, but consider also that Javascript is inherently slow to begin with.
(Slow begets slower, blah blah, I don't want to hear it. I don't care.)
(2) It's a start, and when it comes to 280 North's business practices, I'd be willing to bet that there might very well be a standalone compiler for Objective-J at some point if enough people ask for it.
... if I don't beat them to it first. It's getting close to the point where I'm considering just hacking something together in OCaml to scratch my own itch in this vein.
(3) The 280 North guys are smart guys. They listen. Complain. Send them mail.
We are planning on getting a new compiler in 2010, and it will still do all those things. It will also be more robust, introduce some sorely needed new features, and with any luck be faster to boot.
With respect to point one, I'm not sure anyone commenting in this thread really understands the complexity of optimizing application performance in the browser. On an absolute level, message passing is slower than function calling. But taken in context, that's a small percentage of what happens in an application.
Cappuccino, because its an application framework, can make certain assumptions to dramatically improve performance. Assumptions that can not be made here and there by individual app developers. For example, coalescing DOM updates and drawing events on the run loop. Combining timers together to minimize overhead. Delegating events from the document level to prevent unnecessary build up of event handlers. On the tools front, we can strip some dead code from projects, automate spriting of all app resources, target different code paths to different browsers automatically, and a slew of other things. Performance is complicated.
Is it some MacOS thing?