This Is Why We Can't Have Nice Things
Richmond
richmondmathewson at gmail.com
Thu Sep 10 13:13:55 EDT 2015
On 09/10/2015 07:59 PM, Richard Gaskin wrote:
> 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.
>
+1
Very well put in a well-balanced way.
Richmond.
More information about the use-livecode
mailing list