[plug] [article] Open Code Market (OCM)
James Devenish
devenish at guild.uwa.edu.au
Fri Nov 14 09:52:16 WST 2003
In message <1068734174.8601.1.camel at Shambhala>
on Thu, Nov 13, 2003 at 10:36:14PM +0800, Sham Chukoury wrote:
> http://firstmonday.org/issues/issue8_11/munoz/index.html
> Any thoughts on this?
> Users today have little other option than to hope that some developer
> will realise their needs and decide to dedicate considerable time,
> effort, and financial resources to generate the required software
> package, feature or patch.
While the comment is fair enough, I would just like to use this sentence
to acknowledge that vast expenditure of human effort that millions of
developers and *users* have already expended on meeting their own
requirements plus the requirements of others. A great number of
"hobbyists" have released software to the world, even though they are
not dedicated "developers". The "user community" plays a role in its own
advancement and is not passively dependent upon "developers". This is
not directly related to the GPL, and it predates Linux (and predates me,
I presume).
> Among the current possibilities to solve this very real need, the most
> promising solution is the GPL-License Software, for it offers an
> unbeatable combination of freedom and openness. The GNU General Public
> License (GPL) provides all users with four basic freedoms, namely:
> * "The freedom to run the program, for any purpose
I don't think any copyright licence can provide or abrogate that
freedom. I think a licensing contract may attempt to do those
things, but such efforts are in any case limited by existing laws.
If the GPL is to be a legally-binding contract then...well...isn't
there more work to be done? And won't the GPL have to mandate further
packaging and distribution requirements?
> # The freedom to study how the program works, and adapt it to your
> needs (freedom 1). Access to the source code is a precondition for
> this.
A fair enough comment, but also consider: if we're talking about
individualised end-user benefit, then developers need to provide support
for flexibility that operates at a higher level than source code (e.g.
AppleScript, macro systems, guile, Visual Basic scripting?). When this
is provided, access to the source is not necessarily a prerequisite.
> # The freedom to redistribute copies so you can help your neighbor
> (freedom 2).
That is patently untrue. The GPL might work flawlessly in an all-GPL
world, but that is not the world we live in. The GPL intentionally
limits people's ability to exercise freedom #2. (Aside: I wonder if
there's a reason the freedoms are zero-indexed.) If I'm not mistaken,
the GPL limits freedom in order to ensure openness. It can also be used
to limit freedom for personal gain (e.g. I have heard Hans Reiser using
the GPL in this way -- not that he's a bad person). BTW I don't claim to
have an entire understanding of the GPL -- in fact I avoid it -- because
I don't have the mental accumen to calculate the consequences of the GPL
in its entirety. Thus, I may make mistakes in its interpretation.
> * The freedom to improve the program, and release your improvements to
> the public, so that the whole community benefits (freedom 3). Access
> to the source code is a precondition for this.
Fair enough.
> the developer is paid "to scratch someone else's itch" instead of his
> own.
I probably misunderstand the OCM, but here are some general observations
and questions arising from past experiences (both positive and negative):
(1) Obviously this is not a new phenomenon -- it has already been used
in practice. (E.g. User A provides financial support for open-source,
non employee-developed feature Y.)
(2) It has been confirmed that the benefit of sponsorship from User A
extends to 'the community' and is not limited to User A.
(3) User A may want to pay for feature Y, but feature Y will depend on
feature X and user A won't be interested in bankrolling feature X.
(4) User A can cause personal and financial distress to developers if
support is withdrawn before feature Y is completed.
(5) Feature Y might be a bad idea.
(6) If User A were really interested in paying for feature Y, wouldn't
it either employ its own staff or already be making advances to existing
developers? Why would an OCM encourage User A to spend money that it
wasn't intending on spending in the absence of an OCM? Would an OCM
encourage User A to spend less than it intended in the absence of an
OCM?
(7) If money is going to be given to OCM project managers, etc,
wouldn't it be better to employ these people in normal jobs? Why would
an OCM stimulate payment of wages and salaries beyond what the market
is already willing to provide? (See next point.)
(8) User A might not want hobbyist B to work on the project but will
specifically want to choose well-known expert C (thus preferring to
ignore the OCM system anyway).
(9) Expert C may refuse to work on feature Y due to other commitments,
or on some basis of principle. Expert C may be an employee of Rival D.
(10) How is an OCM's relationship to a project's existing development
communities?
(11) Something that is missing in a lot of free software development is
contracts. Perhaps the OCM idea may provide contacts.
(12) If User A wants to sponsor Project M (a long-term commitment), is
an OCM at all appropriate? Would OCMs only be appropriate for
brokering 'features'?
(13) User F might be interested in sponsoring the same feature as User
A, but would rather stay silent and let User A pay some pittance to
hobbyist B while making commercial claims based on that "vapourware".
(No worse than we have, but no better.)
(14) OCM membership and ranking system might be inequitable or might
match feature with developers poorly.
(15) The best software might be released "unexpectedly" by hobbyish E
outside of the OCM system, superseding the partially-complete effort
sponsored by User A.
(16) In (15), "hobbyist E" might actually be an entire developer
community in itself.
(17) Do we really need yet another "repository" for software?
PS. Please do not forward directly quote this e-mail on other mailing
lists. Either leave it in the PLUG archives, paraphrase, or ask first.
Thanks.
_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug
More information about the plug
mailing list