I am not Adam Smith, but I do have some background in economics: I doubt this fragile equilibrium will last long.
Is there an infinite supply of "key players" or "players" and people endorsing other roles ? Really ? What is the real value of the "payload" ? Is it enough to re-pay the loss of revenue for the key developpers ? Why would a good engineer work on a long period of time for a low salary ? People grow up, will have children to feed, etc.
Is it fair to see people take part of your work, make a profit and not give you anything back in return ? and bug you for extra features, and take you away from your code to support their own problems, for free !?
The real problem, is that the less people write Open Source code and get paid for that or the more people take money away from the developpers by reselling dubious services without improving the software, then the system will fail.
There needs to be a _real_ incentive for people to write code, be it Open Source or proprietary.
Writing good software is difficult. Software does cost money. And it's better for the industry to invest in good software development than to pay again and again to have some custom, un-reusable glue slapped over again on bad software.
In fact, there needs to be more companies like IBM or Sun or Novell, etc., paying a lot of money to pay Open Source developpers.
First, it is really generic : you are not constrained to a particular subset of an API, like the "old-school" Netscape plugin API for example. Some would argue its over-generic : it does not provide a pre-built organization of extension points and extension for you, so you have to adapt one for your own needs.
It is also a proven base layer for a community development platform. Read: Eclipse has shown that thousands of independent developers and vendors can cooperate on this ground without stepping on others toes.
Finally, the plugin descriptors are really close to the IoC/code injection pattern. All this leads to a great toolbox for building componentized systems.
This is what decided me to port it to Perl for use in my console project. So Perl hackers will be interested to hear about PXP (Perl eXtensions and Plugins), recently uploaded on CPAN : http://search.cpan.org/~dbarth/PXP-0.1.2/
This library implements most of the Eclipse model and configuration syntax. Of course, it does not force you to derive your components from a particular, "fragile", base class : the library can work without any object dependency between the framework runtime and your program.
I'm trying to improve the configuration of the extension components, so that it is more compatible with code injection and "standard" Perl init() sub-routines, ie, not tied to a particular XML parser. This way, you'll be able to compose _and_ configure a program with regular Perl objects.
PXP has been use successfully in IMC, my other web management console project : see http://imc.sourceforge.net/ for more details.
You can discuss PXP on the IMC mailing list for now.
Slashdot Mirror
Pretty cynical...
I am not Adam Smith, but I do have some background in economics: I doubt this fragile equilibrium will last long.
Is there an infinite supply of "key players" or "players" and people endorsing other roles ? Really ? What is the real value of the "payload" ? Is it enough to re-pay the loss of revenue for the key developpers ? Why would a good engineer work on a long period of time for a low salary ? People grow up, will have children to feed, etc.
Is it fair to see people take part of your work, make a profit and not give you anything back in return ? and bug you for extra features, and take you away from your code to support their own problems, for free !?
The real problem, is that the less people write Open Source code and get paid for that or the more people take money away from the developpers by reselling dubious services without improving the software, then the system will fail.
There needs to be a _real_ incentive for people to write code, be it Open Source or proprietary.
Writing good software is difficult. Software does cost money. And it's better for the industry to invest in good software development than to pay again and again to have some custom, un-reusable glue slapped over again on bad software.
In fact, there needs to be more companies like IBM or Sun or Novell, etc., paying a lot of money to pay Open Source developpers.
The Eclipse plugin model is a really nice one.
First, it is really generic : you are not constrained to a particular subset of an API, like the "old-school" Netscape plugin API for example. Some would argue its over-generic : it does not provide a pre-built organization of extension points and extension for you, so you have to adapt one for your own needs.
It is also a proven base layer for a community development platform. Read: Eclipse has shown that thousands of independent developers and vendors can cooperate on this ground without stepping on others toes.
Finally, the plugin descriptors are really close to the IoC/code injection pattern. All this leads to a great toolbox for building componentized systems.
This is what decided me to port it to Perl for use in my console project. So Perl hackers will be interested to hear about PXP (Perl eXtensions and Plugins), recently uploaded on CPAN : http://search.cpan.org/~dbarth/PXP-0.1.2/
This library implements most of the Eclipse model and configuration syntax. Of course, it does not force you to derive your components from a particular, "fragile", base class : the library can work without any object dependency between the framework runtime and your program.
I'm trying to improve the configuration of the extension components, so that it is more compatible with code injection and "standard" Perl init() sub-routines, ie, not tied to a particular XML parser. This way, you'll be able to compose _and_ configure a program with regular Perl objects.
PXP has been use successfully in IMC, my other web management console project : see http://imc.sourceforge.net/ for more details.
You can discuss PXP on the IMC mailing list for now.