This Is Why We Can't Have Nice Things

[Richard Gaskin]

Dirk prive wrote:

 > I tend to stay quiet a lot, and prefer being silent on the side
 > lines

...but when you finally did write here it was very valuable, so I hope 
you'll do so more often.


 > but I have noticed that there is a difference between what was
 > expected from an open sourced LiveCode and what is actually possible
 > with the open source version of LiveCode.
 > When people hear "open source", I think it is completely normal that
 > they expect to read the source, make adjustments, and give them back
 > to the project. This way the project can be improved by anyone that
 > wants to help.
 > That's how open source works generally.
 > With LiveCode we apparently have binary stacks that can be edited,
 > but the changes can't be merged back into the project.
 > That completely goes against what you expect from an open source
 > project.

You've identified the crux of the problem well:  LiveCode was never 
designed with modern FOSS methods in mind.   Indeed, it predates most 
modern FOSS workflows we take for granted today.  This is one reason 
LiveCode Builder is being designed as it is.

But LiveCode Script remains very valuable for all the reasons we enjoy 
using it, and given that its nature is inherently incompatible with some 
aspects of current FOSS tools we have to invent alternatives to bridge 
the gap, things beyond what Github or any other off-the-shelf system 
could ever have anticipated.

I'll write more on that later today. I just had a very productive 
meeting with the team in which they raised this very issue and we 
brainstormed some options for handling it, and I look forward to sharing 
where we are with that as soon as I get some other emails out of the way.

Here, the dynamic you describe applies in both directions:

 > When some people vent frustration over this, others on the list
 > attack the messenger for the message.

Having read nearly every post on this list since its inception, I 
believe it's fair to say that conversations tend to go south when a post 
becomes more about presumption than productivity.

I believe pretty much every team member, and members of the community 
who enjoy using LiveCode, have all expressed very explicitly at one time 
or another that ALL discussions aimed at improving LiveCode are 
valuable, even when they involves criticism, noting the challenges 
involving the product or the usage experience.

When things become less productive here it's often through the use of 
unnecessarily emotion-laden terms, or making presumptions about others' 
intentions.  Sometimes these go as far as including implicit (and even 
occasionally explicit) suggestions of incompetence or duplicity.  It's 
rare in any conversation on any topic in any venue that any good can 
come of that.

If we all just wrote here the way we'd discuss things over a dinner 
table there'd be much work done accomplished and little in the way of 
uncomfortable feelings.

This list is about making software, using and improving LiveCode. 
Anything that helps improve either LiveCode or our use of it is not 
merely acceptable, but essential, and that includes open and frank 
discussion of ways to improve the LiveCode experience.

All members of this list should expect to be treated with 
professionalism and respect.  That includes all members of the 
community, and the core dev team as well.

If we see exceptions to that we should address them, and rather than 
make more noise here I'm happy to help with any grievance process that 
might help move things forward through private email if preferred.

Hopefully there will be little occasion for any grievance as long as we 
all treat one another with courtesy and respect.

We have much work to do, on our own projects and with LiveCode itself. 
Let's try to keep conversations focused on meaningful outcomes for those 
goals, and the rest will take care of itself.



 > I think more work should be done to make this a true open source
 > project.
 > That is my opinion, and I don't expect LiveCode to listen to me.

You are the reason LiveCode exists.   A software is valuable to the 
degree that it satisfies its users.  Your presence, and the presence of 
the others here, makes LiveCode possible.

The ever-more-frequent posts from core team members suggests they're not 
only listening, but actively engaged.

A code base like LiveCode is complex stuff, and the process needed to 
make it happen no less so.  It takes all of us working together to pull 
it off.

My own modest contribution is to donate chunks of my time to help 
coordinate activities between the community and the core team.  Where 
there's friction, or even just any lack of ease, that's among the things 
a good Community Manager will be available to help with whenever possible.

Later today I'll share some of the things I've been discussing with the 
core team on behalf of the community, but it needn't be limited to that.

Let's please continue to brainstorm here on this list any and all 
productive ideas for making LiveCode and ever better part of our 
software development toolkit.

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org