Joomla! Discussion Forums

Here is the major glitch with web design. Try calling all the web design shops in the yellow pages.
Most will quote you 125 per hour over the phone. Building, electric, computers, licences, saleries etc etc etc.
A good 5 person shop can run you 3-5k per person. So you don't make any money until you do more then 18-25k per month.
Even if you are your own best programmer and you stay small you end up needed a minium of 3 people.
Outside sales, Graphic designer/template person and programmer. 3 people means 12-15k in base saleries.
Add an office for 1k and electric for 300 per month and internet for 100 3 phones etc etc
you need a base of like 17k per month just to make a 5k salery for yourself.
So 17k per month / 4 sites = $4250 per site average
Thats 50k per year. Now if your lucky you sell 1 extra site per month and literially double your profit.
The only problem with that is in a 3 man office everyone knows everything.
So everyone wants equal pay. Depending on the dynamics of the web shop it might make sense not
to do it. But if you can do 2 sites per month by yourself Then you can actually pay your self more and reduce costs.
Of course you need to either sometimes outsource or just roll thought your work like a mad man.
I have been doing the by myself thing for about 5 months now. The best part is you never have to worry about depending on someone.
And it really builds all your skills up much quicker. Only sucky part is you NEVER leave your desk.

Please see Open Source Business Models: about Joomla going GPL 100% written by Roberto Galoppini and published on his Commercial Open Source Software blog. Roberto is an expert in open source business models and a supporter of Joomla!.

Feel free to respond on his blog and ask questions of this expert in the field.
Amy

