Sandbox Block
Permalink
If Concrete5 had a way to do a free trial period for paid blocks, customers would be able to see how the blocks actually look and work on their own site!
I had a brain storm on how this might work.
A Sandbox block!
1. A developer subscribes to the sandbox service and identifies their block, and the free trial parameters
2. Other sites (customers) would need to install the sandbox block
3. Configuring the sandbox would require the database server name and password
4. They could then add any paid block to their sandbox (for free)
5. The actual (paid) block would be downloaded and hosted on a remote server so it's source code can't be accessed
6. The customer would see all the features of the block as if it were being hosted on their own site.
7. When the time period expires, the sandbox block displays "Trail Period Expired" and instructs the customer how to purchase the block
Many of the details still need to be clarified. but this gives you a good idea.
I had a brain storm on how this might work.
A Sandbox block!
1. A developer subscribes to the sandbox service and identifies their block, and the free trial parameters
2. Other sites (customers) would need to install the sandbox block
3. Configuring the sandbox would require the database server name and password
4. They could then add any paid block to their sandbox (for free)
5. The actual (paid) block would be downloaded and hosted on a remote server so it's source code can't be accessed
6. The customer would see all the features of the block as if it were being hosted on their own site.
7. When the time period expires, the sandbox block displays "Trail Period Expired" and instructs the customer how to purchase the block
Many of the details still need to be clarified. but this gives you a good idea.
a lot of addons and themes have demos. For addons they genereally reset every hour and the user can login to them to edit them, for themes thats generally not necessary. Is that what you want, or am i misinterpreting you?
A demo site is not the same at all. Especially with the more expensive blocks which are deeply integrated to your site. You could have data that needs to interact with the block, or you want to see how it looks or interacts with other blocks and themes on your site. You can't do that when its on a demo site.
Also, because every minute you spend on a demo site is lost, you never take the time to "own" it, and try to make it work for you.
If you see a block that's $50+, you might just pass it buy and keep looking for a cheaper one. But if you install a $50 block for free... take the time to configure, integrate it, make it work on your site, and really see how awesome the more expensive blocks can be for your site... your more likely to buy it.
Also, because every minute you spend on a demo site is lost, you never take the time to "own" it, and try to make it work for you.
If you see a block that's $50+, you might just pass it buy and keep looking for a cheaper one. But if you install a $50 block for free... take the time to configure, integrate it, make it work on your site, and really see how awesome the more expensive blocks can be for your site... your more likely to buy it.
It really isn't possible (that I know of) to have a demo block and a paid for block without maintaining two codebases at once, and even then it so weird to even think about how one would accomplish it. I mean I know how I would, but I really think time would be better spent in better demos.
If the demo isn't quite exactly what you need, you can always email the developers of the block/package and they can custom tailor something for you, I know I will :). I often modify other people's marketplace items for additional functionality.
-Scott
If the demo isn't quite exactly what you need, you can always email the developers of the block/package and they can custom tailor something for you, I know I will :). I often modify other people's marketplace items for additional functionality.
-Scott
I can tell you that is not going to happen,
Enforcing the 1 License per Site is hard enough, and that would just make it a lot easier to pirate.
Just ask Developers to setup a demo site if they don't have one already,
Enforcing the 1 License per Site is hard enough, and that would just make it a lot easier to pirate.
Just ask Developers to setup a demo site if they don't have one already,
Come on guys, use your imagination! The 1st rule of brain storming is the NOT discount ideas. The Sandbox block would simply point to external web server where the block is actually hosted. The external web server would only need to know how to access your database. This concept is not new and happens all the time.
The developer would only need to know the sand box server is trustworthy. If we can't get Concrete to host it. I'm sure a third party would do it.
If it's a cost issue. I don't see why it could not be a fee-based service. where fees are charged to the customer only if they buy the block. demoing should be free or what's the point?
The developer would only need to know the sand box server is trustworthy. If we can't get Concrete to host it. I'm sure a third party would do it.
If it's a cost issue. I don't see why it could not be a fee-based service. where fees are charged to the customer only if they buy the block. demoing should be free or what's the point?
So the People that actually buy it get hurt, but not the people that just demo it. Good luck with that. Frankly, I don't see what's wrong with demos- sure an hour might be quick. But that's still plenty of time- the idea is to let people know if they want to buy it or not, not to let them add all their images of aunt Suzy- you have to buy the block to see it.
Guys! If you're debating over a block and you were able to actually install it, and make it work on your own site... you would be much more apt to buy it. how is that so hard to understand?
As for the Sandbox fee - that was optional and has nothing to do with the concept of how it could work. There are lots of was to charge fees - if that's the way to go.
As for the Sandbox fee - that was optional and has nothing to do with the concept of how it could work. There are lots of was to charge fees - if that's the way to go.
the problem is that is your own site- if you stop the expire date from being sent through some code then you could use it indefinitely, or if the blocks expiration doesn't work, etc... you could get a free 100 buck block- Its a good idea, but it'd be REALLY hard to make it work- and devs wouldn't trust it, they want to get paid.
What about a Karma based system... I'd love to "checkout" some blocks, and based on my Karma, I'd be allowed to try it before buying it.
I know I've wanted to pitch the block to bosses, or demo to a client, or proof of concept a block before I can get the approval to actually spend the cash. no big deal on $20, but on $125 it's a different story. Just hard to justify the hard expense on R & D.
I know I've wanted to pitch the block to bosses, or demo to a client, or proof of concept a block before I can get the approval to actually spend the cash. no big deal on $20, but on $125 it's a different story. Just hard to justify the hard expense on R & D.
The expiration date is not controlled by the client... it would be on the server which hosts the paid block.
yea... but if you own the server/hosting account then you can just download the block via ftp,
Its not going to happen, you can ask developers to setup demo sites,
find another place that does this sandbox thing, (that is open source)
Its not going to happen, you can ask developers to setup demo sites,
find another place that does this sandbox thing, (that is open source)
or curl, or any number of ways, its not secure and is almost impossible to make secure
Dude, its a web server hosting PHP files. the customer would NOT have access to the source files. Why would you give the customer FTP rights to the sandbox? The developer would need to upload their block to the sandbox to make it available to customers.
In order for concrete5 to be able to use the block it NEEDS the source files, and if c5 can get them so can a human,
The external web server would host the PHP files and point to the customer's database. the Snadbox block would only contain only the html, css and javascript which is passed from the sandbox server.
how would you edit the block then?
The sandbox block you post back to the sandbox server allowing you to see and interact with all the content
ok, so your saying that each block would have to have its own sandbox block?...
In the dashboard, you would need a Sandbox page which listed all the dashboard blocks assigned to you on the sandboxes server. You would be able to click any one of them and open the dashboard page which is being redisplayed from the sandbox server.
In your website, you would add a Sandbox block. When you edit the sandbox block, you would be able to pick which block it points to in your sandbox... which is a list of available blocks on the sandbox server.
In your website, you would add a Sandbox block. When you edit the sandbox block, you would be able to pick which block it points to in your sandbox... which is a list of available blocks on the sandbox server.
ok, that makes sense, users would have to authenticate also, and in what way would this be cost effective for the core team? or a single developer?
I did not want to spend $150 on a block, so I passed it by (SEVERAL TIMES). The demo site just did not show me how well it would work with my site. Months later, I now own the block and think it's awesome! Had I been able to install the free block and the $ block on my site... I would have clearly purchased the $ block in the beginning and not waisted my time.
Who is the core team?
I think developers would be able to sell blocks at a higher cost, because the price would not scare people away as easily.
The customer would be able to know exactly what they're buying and how it works on their site. It would be MUCH easier to demo it to the client and get approval to purchase the block.
Who is the core team?
I think developers would be able to sell blocks at a higher cost, because the price would not scare people away as easily.
The customer would be able to know exactly what they're buying and how it works on their site. It would be MUCH easier to demo it to the client and get approval to purchase the block.
i understand that it makes it easier to demo, but its still the devs decision,
The core team is the company that develops concrete5, and several addons,
it wouldn't be cost effective for anyone to make this, especially with security issues, bugs, etc
The core team is the company that develops concrete5, and several addons,
it wouldn't be cost effective for anyone to make this, especially with security issues, bugs, etc
just wondering, if you bought the addon would you be able to port data over as well? that could get time consuming for the dev, and im not sure how you'd manage it.
The data would not need to be ported over... it already lives in the customer's database. The Sandbox server would only host the PHP files and direct the data to go to the customer's database
hmmm. but then what would stop the customer from copying the html and java from when they get it working and then just using that manually? 1 hour isn't really enought to do that, but a couple days and they might not want to change it.
if the block only has HTML and javesacript, the customer could take the code weather it is in a demo area or a sandbox. This type of code cannot be protected no matter what you do. This would protect the PHP code.
I honestly think if Concrete5 is going to be a free CMS and money is made from the sale of blocks... this sandbox idea should be built into the core Concrete5 system.
But even if that never happens, I can see it being done by a 3rd party.
But even if that never happens, I can see it being done by a 3rd party.
rockface --
I (think) I see what you're getting at. But, as a developer, I'm just not sure how feasible it is. As much as I like these kinds of challenges, and this would be pretty fun.
The easiest would be have a bunch of stub files on your server that do something like. But, PHP would be expecting to find PHP code at that remote location... And, as mnkras said, if a computer can get it, so can a human....
So the next level down would be to extract stubs of each method. For a class of 5 properties and 5 methods, the service would create a small file with 5 properties and 5 methods, each of which takes the request (and possibly arguments), serializes everything, and sends it off to a script on the server (NOT the actual package source code), which would be responsible for unserializing, including the appropriate files, executing the code, taking the return, serializing, sending back to the stub, then having the stub unserialize and return. In theory, this sounds pretty straightforward, but:
1. Obvious potential for latency.
2. I'm not super familiar with serialize(), but I don't think it can handle all datatypes (ie, the custom classes which would be necessary). And I'm not sure how it'd handle when somebody decides to store $db inside their class, or some other such "oddity".
3. I can predict some problems with parent classes, etc, but can't put my finger on them.
4. Commercial value of such a service will depend largely on convincing other developers to sign up with you.
5. Lots of problems with the data. Most add-ons have to access your users, pages, etc. You mentioned a db username and password. Are you talking about giving the demo site your db credentials? I think a lot of people would have problems with a remote service accessing their database over the internet. Plus, will the demo service install the package's tables within your database? Or will it store those tables locally, while accessing your tables remotely? Either way, it's messy.
All the db issues associated with #5 got me thinking... instead of having the package data in your db, why not have your data in the c5sandbox.com db? And if you're doing that, then why bother with all this back-and-forth, why not run everything from the sandbox site? Basically what we're talking about would be a service where you sign up for a sandbox, push your current site (custom files & db) to, then install an add-on from a list. This site would be locked down so you couldn't access FTP, etc.
It's an interesting idea, and I'd probably support (though maybe not pay) for it as a package developer. I'd be tempted to hack together a proof of concept, but I don't want to reinvent the wheel, and about 60% of the difficulty, and 90% of the unfun work is creating a 'click here to create a sandbox that we'll keep up for 3 days then delete, unless you pay us more...' which has already been done. (Another 30% is creating the sandbox package, which would actually be a migration package to send your data and files to the server. Another 10% to provide a library of packages and lock that down sufficiently. Oh... and another 10 to 15% for the backend for package developers.
Also, there's source compilation/encryption/etc, but I'm not familiar enough with doing that in PHP.
I (think) I see what you're getting at. But, as a developer, I'm just not sure how feasible it is. As much as I like these kinds of challenges, and this would be pretty fun.
The easiest would be have a bunch of stub files on your server that do something like
include('http://www.c5demos.com/...');
So the next level down would be to extract stubs of each method. For a class of 5 properties and 5 methods, the service would create a small file with 5 properties and 5 methods, each of which takes the request (and possibly arguments), serializes everything, and sends it off to a script on the server (NOT the actual package source code), which would be responsible for unserializing, including the appropriate files, executing the code, taking the return, serializing, sending back to the stub, then having the stub unserialize and return. In theory, this sounds pretty straightforward, but:
1. Obvious potential for latency.
2. I'm not super familiar with serialize(), but I don't think it can handle all datatypes (ie, the custom classes which would be necessary). And I'm not sure how it'd handle when somebody decides to store $db inside their class, or some other such "oddity".
3. I can predict some problems with parent classes, etc, but can't put my finger on them.
4. Commercial value of such a service will depend largely on convincing other developers to sign up with you.
5. Lots of problems with the data. Most add-ons have to access your users, pages, etc. You mentioned a db username and password. Are you talking about giving the demo site your db credentials? I think a lot of people would have problems with a remote service accessing their database over the internet. Plus, will the demo service install the package's tables within your database? Or will it store those tables locally, while accessing your tables remotely? Either way, it's messy.
All the db issues associated with #5 got me thinking... instead of having the package data in your db, why not have your data in the c5sandbox.com db? And if you're doing that, then why bother with all this back-and-forth, why not run everything from the sandbox site? Basically what we're talking about would be a service where you sign up for a sandbox, push your current site (custom files & db) to, then install an add-on from a list. This site would be locked down so you couldn't access FTP, etc.
It's an interesting idea, and I'd probably support (though maybe not pay) for it as a package developer. I'd be tempted to hack together a proof of concept, but I don't want to reinvent the wheel, and about 60% of the difficulty, and 90% of the unfun work is creating a 'click here to create a sandbox that we'll keep up for 3 days then delete, unless you pay us more...' which has already been done. (Another 30% is creating the sandbox package, which would actually be a migration package to send your data and files to the server. Another 10% to provide a library of packages and lock that down sufficiently. Oh... and another 10 to 15% for the backend for package developers.
Also, there's source compilation/encryption/etc, but I'm not familiar enough with doing that in PHP.
As a newbie to Concrete5, I would have liked the experience below.
Go to "Instant Setup" and create a site to play around in. Allow me to add "Add-Ons" both free and paid. I dont know how long these sites stay up but maybe you could restrict it to maybe 30 days. Seems like the marketplace could be smart enough to know the add-on is being added to a "sandbox" site and bypass the payment requirement. Maybe the author gets notified that someone is checking out their add-on.
It seems like this would be both a service to consumers as well as the authors. Instead of having every author do this, it gets done once for all.
I am currently doing a proof of concept for a client. I am not going to pay for some add-ons when I am not sure if the client will even accept my proposal. However, if I could build some nifty stuff with some add-ons and a nice theme and show it him. What a benefit. Client accepts proposal, I purchase the add-ons...sweet.
However, I dont want to spend the money on the add-ons because the site will be hosted in the clients environment. So I would have to purchase them twice. If I were to purchase the add-ons and the client rejects it...then I am out a few hundred dollars. Not going to do that.
Granted, after I build some sites for clients and take a chance on some of the add-ons that dont have good interactive demos where I can actually use the "add-on"; it may not be much of an issue.
I really think doing this will allow the platform to continue to go and actually sell a whole lot more add-ons.
Go to "Instant Setup" and create a site to play around in. Allow me to add "Add-Ons" both free and paid. I dont know how long these sites stay up but maybe you could restrict it to maybe 30 days. Seems like the marketplace could be smart enough to know the add-on is being added to a "sandbox" site and bypass the payment requirement. Maybe the author gets notified that someone is checking out their add-on.
It seems like this would be both a service to consumers as well as the authors. Instead of having every author do this, it gets done once for all.
I am currently doing a proof of concept for a client. I am not going to pay for some add-ons when I am not sure if the client will even accept my proposal. However, if I could build some nifty stuff with some add-ons and a nice theme and show it him. What a benefit. Client accepts proposal, I purchase the add-ons...sweet.
However, I dont want to spend the money on the add-ons because the site will be hosted in the clients environment. So I would have to purchase them twice. If I were to purchase the add-ons and the client rejects it...then I am out a few hundred dollars. Not going to do that.
Granted, after I build some sites for clients and take a chance on some of the add-ons that dont have good interactive demos where I can actually use the "add-on"; it may not be much of an issue.
I really think doing this will allow the platform to continue to go and actually sell a whole lot more add-ons.
I am in the same situation, evaluating Concrete5 for a site that will need several Add-Ons.
The money to get them will add up to a fair amount. If we go ahead, then they represent good value for money. But we can't justify paying out on a 'maybe' in an evaluation and we can't mock-up enough of the site to make a decision without having the actual Add-Ons to play with.
Some sort of sandbox or trial facility for Add-Ons where we can experiment with how they would work in the evaluation would solve this dilemma.
The money to get them will add up to a fair amount. If we go ahead, then they represent good value for money. But we can't justify paying out on a 'maybe' in an evaluation and we can't mock-up enough of the site to make a decision without having the actual Add-Ons to play with.
Some sort of sandbox or trial facility for Add-Ons where we can experiment with how they would work in the evaluation would solve this dilemma.
This sounds like a great idea and would welcome it.
Luckily add-ons I suggest to clients I have used before so know how they work and can demo these to the client but I will admit to not considering some of the higher costed add-ons because I want to see how they work from the back end as well as the user end.
Its important for add-ons to be easy to use for my clients as most have no tech knowledge or have never used a CMS before so testing out add-ons fully and not just viewing a front end demo would be a welcome addition.
If this can be done securely, hosted by C5 and developers can monitor who is testing out there add-on so we can offer support to hopefully drive a sale it can only be a winning situation all round. C5 gets more exposure, add-on developers make more money and the website developers have not spent money on add-ons that there client did not like.
Luckily add-ons I suggest to clients I have used before so know how they work and can demo these to the client but I will admit to not considering some of the higher costed add-ons because I want to see how they work from the back end as well as the user end.
Its important for add-ons to be easy to use for my clients as most have no tech knowledge or have never used a CMS before so testing out add-ons fully and not just viewing a front end demo would be a welcome addition.
If this can be done securely, hosted by C5 and developers can monitor who is testing out there add-on so we can offer support to hopefully drive a sale it can only be a winning situation all round. C5 gets more exposure, add-on developers make more money and the website developers have not spent money on add-ons that there client did not like.
So, does anyone know how to formally request this type of functionality be added to C5?
It would be nice if there was a way for users/developers to vote on this feature.
Sent from my iPhone
Sent from my iPhone
Thanks jshannon,moving the whole db to the sandbox is a good idea and would make it much easier to develop. However, the solution really needs to come from C5 to work. Developers have to trust the sandbox with their source code and they will likely only trust C5.org.
Thanks for everyone's comments, but the only way for this to work is for Concrete5.org to build it into their core product.
A "trusted" 3rd party hosting service MUST be used for this to work correctly. The developers need to trust this 3rd party with their source code, and the customers would have to trust this 3rd party with the login to their database. And Concrete5.org is the only source both developers and customers would both trust.
The customer would need to do all the control panel configuration on the actual 3rd party's website (not their own website). Then add a sandbox block to their site. The Sandbox block would make a client-side include call to the neutral 3rd party service and redisplay whatever the content is.
The PHP executes on the 3rd party's web servers so the customer does NOT need access to the source code! The 3rd party web servers are configured to point to the customers database so they can interact with real customer data.
Because the customer's database is already using the block, there would be no need to reconfigure it once the customer purchases the block... simply buy it, download and install it, and the block should see the data same as it did from the 3rd party web server. The sandbox block(s) whould need to be removed and replaced with the blocks from the purchased product.
I don't know how to make it any clearer and it seems developers here just don't seem to understand how it could work. Because of the trust concerns, the bottom line is if Concrete5 does not take it under their wing to make a sandbox, the whole idea is washed up anyway.
A "trusted" 3rd party hosting service MUST be used for this to work correctly. The developers need to trust this 3rd party with their source code, and the customers would have to trust this 3rd party with the login to their database. And Concrete5.org is the only source both developers and customers would both trust.
The customer would need to do all the control panel configuration on the actual 3rd party's website (not their own website). Then add a sandbox block to their site. The Sandbox block would make a client-side include call to the neutral 3rd party service and redisplay whatever the content is.
The PHP executes on the 3rd party's web servers so the customer does NOT need access to the source code! The 3rd party web servers are configured to point to the customers database so they can interact with real customer data.
Because the customer's database is already using the block, there would be no need to reconfigure it once the customer purchases the block... simply buy it, download and install it, and the block should see the data same as it did from the 3rd party web server. The sandbox block(s) whould need to be removed and replaced with the blocks from the purchased product.
I don't know how to make it any clearer and it seems developers here just don't seem to understand how it could work. Because of the trust concerns, the bottom line is if Concrete5 does not take it under their wing to make a sandbox, the whole idea is washed up anyway.
The amount of time and money it would take to build this is just not cost effective right now. Do you see this type of thing done anywhere else? I havn't.
Actually I don’t know of another place that operates like this! App Stores don’t sell source code or “puzzle pieces” of a full working finished application. Sites that sell developed components are usually sold as complied code and offer free trial periods. Many of us develop websites for around $500 to $1000 each. And we can’t even show our customers a mockup of the site without first buying all the blocks. What do we do when they go with someone else? To me, if C5 wants to have a CMS with app store of source code they need to invest in away to offer free trials or some kind of sand box. If not, blocks should be limited to $25 max.
I don't really get what you say when you say "puzzel pieces".
but i can tell you that all blocks arn't ever going to be under $25.
The Addons in the Marketplace are tested before they are approved so you get a fully working addon.
also if you are mocking up a site for a client with all the addons and such, you basically built the site for them. You can ask addon developers for a demo of the addon (the dev hosts a site with the addon installed) but developers arn't going to give web shops free or cheap copies of their addon to someone they don't know.
Also, there are other places that sell source code, for example:
http://codecanyon.net
and
http://www.mojo-themes.com/
neither give free trials of any kind, for most there are demos, and full readable source code is what you get, nothing encrypted at all.
Mike
but i can tell you that all blocks arn't ever going to be under $25.
The Addons in the Marketplace are tested before they are approved so you get a fully working addon.
also if you are mocking up a site for a client with all the addons and such, you basically built the site for them. You can ask addon developers for a demo of the addon (the dev hosts a site with the addon installed) but developers arn't going to give web shops free or cheap copies of their addon to someone they don't know.
Also, there are other places that sell source code, for example:
http://codecanyon.net
and
http://www.mojo-themes.com/
neither give free trials of any kind, for most there are demos, and full readable source code is what you get, nothing encrypted at all.
Mike
I'll just say a few things:
1. After my long-winded post last month, I started to think that it makes the most sense that the core team develop this. Not because I trust them, but because they already have 80% of it. Basically, the easiest way to do this would be to have 'create a temp site' functionality that has a web interface / scripts / etc to set up a temp shared hosting site and then tear it down after a certain period of time. That temp site would include symlinks to a "packages that developers have sent us" directory (or possibly you'd have to first enable the symlinks, for better tracking/security) so that you can basically log in, go to the "install functionality" page and see a bunch of packages that you can enable. That directory would have to be prevented from FTP access, and maybe a few other tweaks to prevent wholesale copying. You can even drop the whole "import my db" feature... let the person start from scratch. I think the bulk of the work is the setup interface / script, doesn't sound particularly fun to develop, and already exists in the form of the core team's 'demo a c5 site'.
I was discussing with Mike and he pointed out it'd be impossible to prevent another script from accessing the source and displaying it. You, as a pirate, could develop a package that zips up everything in the package directory and allows you to download it. Or you could even put together something within the PHP block. He's right. But, really, I don't think that's much of a threat. One very sophisticated person might get your package and possibly cost you 15 - 150$, assuming they would have ever bought it in the first place. You could mitigate it a bit by preventing the PHP block and user code (this would mean no themes, other packages, etc). You could also consider requiring that the person have some minimal karma rating, purchases add-ons regularly, etc. (ie, for every 5 packages you demo, you have purchased 1 in the last month).
2. I, as a package dev, don't really need to trust the party setting this up. I'd want to know that they're somewhat reputable (e.g. karma > 500). Because, once again, you're sending them nothing more than they could get if they purchased the package. So, you might be out once license if it turns out to be a scam... I'd also want to know that they're not complete morons and put some anti-copying measures in place.
3. I, as a package dev, would be very interested in participating this. I really do buy the argument that people want to see how the package works (which can be solved with a demo site, but that's limited to just one dev's packages), and want to mock up a site for a client. If its successful, then everybody gets a sale (designer & developer).
James
1. After my long-winded post last month, I started to think that it makes the most sense that the core team develop this. Not because I trust them, but because they already have 80% of it. Basically, the easiest way to do this would be to have 'create a temp site' functionality that has a web interface / scripts / etc to set up a temp shared hosting site and then tear it down after a certain period of time. That temp site would include symlinks to a "packages that developers have sent us" directory (or possibly you'd have to first enable the symlinks, for better tracking/security) so that you can basically log in, go to the "install functionality" page and see a bunch of packages that you can enable. That directory would have to be prevented from FTP access, and maybe a few other tweaks to prevent wholesale copying. You can even drop the whole "import my db" feature... let the person start from scratch. I think the bulk of the work is the setup interface / script, doesn't sound particularly fun to develop, and already exists in the form of the core team's 'demo a c5 site'.
I was discussing with Mike and he pointed out it'd be impossible to prevent another script from accessing the source and displaying it. You, as a pirate, could develop a package that zips up everything in the package directory and allows you to download it. Or you could even put together something within the PHP block. He's right. But, really, I don't think that's much of a threat. One very sophisticated person might get your package and possibly cost you 15 - 150$, assuming they would have ever bought it in the first place. You could mitigate it a bit by preventing the PHP block and user code (this would mean no themes, other packages, etc). You could also consider requiring that the person have some minimal karma rating, purchases add-ons regularly, etc. (ie, for every 5 packages you demo, you have purchased 1 in the last month).
2. I, as a package dev, don't really need to trust the party setting this up. I'd want to know that they're somewhat reputable (e.g. karma > 500). Because, once again, you're sending them nothing more than they could get if they purchased the package. So, you might be out once license if it turns out to be a scam... I'd also want to know that they're not complete morons and put some anti-copying measures in place.
3. I, as a package dev, would be very interested in participating this. I really do buy the argument that people want to see how the package works (which can be solved with a demo site, but that's limited to just one dev's packages), and want to mock up a site for a client. If its successful, then everybody gets a sale (designer & developer).
James
While I would welcome the idea of a demo site, I would rather see the core team continue to develop other elements of the system.
As a professional, I don't mind investing money in an add-on that I may benefit from (and earn profit from). Considering the core team developed this awesome package, and most add-ons are dirt cheap (have you priced a Micro$oft or Oracle product lately?), I have no complaints.
I think there should be higher standards for paid add-ons regarding demos, docs, etc. While most add-ons have those great demos, there are some with inadequate docs.
As a professional, I don't mind investing money in an add-on that I may benefit from (and earn profit from). Considering the core team developed this awesome package, and most add-ons are dirt cheap (have you priced a Micro$oft or Oracle product lately?), I have no complaints.
I think there should be higher standards for paid add-ons regarding demos, docs, etc. While most add-ons have those great demos, there are some with inadequate docs.
