This Is Why We Can't Have Nice Things
ambassador at fourthworld.com
Thu Sep 10 12:59:33 EDT 2015
Dirk prive wrote:
> I tend to stay quiet a lot, and prefer being silent on the side
...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
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
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
> 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
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.
LiveCode Community Manager
richard at livecode.org
More information about the use-livecode