Making money from this is going to be an uphill battle, especially because getting people to use it is going to be an uphill battle. Looks very cool though.
If it's using node.js (or other JavaScript-based) server-side framework, it could be very useful as a live 'gist' or pastebin. Show/Review the code and see it in operation all in one place. Collections of lots of little scripts.
I'm also thinking of it as a community-based implementation of something like Yahoo YQL, so mashing together several useful datasources and using JavaScript as the glue.
I'd second the recommendation that you have a look at the commonjs stuff that olegp mentions above ( http://news.ycombinator.com/item?id=1262380 ) and seeing if there's an opportunity there to be a prototype / working platform for such an endeavour. (Assuming that there's a good degree of fit between your platform ideas and commonjs)
This is a good start. You should do a better job of selling the idea of the service to developers. Come up with some pain points that Akshell relieves, and use that as the basis for the language on the homepage.
A directory of apps written with Akshell would be more powerful than a screencast or explanation. If you don't have very many users yet, write the applications yourself.
It might be wise to hire or find someone to narrate the screencast.
You're going to have a near impossible time turning this into a business. My suggestion is you open source the whole stack and figure out how to sell it to enterprises for internal application development.
Yes, this does look like an appjet clone. Not to take anything away from this implementation, however, because it looks like the author didnt know of appjet.
Appjet had the same concept: server side js based on rhino, persistent js object store, etc.The concept, however, was a little bit rudimentary: one app consisted of one js "file". You had to write every possible interaction as functions within that file. It did have an interesting function call based templating mechanism, however, something like so:
AppJet open sourced some of their code and JavaScript libraries. They don't seem to be online any more, but if you want them to see whether and how they could be integrated with Akshell, let me know.
This is quite innovative, a javascript appengine if you will. I am not so keen on the enforced sharing, I think separating "library modules" from "user apps" and providing opensource access to the "akshell" engine so folks could host their own, port the db over to google appengine etc. would make this rock. So, is the akshell engine's source open/available now/later??
Currently I don't have plans to opensource the engine. It isn't a noncommercial project; I spent a lot of time on it. What business model would you suggest if I opensource the engine?
In fact, it's impossible to port Akshell database to App Engine. The database system is my pride: Akshell provides a special query language for it, which is based on relational calculus and easily integrates into JavaScript. A relational database couldn't be ported to Big Table.
Akshell features another approach to scalability: each application has an access to a fully functional relational database with transactions, complex queries, etc. Application databases are completely independent; so the whole system has a non-relational database, which should scale well if multiple applications are loaded. You may imagine it as "relativity islands".
1. business lock-in: Having one's whole web business(code/website&data) be hosted by a small startup out of russia(ssor) will be a non-starter for most.
2. code lock-in: Having "code lock-in" for developers, meaning writing to a proprietary code-stack for an ssor will also be a non-starter.
3. scaleability: akshell does not currently provide a clear path to scaleability for any one app let alone the potential of hosting 1000's of apps. This very rapidly becomes a cloud-scaling issue that the ec2, gae's are attempting to solve and will be a non-starter for an ssor .
4. dynamic code sharing - use'ing other libraries within askell might reduce development time, but unless there is a static version of that library associated with each instance, with any change the possibility of breaking the web services makes this a non-starter and everyone would revert to a github like "static code sharing" model.
Here are the pros
1. A custom webhook pipe builder: Say I wanted to build a "dynamic form" get user input, save state (in a db) and run it through a series of dynamically created "webhooks" and process the final output. If akshell provided "an app development api" I could dynamically create an app, generate the code have it hosted and throw the url up for user input and have the user walk-thru various webhook/needed steps to process & generate a final response.
- this is not now possible w/ appengine or ec2
- propietary code/data lock-in is a non-issue since I am not "storing" as much as I am processing.
- leveraging "dynamic community code" would be a pro/ not a con in this case.
- a freemium model would be possible as i'd need free to wade in/ test etc and with load expect to pay a per use fee.
- see some of Jeff Lindsay's webhook related work i.e. webhooks, mailhooks, scriptlets.org etc at http://github.com/progrium for related work
2. A mashup test/use-bed: Web sites with apis could create "canned akshell apps" that not only allowed developers to use("foo-api") to test but also provided examples of use and each web-service could possibly subsidise the hosting / bandwith costs of using their api-apps so developers could just plug-n-play.
3. There are a few more use cases i can think of, you could shoot me an email if interested.
Thank you for your comprehensive reply. I definitely agree that now Akshell doesn't suite mission-critical applications. And I think it will never suite bank applications or such. But I think that it has a rather big niche.
This looks very cool, but there's no way in the world that I'll actually create anything on the platform if there is no way to run apps on my own server or locally. I have a feeling that this won't go anywhere unless you use completely open technologies (and frameworks, middleware, etc) or you open source Akshell itself.
This is what happen when you first open your app the public, you get feedback that may not line up with you primary vision. I found these primary feedbacks invaluable because it tells you that your product is not doing exactly what people want, you learn from it and shift direction. Your idea is very good and well executed, you should minimize the trust factor by making it less social based ; make it possible for someone to take his code away from your platform.
Thank you! In fact, moving code away from Akshell should be possible. All libraries and utilities are BSD-licensed, one only have to clone the core to run Akshell applications.
Cloning the core doesn't sound simple (even if it is).
Making it easy to move away lowers the potential cost of using Akshell - I really don't want to be locked in. How about open sourcing whatever is needed to run an app on your own server and then working on keeping customers through convenience and the interoperability between apps?
May be I'll take this way. But now it's too early do decide. At least because currently Akshell doesn't have many users and applications; so if I opensource the core, anybody would be able to setup an absolutely equivalent server.
Sure - you'll need to take a bit of a wait and see approach, but personally I'm hesitant to build anything at this point. If I wanted to build something serious on it I'd be relying on you to stay in business...
And when I suggest open sourcing I am thinking in terms of the bare minimum to setup an app on another server - so your very cool editing system wouldn't need to be part of it, that would be what makes you different from anyone else who sets up their own server.
Well, the edition system isn't mine; it's EditArea, a free client-side JS library by Christophe Dolivet. But opensourcing a part of Akshell may be a good idea. I should think about it. Thank you.
You should make this into a Django app that people can plugin to their admin interfaces. It would be a great tool for on the fly code development, bug fixes, etc.
I like the idea of a constellation of small applications but I cannot envisage how it work. If you have written an app (library) that I want to use, I use it directly, or I can clone it.
The former requires that I trust you completely and permanently and is therefore not likely to happen in serious contexts. The latter requires a round-trip through my VCS anyway, so what benefit does this feature bring over e.g. Github?
The Akshell is all about the former way. The idea is the following: I administrate basic utilities and libraries and you trust me because you use Akshell. These applications are free, they have public repositories at http://bitbucket.org/akshell/; so the development is driven by the community and is beneficial for everyone. I am responsible for consistency, stability, etc.
The resulting environment is easy for development, is formed by a community, and is stable.
Other developers could gain an authority and authour such applications as well. In future, they will be able to make money on it.
The cloning is a good way for libraries, but in Akshell you could create utilities as well. It's easy to explain by an example: in the profile application users save their profiles; other applications could access them. Cloning the profile code is senseless, because its data matter.
Looks like a great way to shorten the edit-run cycle, but my first question would be: where is my source? More specifically, is Akshell storing it in some kind of version control? Is there any possibile way to take it offline, and edit it on my local machine (still in my browser)?
akshell put your-app -e "test()" # send changes and run the test() function
It can be integrated into an IDE (I use it from Emacs). But it isn't a substitution for a version control, which wouldn't be handy here because of short put cycles.
The authentication functionality demoed in the screen cast is cool - but looking at the notebook app it seems that it is a Akshell branded system. Are you going to offer customisation of that?
Except how many developers want a random (to the user) shared login? I'm doubtful that logging into a non-Google site with a Google account or using Facebook Connect is yet a standard user experience. The way I see it, this could just confuse users.
Why not provide a login system specific to each app?
I actually think a common login across all Akshell apps is what will make this superior to AppEngine, AppJet etc. Also, it would be good if there was a per user data store in addition to a per application one.
A specific for application login system can be implemented as a library in a few lines of code. But using it will prevent an application from benefiting from the Akshell environment.
Thank you. In fact the s3 library is not ready yet :) Currenly the most live application is blog: http://blog.akshell.com/, but I launched the public beta only 30 minutes ago...
2. Applications can interact, i.e., your app can use the log app for logging, the profile app for accessing user profiles, etc. So each app does only one thing, but does it well. It can be imagined as a social network, whose logic and content is formed entirely by users.
