Pd social aspects (Re: [PD] PDDP meeting?)

[geiger]

On Sun, 7 May 2006, Mathieu Bouchard wrote:
> On Sun, 7 May 2006, geiger wrote:
>
> > First, I do not think that technical reasons led to the fact that jMax
> > got abandoned.
>
> Whose abandon you are talking about? There wasn't just IRCAM involved with
> jMax.
>
> I don't think it's fair to pick either technical reasons or social reasons
> as being decisive. It's not an either-or, it's an interaction of both
> kinds of reasons.

You are right, both are interacting, I just meant that these were mainly
social reasons, but then, both are so dependent on each other that you
can not really tell.

> > jMax died because it was not possible to get the community support, and
> > when they had no money any more it just got closed. At that time
> > probably most people were already using Pd or both, so it was not a big
> > loss.
>
> Why wasn't it possible for jMax to get community support? Why were jMax
> users looking into Pd? It's at once because Pd already had a bigger
> community, but also because jMax wasn't technically superior enough, and
> also because it had some serious technical drawbacks that made its users
> look for something else. The announcement of jMax 4.x was the final demise
> because instead of making technical changes that would help its community
> grow, it made technical changes that made its community run away. jMax 4.x
> makes the most sense if you see it already as the MAX plugin it was going
> to be morphed into, but at the same time, the PyMax project was trying to
> replace JAVA by Python, which would have made jMax more acceptable by
> free-software developers, who are the part of the community that could
> have helped IRCAM make jMax something more technically acceptable.
>
> My point is that technical and social reasons are interlocked.

Its a good point, and you probably have more insight into the community
part of jMax. If I recall there have been some sort of split versions of
jMax too.

> > Maybe it was a mistake to make jMax free software, and therefore
> > compete with Pd directly. But maybe it was its salvation at that time.
>
> It would've been a worse decision to compete against C74-MAX directly,
> because it had a bigger user base than Pd (and still has), and was harder
> to technically catch up with than Pd, and also is backed with a bigger
> company than a team of 2-4 people at IRCAM.
>
> > This can't happen with PD because there is no money behind its
> > development. Its based on a different development model.
>
> There is obviously money behind the development of Pd. Intel has funded
> both Pd and GEM.
>
>   http://crca.ucsd.edu/~msp/bio.htm
>   http://puredata.org/Members/zmoelnig/GemFAQ/WhatIsGEM/src
>
> Apart from that, there are a number of Pd developers who are using
> university resources to develop Pd, without being hired specifically for
> that.
>
> The development model is different, it's more decentralized, but that
> doesn't mean that there is no money involved.

Yes, that kind of what I wanted to say. I think the intel grant is not
relevant nowadays.

> > If Miller had to stop to develop Pd now, we would soon see several
> > versions of Pd popping up, competing against each other. This is already
> > the case actually,
>
> They aren't quite competitive as of now, though that could change any
> month. There needs some kind of trigger to get things going.  Currently
> there aren't enough developers willing to work on the core.
>
> > it is not bad for PD per se, but it can be a terrible loss of energy.
>
> It's only a terrible loss of energy if you think that this energy could be
> going anywhere else and if you think that Pd is perfect as it is.

Yes, exactly, and I think this energy could go somewhere else :)

> > but still I think it is important to focus our efforts.
>
> Whose ideas should we focus our efforts on?

Ours ?

>
> > I don't understand PD develpers who complain about missing features, or
> > how main Pd development is handled.
>
> That is an example of a social reason. The "complaining" also happens to
> be a call for discussion, for alternatives and a way to find like-minded
> people, some of whom can become allies. If your changes to pd are small
> then it's easier to code them alone. If you'd rather change pd by yourself
> then you don't need to look for allies. If you don't need to look for
> allies for your changes to pd then you don't need to understand why and
> how someone would.

I have been constantly looking for allies. I had to look for allies
when establishing the CVS, I had to look for allies when trying to
get the patches system going. There was plenty of opposition against
both systems, so it was not an easy task. I am still trying to get you
as an ally or to get Tim back. I sort of know how you feel.

> > Its noone else but themselves who can change this situation.
>
> I pretty damn know that and still trying to figure how to do it without
> discouraging myself again *and* without going bankrupt. I'm looking
> support from people who care. It also means getting a lot of non-support
> from people who non-care. That's a fact of life.

Yes, and obviously I am discouraging you because I think that splitting
is not the right thing to do. But its not only that, I want to encourage
you to work together on a vague base, which is the CVS and contribution
to Millers code. This is not an easy task.

Your problems with money should not be to hard to solve, get yourself
a job, your qualifications are excellent, and if you are clever
enough you will have enough free time to work on Pd. Thats actually
what is the main development model of free software.

> > Miller has always been very open to contributions
>
> Compared to the jMax team, yes...
>
> Compared to the MAX/MSP team, very much... ;-)
>
> However, many other open-source projects are intensely more collaborative
> than Pd, in such a way that (the core of) Pd, jMax and MAX/MSP look about
> as collaborative as each other.

A somewhat vague argument. The universe is big, compared to that, a mouse
and an elephant are about the same size.
There are only few (relevant) open-source project that are that much more
collaborative than Pd. Debian might be an example.

It is true that most other projects have better infrastructure and rules
about collaboration. That is a point we have to work on.

> > he includes patches when time permits and also explains why he doesn't
> > include others.
>
> I haven't found his explanations to be always particularly explaining, and
> I don't expect them to always be, but there are some biggies for which his
> explanations were even more disconcerting than the lack thereof.

I understand that there are several things that one might want to change
in Pd, that can't be done. Either you accept it or well, you have to
split. You have to decide what is better for you. This doesn't mean that
it is better for others.

> I don't mean just the patch submission system, I also mean discussions
> that lead potential patch submitters to decide whether submitting patches
> is worth doing.

The patch submission system is not specifically good, but it is better
than what we had before. We can improve a lot, on the CVS and the patch
submission, but someone has to do it, make a good proposal, and get
enough people on his/her side.

Günter

>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
> | Freelance Digital Arts Engineer, Montréal QC Canada
>