Lock-in is a concern to many developers, and is a risk with many platforms. The team at Bungee Labs are well aware of the concern, and plan to take steps over both the short and long term to address the concern. Our goal is to keep developers on Bungee Connect by providing a platform that developers love to use, not by way of technology lock-ins.

Concern about lock-in generally falls in three areas: hosting choices (your place or ours), ability to export your code from Bungee Connect and run it on other systems, the openness of the Bungee Connect infrastructure. I briefly address each in a separate paragraph below.

With regard to hosting choices, we are investigating several approaches, to address three different scenarios: i) federating with third party hosting centers, giving developers a choice of providers; ii) providing dedicated managed servers at federated centers, as well as through Bungee Labs, and iii) providing a run-time version of Bungee Connect server host to allow developers to host their own applications. We have not worked out delivery timeframes for these yet, but they are definitely on our list.

Regarding code export, you can already export your application logic (pseudo-code, effectively) today. Before Bungee Connect goes from beta to general availability, we plan to refine the conventions for how code is represented within Bungee Connect, and allow you to export that code in tact.

The final topic deals in the openness of the Bungee Connect infrastructure. Bungee Connect relies upon a vast assortment of open standards and Free Software, and the team at Bungee Labs needs no convincing of the value of both. However, Bungee Connect’s most powerful capabilities are the product of inventing new software development and delivery methodologies for which standards do not yet exist. For this same reason, we have not started to open source the platform yet: we are still actively refining and optimizing the system. To open source parts of the platform before we have better refined the code–and, equally important, before there is any demand for opening it–would serve little except to have yet another start-up declaring a grandiose open source vision. To put source code out into world before that code has been properly prepared for actual use, extension, and maintenance by third-parties would be code dumping, and doesn’t serve anyone’s interest.

Please see our FAQ (http://www.bungeeconnect.com/?bl_link=FAQ) for answers to many similar questions.

Ted Haeger
Director, Bungee Connect Developer Network
Bungee Labs

I found your entry interesting do I’ve added a Trackback to it on my weblog :)…

So fair enough on wanting to build a language better suited to the on-demand development environment you’ve created. I just think that’s a tough sale for a lot of people.

For me as a dev I’ve spent years building up knowledge in my development language/environment of choice (C#/C++/.NET) and, while I don’t mind the idea of moving from VS to something like Bungee Connect, my preference would be to take as much of that knowledge with me as I can.

I half expected your language to be PHP, Ruby, or Java centric but when I saw it was something completely new visions of PowerBuilder & Delphi started dancing through me head. Knowing those two languages will never again help me as a dev. And my concern is that Learning Bungee Logic could be learning yet another PowerBuilder.

My preference would obviously be for an ASPX flavored language but if it was PHP or Java based I might be at least a little more compelled to give it a go because I know those are skills that can and probably help me out in my programming endevors beyond Bungee Connect.

Given that your target audience is developers this seems to me like it could be a very big hurdle for you guys to get over. Good luck though because I think they’re are some awesome things that are possible with this kind of approach to web development!

-steve

Unlike many of the johnny come lately widget dev sights, Bungee has been in development for a while now, starting long before the rise of the widget fad. The foresight of the Bungee team is proven by the depth to which they have built out their product. It’s clearly well thought out, well built, and undoubtedly has a clever and innovative roadmap of enhancements far into the future.

This is a product and company to closely watch IMHO. I expect great things. Congrats on your launch.

The other topic - the one you’re referring to is the JavaScript library sent to the broswer (called Pulse). I agree re: the general point on JSON. When we have talked with you previously (by phone) re: standardizing the js library, I believe we communicated to you our intention to reviewing Open Ajax as one of a number of options we would consider *when the time is right for Bungee Labs*. Right now, we’ve got a whole bunch of other critical items we have to nail before we commit to efforts like standards bodies and to do so the “right” way, not just as a checkbox item. So again, watch this space.

@LiquidSilver - if you sign up for a Bungee Connect, you should get a feel for why Bungee Logic is the way it is through our learning content. At the fundamental level, it is an enabler of the kind of web apps we think could and should be built for end user. (see the WideLens reference app as an example. But I acknowledge you meta-point here. Thanks for clarifying.

although i use asp.net, i am very tempted to use bungee logic as well. but for now, without the rationale behind bungee logic being unveiled. it would be hard for developers to measure what can be done and cannot be done with bungee logic and have a clear picture on what type of advantage bungee logic has over asp.net/php and others. hope this has clarify a bit for you.

FAIL.

On: “reluctant to adapt to bungee logic because they do not have the future vision of the framework as you do.” - yup, we’ve got that feedback from some of our developers and it is legit concern. The challenge for us at Bungee is to provide real technical solutions to this issue. What we’d love is to let devs bring along their existing language knowledge and apply that within Bungee Connect - this isn’t a trivial CS challenge but we know it can be done. There are other avenues we’re investigating to deal with this, and really hope to share news on this soon that will remove this objection / concern entirely. The bottom line for the moment is: given what Bungee Connect lets you do that you can’t on other platforms (or at least without an *enormous* amount of heavy lifting required by the dev) is that it becomes a cost / benefit analysis for the dev: is the juice with the squeeze?…the feedback we’re getting from devs who grok the power of Bungee are telling us: yes.

On the the second issue, I’m not really sure what you mean - am happy to respond if you rephrase (sorry…I’m slow this morning…lack of sleep for me recently!).

When I tried to view the page right in Akregator (->Konqueror browser) I just got a note saying I should use one of their supported browsers (among them Firefox).

So I switched to Firefox. And got a blank page… I guessed it was because of JS and allowed bungeelabs.com. I got a grayed page with no reaction to any clicks, so I allowed bungeegrid.com as well, and finally it worked.

This was annoying. I suggest they at least tell their users they have to use JS to view their start page.

what about a development environment, built on top of eclipse, or something like that, that offers a traditional IDE for java/c/whatever as a service?

THAT could be useful, for collaborative programming, but i guess it would be hard to do technically

But seriously, I would only start to consider relying on this kind of platform if I a) can take the runtime environment and deploy it anywhere without having to rely on Bungee, and b) would have the stand-alone tools to continue development offline.

And personally, I would like all of that to be open source. The current concept makes Microsofts’ vendor lock-in practices look benign.