Read the parent comment. I was replying to the specific statement that one cannot download apps onto the device other than through the App Store, not addressing whether it is useful or not as a channel to distribute apps.
As to your other points, sign up for the Enterprise program.
Read the parent comment. I was replying to the specific statement that one cannot download apps onto the device other than through the App Store, not addressing whether it is useful or not as a channel to distribute apps.
I can get out and push my car, but that doesn't make it a hybrid.
As to your other points, sign up for the Enterprise program.
The enterprise program does not allow for external distribution and is not useful (or even permitted) outside of large enterprise organizations.
People are used to more, and we need to do it with less time. They don't want to wait for loading screens, they want to load their smoothly scrolling images over the WiFi on-demand from Flickr while performing high quality interpolation to produce the thumbnails.
They want to rotate the device to CoverFlow, and we'll have to load all those images as GL textures and pay the CPU hit for rendering the text labels as they rapidly scroll through their caturday pictures, all the while downloading and caching images in the background to provide a seamless and smooth user experience.
I can't add loading screens (so I have time to preload/pre-render), or restrict my data accesses to loading to optimized textures I have on disk, or spend months (years?) working on optimizing out every CPU cycle. That's not what people want.
So yes, for the things people expect from our applications, we're up against serious resource limits.
As someone with a mildly neglected (but understanding) wife and and an on-hold personal life, I couldn't disagree with your comment more -- but it's also not what the article said. The article said:
[Your] business is rarely so fragile that it can not suffer some minor neglect _now and again_.
Emphasis on now and again. You will have to put your personal and family life on hold, but you'll also need to figure out how to maintain your relationships while you do it.
Starting a company requires a tremendous amount of work, and I've regularly had to choose between what I want (a relaxing dinner out with my wife) and what I need to get done to maximize our chances of scaling to the next stable plateau (a contract, the next product feature, etc).
If you're not ready to put everything on hold and work your ass off, then starting a company is probably not the right choice for you.
There's nothing about the GPL that says you can't sell your product.
I wish this tired GPL counterpoint would be put to rest. If you provide the source code for your software, someone else will compile it and distribute a binary legally and for free.
That -- without any shadow of a doubt -- hurts sales (even if you "highly doubt it").
RedHat sells services, not software. That's why they can afford for CentOS to keep doing what they do.
I wish this tired GPL counterpoint would be put to rest. If you provide the source code for your software, someone else will compile it and distribute a binary legally and for free.
My entire point is that this isn't true. The aforementioned game released its source code--and nobody cared.
The GPL applies to code only--nothing else. If a game's source code is GPL, that doesn't give anyone permission to legally distribute the game--all the art and assets are still not GPL'd, only the binaries are. I don't see how one could possibly sanely think that I would find a copy of, say, Civilization 4 without models, textures, and sound to be useful.
And companies vastly overvalue their source code. They assume that since they spent $1m developing something that the source is worth $1m, when in reality there's probably nobody in the world who would pay a cent for their crappy code.
And you'd have to release it under that same license (or a GPL compliant license), which means that anybody can do the same thing to you. If you improved the engine in some way, there's nothing stopping the makers of the original game to take your improved version, bundle some resources with it (sound, graphics) and release a new and improved version of their game.
Which means that the original corporation won't participate (unless forced to by accidentally including GPL'd code) because there are a lot of very good reasons for a corporation to not share their source code (ie, competitive advantage), and we've come full circle.
I wish this tired GPL counterpoint would be put to rest. If you provide the source code for your software, someone else will compile it and distribute a binary legally and for free.
FWIW, I contribute to an app that has been on the App Store for ~10 months now, been in the top 100 for its category since release and is open source (under a BSD license). We've had several people tell us that someone could do this very thing - compile the app and post it online for free - but it hasn't been done yet.
Of course, the app has been cracked and placed on other sites (and its technically legal since binary modifications/redistributions are allowed). But thats a different issue.
FWIW, I contribute to an app that has been on the App Store for ~10 months now, been in the top 100 for its category since release and is open source (under a BSD license). We've had several people tell us that someone could do this very thing - compile the app and post it online for free - but it hasn't been done yet.
That would be because:
- The copied app (unlike on the free internet) couldn't be called "Colloquy" (or reference Colloquy in its tags) because Apple would forbid its distribution, and so discoverability is significantly reduced.
- It costs $99 to acquire an appstore developer certificate to work with Apple's DRM, reducing the chances of opportunistic behavior on behalf of users. I can't just check out your project and put it online.
Of course, the app has been cracked and placed on other sites (and its technically legal since binary modifications/redistributions are allowed). But thats a different issue.
Is it really a different issue? It seems like the only thing protecting you from unrestricted copying is Apple's DRM and control over the AppStore.
The copied app (unlike on the free internet) couldn't be called "Colloquy" (or reference Colloquy in its tags) because Apple would forbid its distribution, and so discoverability is significantly reduced.
Sadly, not completely true. It couldn't be called colloquy, but the I last time I looked (admittedly, a month or two ago,) two of the competing IRC clients in the app store mention Colloquy by name in their description and one of them also has "Colloquy" as one of their search terms.
Is it really a different issue? It seems like the only thing protecting you from unrestricted copying is Apple's DRM and control over the AppStore.
I don't see the difference between Apple creating some semblance of DRM in the app and developers having to do so on their own. A cracked app is a cracked app, regardless of the protection that was cracked.
One of the things that I love about the App Store is that I don't have to deal with keeping track serials. I buy the app, and it just works. If (when?) Apple were to allow people to put apps on their device without going through the App Store, serials may then become an issue.
There is a very simple solution to getting your stuff to run on many linux distros without too much trouble: static linking.
That's not simple at all. If I want to integrate properly with your desktop, do I write my code against gnome or KDE?
If I statically link against an older (or newer) version of gnome or KDE, will it even interoperate correctly with whatever the user has running on their desktop?
If there's a security vulnerability in what should be a base system library, does every single vendor have to track those issues and release updates to their applications?
No. The right way to support binary compatibility is to define a compatible, stable API and ABI and then support that ABI/API across OS releases and updates.
> The right way to support binary compatibility is to define a compatible, stable API and ABI and then support that ABI/API across OS releases and updates.
With that I fully agree. But I think if the last decade is any indication that in the linux world we are still at least a decade away from achieving that, even though there are plenty of efforts in that direction.
Less than $1000? For any per-seat pricing that nears $1k, Atlas needs be so much better than the current tools that it'll shoot sunshine and rainbows out of our asses while we're using it.
Investing in Atlas is making a heavy investment in technology solely provided by yourselves: Obj-J and Cappuccino. The foundation being open source may alleviate some concern there, but to do so, the open source foundation will need to be of sufficient quality and usefulness that we feel we can work without your IDE in the future.
I'm also VERY surprised that you're charging for an expiring beta. Doing so will greatly limit user exposure, and I'm pretty uncomfortable with paying for the privilege of testing your software.
You're not Apple -- developers don't need to pay for the ability to test/update their software for an upcoming OS release.
Well, it's as unlikely to cost $1000 as it is to cost $20. That being said, Atlas is completely optional. Everything built with Cappuccino to date did NOT use Atlas. And this will always be a viable option.
This beta is not intended to get large exposure. It's intended to get a group of people who we are confident will be dedicated to helping us make Atlas a better product.
Well, it's as unlikely to cost $1000 as it is to cost $20. That being said, Atlas is completely optional. Everything built with Cappuccino to date did NOT use Atlas. And this will always be a viable option.
You wouldn't be the first company to start with these intentions, only to eventually widen the open source/commercial split, where features never reach the open source edition. It's a possibility, however remote you might consider it, that we have to anticipate and plan for.
If the tools save time and money, we'll buy it, but we also have to consider potential lock-in costs a very real part of the price.
This beta is not intended to get large exposure. It's intended to get a group of people who we are confident will be dedicated to helping us make Atlas a better product.
If we're supposed to be helping you, it seems inappropriate to charge.
If you feel it's inappropriate, please don't pay. We feel that we're providing something that a certain group of people want at a very reasonable price. If you don't think it's a fair trade, we'd rather have you wait until the final version to re-evaluate the product. Thanks.
You're right, I don't think it's a fair trade -- I'm not going to pay money to beta test your admittedly unstable, rough-hewn software.
I'm not telling you this to be offensive. I'm doing so because it's clear you're alienating people who would both test and evangelize, and I think that's an unfortunate waste for a product I think has great potential (but is much, much too veiled in secrecy and a general lack of public information).
If you think the opinion isn't valuable, you're also just as free to ignore it as you see fit (... but given that I've contributed patches to Cappuccino in the past, I'm pretty surprised you don't think I'm in your 'target audience' just because I'm not excited to pay $20 AND test your software for free.)
boucher seems to be running into some pretty stiff resistance here, and I totally get it. That said, I opted to pay for the beta. While it probably should have been marketed as an alpha instead, it was worth much more than $20. Really, many people probably blow more than that on coffee in day. The Atlas alpha/beta appears likely to provide me with more value than an afternoon's worth of coffee, so I subscribed.
If doing that doesn't float your boat, then working with rough, buggy, pre-release software that may never love you back probably isn't going to be your thing either. Then you're out $20 and wish you'd bought the coffee. For their intended market, I think this program was priced right.
I can see charging a modest amount for a beta program. If it were totally free, you'd get sign-ups from any random person who has the slightest curiosity in the product, and any feedback you get from such folks is likely to be next to useless. By charging for the beta, even just $20, you weed out this chaff, and also your beta testers now have some sense of investment in the product and will be more likely to give you feedback you can act on.
But aren't you punishing your target audience by making them pay money, no matter the amount, so you can "weed out the chaff?" If that is their motivation, I don't like it.
Like you, I'm concerned for the future of Cappuccino. I realize that 280 North has to make rent somehow, but dividing the platform into a free software component and a commercial proprietary component necessarily gives them incentive to focus on the proprietary component more. This is the sort of thing that can prevent the platform from ever gaining critical mass among developers.
Yes -- Apple makes direct review contacts available to larger companies, permits them to break certain portions of the SDK agreement, and provides assistance and status information while navigating the (much more friendly) review process.
They also provide leg-ups by negotiating feature of their applications, etc.
Maybe a bunch of the smaller app developers need to get together and form a large umbrella organization (that they are all share holders in) to get the better treatment.
To those apologists who said Apple couldn't fix this issue rapidly if they were sufficiently motivated by negative press or otherwise -- you were wrong.
It took many months, but something finally motived Apple to move.
Only if you're aware that the virus is running, and it doesn't do something disastrous in the meantime (eg, sniff your keystrokes while you enter a bank account number or log into the hospital records system).
1) Share your unique device identifier with the developer.
2) The developer registers that device ID with Apple. Only 100 devices per developer may be registered in one year.
3) Apple signs a signing certificate which includes that device ID.
4) The developer signs the application binary with their private key and includes the Apple-signed certificate with the binary.
This is absolutely not useful for anything other than beta testing.