I'll try to go down the list one by one...I think you may have made the concept much bigger than it has to be.
I was thinking more along the lines of an installable library (you released something similar if I'm not mistaken) that would add functions to J! that other add ons could use. In this case it would be noting more than a library that duplicates with the ability to enhance functions already present in the J! system but not actually duplicate anything. Simply providing an LGPL access to the core functions.
It would also allow some developers to add functions that do not exist in the 1.5 framework yet but is needed by the Developer.

Point by point
1 - the user really would only need to install the extra library once. It would then be available to any other 3PD projects that needed that capability. Upgrades could be made as needed but should be done from a central location.
2 - Yes but your really only adding one more point of failure since the first point is already present even without a library bridge.
3 - Not sure what you mean by administer. there should be no configuration needed. It does however have to be centrally managed as a project so that the same library works for all 3PDs who use it.
4 - Yes but this would be done by a 3PD consortium.
5 - ONE! There will however be different versions as features are added to the library. And at least one version to remain compatible for each change of the core routines.
6 - Actually they don't. It's an LGPL licensed product as it has to be to do what it is intended to do. Who owns it? The 3PD consortium that developes it. The base routines are dictated by what the core routines are. Additions to that library would be done in the same way they are done for J! when you come right down to it. the point here is that the 3PDs must cooperate to stay in business. In a sense this would also serve as their contribution to the project since the GPL only developers would be able to use these libraries as well.
7 - Because you can't use that framework under a GPL non-Compatible license. If the J! libraries were LGPL we wouldn't even be having this conversation at all!
8 - I don't understand why this has to be RPC-Ajax. Why can't you simply install a library component that can talk to J! and have some other application call to that library instead of Joomla Framework directly?
9 - Well considering that you will still be able to protect and be free to use any license for the bit that actually generates money I would have to say yes. to develop such a library might not make any money in and of itself but you will at least be able to keep the current revenue stream you have now as opposed to none at all.


Well a consortium of 3POD coders will if they can keep their current busines model...
Most of the coding has already been done. The libraries are there the only issue is who is allowed to communicate with them? Right now only GPL or likewise compatible with GPL license can directly talk to the J! functions. If you were to create a buffer you would not have to duplicate all of the J! code you would simply have to say that GPL function A equals LGPL function B in the library, Now you call to the LGPL Function B in your component and it simply send the data off to Joomla to deal with.

Is it really any different than an include in PHP?
include a php file and the functions from the included file are available to the application that included it.
I don't see the library as any different. The only real difference is you include the LGPL version in your non GPL compatible app which would include the J! framework library bridging the two together.

actually we have already determined that you cannot run an internal wrapper inside joomla core and then safely add a component that accesses that wrapper. That internal wrapper would need to be gpl and you cannot add a rider to it for the same reason joomla cannot add a rider to joomla. enabling 3rd parties libaries to inner link with the core would violate the gpl

joomla is a body anything internal falls under gpl
you can build around it not in it anything in it is gpl or gpl compatiable

only a few ways you can do something like  this
1. remote calls
2. seperate threads
3. calling "main function"
4. calling joomla as an executable
5. having joomla call your componet as an executable

so far in my opinion 5 is the most easy one to implement
but no hosting company would ever allow it so expect a ton of people to ask for their money back as it wont work 99% of the time

your wrong Speed...the license of the Wrapper must be compatible with GPL...It doesn't have to be GPL itself!
you can make the wrapper LGPL which is compatible and allowed under the GPL license of J!



LGPL is compatible with GPL....

The advantage to this approach is that you have a clear boundary line (HTTP) between the GPL and non-GPL code you're writing. Much in the way that templates and WYSIWYG editors were most recently explained where you have the browser making the requests to the non-GPL scripts, CSS, and images, you could have an external non-GPL PHP script generating your presentation layer.

I agree in principle that this would put more space between the two for the courts sake but it seems like it would be too much work to get that far when it probably isn't neccesary to distance yourself that much...

I mean if the court order said stay 500 feet away while it might be nice to stay 1000 feet away just to make sure it's a much more difficult task that just staying 500 feet away.

Sometimes less is more...and much easier to manage than all the work that is needed to get that extra level of seperation.

I would think that recreating the Joomla! framework in an LGPL library would be much more work than making an AJAX call to an external script to power the views.

But you wouldn't be recreating it...
You would be calling to it with a program that has a GPL compatible license...

function (gpl-jdisplay=jdisplay)

you app calls to gpl-jdisplay which means it isn;t technically calling to the API it is calling to the LGPL library and that library has integrated the J! api into it's system. totally legal since the LGPL is compatible with the GPL.

you could even add to jdisplay function

function (gpldisplay = jdisplay + gpl-newtypedisplay)

Since the add on would never directly call to Joomla API it would technically not use any of it's API functions, it would instead call to the LGPL library that incorporated the J! API into it's own functions with the ability to add to those functions if it was ever needed.

But you know the truth of the matter is this would be much better if OSM just made the J! API LGPL and simply denied encryption in their choice of enforcement. I won;'t belabor this idea...Just threw it out there to see if it was a realistic proposition.

Personally any development I do will be GPL anyway so this is all moot to my goals! LOL

Ahh.. I see. You do bring up a valid (and simpler) way of accomplishing the same thing.

The beauty of such a method is that the core can change whole portions of the API but as long as the function name remain the same the LGPL library will remain compatible.

They could totally rewrite Jdisplay and the library wouldn't care as it simply copies whatever changes are made. Only extentions that would have broken under a direct call to the API due to the change would have issues and they would have issues anyway even with a direct call to it...

The real issue would be is it even legal to take such an approach. It may not be. after all unless you are adding something to it it's not a whole lot different than doing a cover tune of a song.

As for other business models I still don't understand why the support model doesn't actually work.

The license must be GPL but the access to the file itself does not have to be (hence the reason you can have commercial GPL at all)
I don't see why a monthly subscription to get file access and updates would not really work for most developers...(the good ones anyway)
the current model operates on a one time purchase and updates for life....At best you will get one fee and you have to make all your money at that time. But if you required a $25 sub to the site and download section and forum, you could potentially make $50 in the first two months as opposed to the single $25 or more you get as a one off.

This would require all the clients to pay for the work of the updates (hence more revenues) and the only ones who would be able to pay once and run are those who can support themselves. granted they could still distribute it and bypass your pay structure but truth is they can do that now anyway just not legally. Perhaps a GPL program that requires a license file would work in this case. The program itself would be GPL and require Joomla but the program would also require a seperate file (that does not access J! at all so could be licensed under any license they wanted as copyright holder of the GPLed extention) and that would be what the user actually paid for. a crippleware demo version of this file could be released with the GPLed version and to get the full features and support you had to buy the file with the full library.

There are lots of ways to stay in business provided you have the imagination (which I have to believe most developers do!) to think of ways of protecting your work aside from encryption and license.

Hence the XML-RPC route described earlier where the boundary line is much clearer.



How is this model any different from the way Microsoft sells Windows? Last year, I could buy XP for $200-$300, but if I want Vista today, I'll need to shell out at least another $90.



That's kind of the entire point. With a proprietary license, I would at least have the legal recourse to say "pay for another license", or even sue in the event I found a site using a pirated copy. With GPL, it's the end user's RIGHT to make those copies for themselves, for all their friends, or post a copy for the entire world to download without the obligation to send me another dime. They would even have the RIGHT to charge people for downloading that software from their website.



That's essentially what we're talking about with separating out the view layer while distributing the rest of the component as GPL.

EDIT: clarified last sentence.

I understand the reason for the more ambitious solution but it is also much harder to maintain compatability since you would need to rewrite it each time the Core is rewritten whereas the other way if the core changes you simply incorporate those chages via a function redirect. You don't have to maintain code on the cores schedule they maintain their code you simply copy theirs and add your customized bit.


Well for one, If you buy XP you do get bugfixes and updates for free for that OS...And you do not get XP for free and then pay for the updates, you do the reverse so what I am suggesting really is a pay for distribution of 3PD code and while someone could turn around and distribute it for free they would still have to pay again or maintain a subscription to get the updates...
I guess if they are similar at all it is that in Windows you pay the whole sub up front where in this model I'm describing you pay only for the updates you get. You could skip an update and not pay the fee...At least the developer can make money off the future work as opposed to making it once and then loosing all control of their code.


All very true...But thats all they get! They want new features they either have to create them themselves or pay for the extra work that was done to create those new features. And while they could distribute the file would they have the ability to support that file when someone needs help? Would they be able to provide answers to problems such as how do I get SEF working with this app?
While the idea is free the real commodity the #PD is selling is knowledge. the knowledge that created the code and new features, and the knowledge on how it works to correct any issues...Most re-distribs won't have any of that to offer...and while they may have passed on the code to someone if that someone needs help they will have to go to the original source to get that service...which means they will then have to pay that subscription fee which is no different than buying a license only in this case it is a license that will expire!
So maybe they only need 2 months to work out an issue....Thats two subscriptions they had to buy. if it is say $25 per month and they need two months they have paid $50 for the use of the program...

So in a way the developer can actually make more off the support than he can from the code...Licenses are forever...subscriptions are not.


Well as I have said from the beginning there are lots of ways to skin this cat. I just wish the 3PDs would spend as much time in thinking of them as they do in bitching about change....

I understand their points but I also understand the other side of this coin as well...

As they say can't please all the people all the time...LOL

Hold on here. I'm talking about a component that has a piece of Javascript that loads some XML data from the GPL portion of the component, then loads the interface from the proprietary script and combines the two. If the team rewrites the core, you're going to have to rewrite your component even if you don't have an XML-RPC element to it.



Yes, we're essentially looping back on the discussion here. However, the developers were engaging in licensing everyone felt was just fine for 3, 4, 5 years up until last Friday when it was suddenly declared verboten. I'm honestly impressed with how professionally the vast majority of them have carried themselves.

But in the end, I still don't see selling "pure" GPL code as a viable business model. We've had 18 years to see someone come along and use this model, but can you see anyone who does? And when I ask this, I mean someone who has authored a software package, be it a plugin or a stand alone app, then sold that entire work under GPL. Please correct me if I'm mistaken.

Oh, and I meant to add that I too have only released free GPL'ed components to date. However, I believe that there will always be some software out there that is only viable under the proprietary model. This kind of software is now either a) not allowed to be used inside of Joomla! or b) must be written in a hybrid approach such as the one I described earlier.

Well if they rename the API functions you would...But if they use the same name then the library would simply update the funtion code when it attached to the upgraded API

As long as Jdisplay is still called by function jdisplay the library really wouldn't have to know that there was anything different in how Jdisplay works or in the jdisplay code. The Extention would but then again that would be true even if it was called directly without a library.

IE. If you include a function.php file (list of functions) you don't really have to know how each function went about it's business really just know what it wants to get the result.

If function add= (B+A=$result) you provide two variables and return one result.
If that function should be changed to A+B=$result it really doesn't matter that the routine was changed provided you still send your variables to function add.

If it should change where what it required to get result is different from previous versions well that is one story. that breaks even GPL compatible extentions in most cases because it hasn't been coded for the new requirements.
the LGPL Lib would not really care what code is contained in jDisplay and probably not care much what the requirements were. It simply says when you call to my function called LGL-Display I send that info off to J-Display. the onus is still on the component to send data in a manner that the new version of JDisplay can handle since the LGPL function is a carbon copy of JDisplay with the ability to add capability should something better be needed. Now those custom additions would have to be maintained by the LGPL Lib group but the J! APIs would be maintained by the J! core and simply incorporated into the library in whatever version state they exist at runtime.



Well the most often used example of Commercial GPL is Linux both in Red Hat and Suse.
It is a totally different business as it is the support model not the sales model.
You can buy the product and get a year of support or get the free download and get 30 days and after that you pay for updates.
One had an IPO to support the business the other had Novell.
the GPL business model works well for big corporations who don't need every dollar to eat. It is much more difficult for a small home shop developer to do that all on their own.

But as we have both showed there are ways to get around the new reality here and it just takes a little bit of ingenuity and thought.
Threads like this are good as maybe it gives someone ideas on how to proceed.

I think the hybrid solutions offer the quickest short term method for them to keep some semblence of their business.
software developers are pretty smart people they will figure out something!
LOL

No. This is not what I'm talking about. Red Hat and Suse are making money off support after distributing Linux (which they did not write) with their own software added. They aren't distributing the software separately.

"Who has authored a software package, be it a plugin or a stand alone app, then sold that entire work under GPL?" This is my question; I'm talking about the sales model. What people are saying over and over in the forums is "all you have to do is relicense your proprietary software as GPL." I would love to see an example of someone who has actually done this in the past.

I see the distinction your making...but it isn't as distinct as it appears...
You can sell the product seperatly sure but it still needs to be GPL...

You can also get the seperate addition Novell and Red Hat added to Linux (think of the Linux as J! and their piece as the extention..)
They have a whole FTP sitre where you can download YAST as a seperate package despite the fact you haven't paid for it...

their model works because they package a bunch of different products together where if you don't pay you pretty much have to download each package seperatly and install yourself. Any interactivity might be lost if you don't have every package (I don't know I have never tried that!)

So yes their model is essentially a support model not a sales model but does it really matter what it is called if your making the same money you were before?
the issue should not focus so much on how to keep the business model but how to make the same amount of money you are currently making without any extra amount of work.

Think of it this way...
If I make a component and sell for $10 each, sell 100 I made a grand. Now I have to support 100 users for lets say a year with pretty much no new income to support that unless someone else buys it. Now I can make a new version and charge for it again but how many of those 100 need the new version and how many will pay again? I am forced to give new users a ton of my time helping them to install a product on top of all the time spent on making the component in the first place...Add to it bugfixes and patches and your working pretty hard for that $10. Ok maybe only 10 of the 100 need support but all will want upgrades and will they pay again for them?

But if I make a component, Make it GPL. Put it up on a subcription site that gives you one month of support for $10 I make the same amount of money, Only ever have to deal with the many initial install issues, If they need more than a month of support they have to pay to continue the service (you now made $20 off a user who needs extra help) and if anyone distributes that GPL version the users who get it will have to pay for the support from your site meaning you get the same money as if you forced them to buy it from you...

If 100 people buy from you you have made the same $1000 only you are not obligated to provide them with an upgrade. When the upgrade is done only subscribers will be able to get it. sure they could distribute but again those who get it that way do not get support. Maybe they don't need it and maybe they do...But you have in essence set up a way to let anyone distribute the code but can not offer support.

Is this a sure fire way of ensuring no one else makes a buck off your product? No! but it's no less sure fire than releasing under a commercial license as pirates who want to share you files for free will do so no matter what the law says they are allowed to do.

Bottom line the business model should be chosen based on the returns made in it. GPL code can earn more than no code at all. If the code must be GPL then charge for something else onlky you can provide.
Sure I agree it would be easier if OSM would simply turn a blind eye to all of this and you know the truth is porobably closer to the fact that they will...Only when a major threat to the project such as someone coming out with a commercialized and proprietary version of J! will this new reality ever be enforced...

I understand the need to reserve the right to prosecute and keep the license tight and ignore minor transgressions of it in favor of the major ones. I don't see OSM taking any of these smaller devs to court but if they did allow the commercial derivative it would open the door to anyone taking a component, mixing it with J! and reselling it as a commercial proprietary project.

If they were to losen the standards then that loosening could be used against them later on so I understand it.
and many of these 3Pds are my friends. Some have been quite generous to the project, others have not. It may not be fair to lump them all together but Justice has always been blind and they have to have one policy for all and use the look away method of letting things go.

I think in the end what should matter most to the 3PDs is to keep the cash flowing. That might mean only making $20 per user or mean making the money on support as opposed to code.
If the money keeps coming in then it won't matter what it was they actually paid for will it?

So charge $50 for a 6 month subscription to get the support which also means service.
Someone will have to be an active subscriber whenever a new update or bugfix is released. So that means someone had to be paying the bill for that work.

Ok, evidently my question is actually outside the scope of this thread, so I will start another one with my question to keep this focused on GPL-based business models.

something else came to mind.

Remote calls:
if fair use of gpl software api is restricted under the gpl and I distribute software that access and uses that api does my software become gpl
What if 2 developers get together and one extends the others software... If the one trying to claim copyrights is knowingly assisting the other does he not also become part of that extending process?
Does participating in the act of extenting gpl software or communicating and sharing gpl software make the future developments of that software gpl?

I had some interesting thoughts...
1. if i was the external developer and I did not know the other code was gpl does that get me out of any potential gpl fair use
2. if the software resides on the same machine does it make them interoperable or does it make them one
3. are the apps talking to each other or is one extending the other
an example of talking to would be exchanging a piece of data where as extending each other might be considered
building a webpages in side joomla as joomla is a content management system
would extenting the "content management system" be considered gpl?

I am starting to be concerned that an external api might not prevent the gpl licence from extending into the other developers work

These ideas are not ment to inflame. They are ment to explore "copyleft" business models and restictions. So I have a better understanding of what I can do.

No you are denied the right to distribute UNTIL you give it a license that is GPL compatible


Where they reside doesn't matter how they operate does!


In the case of Joomla your app talks to joomla, that is the relevant communication. J! doesn't have to talk back at all but if your program communicates something to J! it is using J! API to do it!


It would extend into the other developers work. But that work would be LGPL which is compatible with the GPL license of J! but has no viral impact on any software that communicates with it since it is free to use no matter what the license of the communicating program has.

Proprietary talks to LGPL (legal) LGPL talks to J! API (also legal since LGPL is compatible with GPL.)
Any 3PD could use this LGPL library since it is also free to distribute and use so you remove any viral affect on any license that talks to the LGPL arbitor.

Think of it like this...
You are not allowed into a building...
You need to tell something to someone inside the building but you can't get in to talk to them.
But you have someone who is allowed to go into that building and knows who you need to talk to.
Instead of giving the data directly to your friend in the building you give it to the 3rd party who passes the information off.

Just a suggestion:

If some business models are going to change by including support (subscription forums or knowledgebase) the community should help. How? Redirecting questions about those extensions to the developer's forum instead of answering here or in other community forums.

If a developer list his/her extension as "commercial" any question related to that extension should be replied politely and redirected. It would be a way to teach ourselves that we care about our developers.

PS: a "Support" button on the JED listings would help too.

Edit: added PS

an EXCELLENT point there Ibn...

If we are going to force 3PDs into a service oriented business model in the name of supporting the GPL ideology and strict interpretation of the license then it should be our duty to support those developers by directing customers and all support questions to the developer's support site even if we know the answer to their problem.

If we truly want to support the GPL development system then we must take this support all the way and not interfere with the Commercial GPL Business models that will be used.

It sounds noble but in practice this might be more like the administrative hassle you get when you phone a utility company and try and get help with something and they transfer you to another department. When someone has the answer to a question, simply answer it when it is in your ability to do so. Developers should have strong representation and offer support in the general community.

Yes Joe, but by the same token if we truly are ideologically inclined to support GPL and force 3PDs into this model then we should also support these 3PDs by not taking away every business model GPL premits.

sure the user has to go through some extra hoops to get support but the truth is the reason is because they got a freely distributable program in the first place.

If the support model everyone seems to think is the best model for 3PDs to pay the rent and remain compliant with J! GPL with then we should not also take that food out of their mouths after that...

If we take away every business model the bottom line is there will be no extention at all...and if that is the case the user looses far more than the pain of being redirected to the pay support site.

I may be wrong in thinking that redirecting a Joomla! user away from the joomla.org community to go to a pay support site will be making a strong negative statement. That is just what the first impression seemed to make to me. Maybe others wouldn't be impressed this way.

By the way, I'm confident that when all is sorted out that everyone's best interests will be served.

Except when a user specifically asks help because he could not get any —for various reasons— from a commercial extension provider (reasons go from site temporarily offline to more serious ones), I do indeed suggest users to contact the developer.

This is common practice on our forums as far as I know.
There could be exceptions.

Joe I understand your point completely...

The user got the benefit of a GPL code and for that lost the ease of coming here as opposed to going to a 3rd site to get support...
sure it is better to help someone no matter where you are.

But you can't take every spoon out of the 3PDs mouth...They need to eat!
If for ideological reason we are going to deny them the ability to control their own product's license we at least have to give them the ability to control the support of that product.

We should direct them to the support site so that the folks who wrote us GPL code can at least get some compensation for their work.
We should not post links  or allow downloads to the new updates (although we would be well within our rights to do so) so that these things can be used to generate rent for the developers.

If the goal is to put 3PD developers out of business well then we should help the users...
The result would be that no one will produce 3PD extentions who would have if they could make a few bucks.
I know that is what some people on the GPL side would like to see (note I am not talking about anyone in this thread....)

I remember the hullabaloo here when Ads were placed in the forum and the whining about listing commercial extentions on the extention site...
Some people just don't want to have to pay for anything Joomla related and they just managed to get all extentions FREE for now...
And I suggest that for that priviledge they should have to go through a few more hoops to get support for that bounty!



Info - I am more concerned with updates than I am with Questions...We should not put binaries people could download into the forge and instead send them to the home page...And I agree there are exceptions to every rule but we should do what we can to keep 3PDs operating and if it means not answering questions and taking food out of their mouths then thats what I think is right. If they went through the trouble to release their IP to the GPL to comply with J! it is only fair that J! community doesn't try and usurp that effort.

and if J! was actually willing I see no reason why the support sections for these applications that you subscribe to couldn't be on this site.
The old Mambo forge had the ability to support apps you got from the forge...
That could be something to add to the extention site if all parties were willing to work together on that.

This thread has been locked.

If you are a developer and wish to share your ideas with other developers on how they (and you) can make money in a GPL world -  you can post them at http://forum.joomla.org/index.php/topic,183306.0.html.

Please format your ideas to be:
IDEA -
SOLUTION (or what is currently working for you) -

Please remember that forum rules apply and try to leave any irrelevant commentary out of the discussion. Any commentary that is not pertinent will be deleted.

Thanks for your understanding and cooperation.