The dangers of fragmentation

[Mark Friedman]

I'd like to enlist all of you in an effort to avoid some of the potential dangers of fragmenting the App Inventor user base.

First off, let me say that I think it's great for folks to experiment with the code, try new things, etc.  If you're doing things for your (or your friends) own use of App Inventor, everything's cool.  The real danger occurs if you make changes to the code and then make your server available to the public.  At that point we risk confusing people about what App Inventor is and how it's used.  The biggest problem is if you make changes to the components and/or the blocks language.  In that circumstance you run the risk that your users downloaded projects won't be uploadable or usable in other servers and that does a significant disservice to all App Inventor users.

So here are some suggestions that I think might help to mitigate the dangers:

• If you really want to open up a server based on modified App Inventor code, try to be clear to your users that they're not interacting with a 'standard' App Inventor instance.  Having your own logo may help, as would your own 'about page', etc.
• Limit your changes so that they don't involve changing (i.e. adding, deleting or modifying) components or blocks.
• If you do change components or blocks, please take a close look at the code and comments in com.google.appinventor.components.common.YaVersion and openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).  There's a mechanism there for detecting the versions of components and blocks.  The most important thing is to increment YaVersion.YOUNG_ANDROID_VERSION and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   If you do that, at least other, older, versions of App Inventor will know to reject such uploaded project source zips.  Not that there's still a danger of having multiple developers incrementing those constants to the same value and therefore incorrectly allowing projects that they won't be able to handle but it's a first line of defense.  At some point we'll figure out a way to coordinate it all, probably when MIT is ready to deal with it.

Let me what you all think.  We'll need the support of all you developers in spreading the word about the dangers of fragmentation and helping other developers to understand the issues.

Thanks in advance.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

[Kyle Hamilton]

Here's how I read it.

1) Little to no thought has been given to the actual form of the open
source project's process or administration. Because there's currently
no central oversight of the process, let's try not to fragment the
codebase too much.
2) The code is there to do what you will with, but please don't make
your instance publicly available unless you:
a) Change the logo, about page, and such, to...
b) ...make it clear that it's *not* MIT's, it is *not* supported by
Google or MIT, and the sources it generates may not be compatible with
MIT's or anyone else's.
3) If you do change or extend it, please:
a) For the moment, you probably shouldn't add, change, or delete
components or blocks. If you do, expect the underlying structure to
change and break your modifications. This is probably where the
largest incompatible fragmentation would occur, and also probably
where the largest user demand for functionality ("why doesn't this
block work anymore?") will lead to support and project management
headaches. For everyone's sanity, please don't. (Learning about this
code is good, particularly in support of a component or block
development kit. Changing it is currently bad, though, because there
are no conventions for such right now.)
b) read the code and comments in
com.google.appinventor.components.common.YaVersion and
openblocks.yacodeblocks.BlockSaveFile (particularly
upgradeLanguage()).
c) Increment YaVersion.YOUNG_ANDROID_VERSION and
YaVersion.BLOCKS_LANGUAGE_VERSION.
d) Recognize the current limits of the code-version recognizer,
which are that equal version numbers in incompatible trees will lead
to cryptic, arcane, and unresolvable errors.
4) Because YAV and BLV are monotonic counters, attention will
eventually be paid to figuring out how to segregate individual
extensions. Nobody has time for this right now. It is not yet on the
roadmap, but it is an issue which the AppInventor team expects to
schedule and resolve when they have a chance to catch their breath.

This makes me wonder, could we pre-reserve the YAV/BLV versions that
the next official drop will use, so we know where our wiggle room is?

-Kyle H

On Jan 24, 1:15 pm, Mark Friedman <ma...@google.com> wrote:
> I'd like to enlist all of you in an effort to avoid some of the potential
> dangers of fragmenting the App Inventor user base.
>
> First off, let me say that I think it's great for folks to experiment with
> the code, try new things, etc.  If you're doing things for your (or your
> friends) own use of App Inventor, everything's cool.  The real danger
> occurs if you make changes to the code and then make your server available
> to the public.  At that point we risk confusing people about what App
> Inventor is and how it's used.  The biggest problem is if you make changes
> to the components and/or the blocks language.  In that circumstance you run
> the risk that your users downloaded projects won't be uploadable or usable
> in other servers and that does a significant disservice to all App Inventor
> users.
>
> So here are some suggestions that I think might help to mitigate the
> dangers:
>

>    - If you really want to open up a server based on modified App Inventor

>    code, try to be clear to your users that they're not interacting with a
>    'standard' App Inventor instance.  Having your own logo may help, as would
>    your own 'about page', etc.

>    - Limit your changes so that they don't involve changing (i.e. adding,

>    deleting or modifying) components or blocks.

>    - If you do change components or blocks, please take a close look at the

>    code and comments in com.google.appinventor.components.common.YaVersion and
>    openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).
>     There's a mechanism there for detecting the versions of components and

>    blocks.  *The most important thing is to
>    increment YaVersion.YOUNG_ANDROID_VERSION
>    and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   *If

[Mark Friedman]

Yeah, I think you've read it quite correctly.

As for your question at the end, the MIT developers are trying not to change the components or blocks language until some time after their server goes public, i.e. they are concentrating on scaling the current code and fixing some bugs.  Consequently, the YAV and BLV are likely to remain unchanged in the canonical source.  No guarantees, though ;-)

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

--
You received this message because you are subscribed to the Google Groups "App Inventor Open Source Development" group.
To post to this group, send email to app-inventor-o...@googlegroups.com.
To unsubscribe from this group, send email to app-inventor-open-so...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/app-inventor-open-source-dev?hl=en.

[Kyle Hamilton]

On Tue, Jan 24, 2012 at 2:44 PM, Mark Friedman <ma...@google.com> wrote:
> Yeah, I think you've read it quite correctly.
>
> As for your question at the end, the MIT developers are trying not to change
> the components or blocks language until some time after their server goes
> public, i.e. they are concentrating on scaling the current code and fixing
> some bugs.  Consequently, the YAV and BLV are likely to remain unchanged in
> the canonical source.  No guarantees, though ;-)

Alright, but that doesn't really help a lot for those who do want to experiment.

Maybe MIT could increment those integers by a minimum of 3 each time
they update them upstream, until the full community and
cross-pollination structure is built? This would give a little bit of
room for private work while reducing potential fragmentation.

My initial thought is that we're going to need one bump for learning
how to work with the component/block stuff in support of learning what
we'll want in a useful block development kit, and then another for
exploring what the serializations of those structures could be. If
MIT increments by 3 in the event of updates, it would permit this.

Then again, I haven't had the time yet to look at the code very much
at all, so it may take less than that.

-Kyle H

[Sharon Perl]

Kyle, I think that once versions of App Inventor diverge with respect
to components and blocks that are supported, a linear versioning
scheme is not going to be sufficient. So having gaps in the linear
versioning is not going to help. One possibility may be to introduce
some sort of service identifier that gets checked even before the
version numbers. A project that is created with one service identifier
would not be uploadable into a service with a different identifer.
That might also be too simplistic, but it would probably be safer (as
long as people remember to change the identifiers when they make
incompatible changes to the components or blocks).

Sharon

[Gary Frederick]

Count on me Mark! I have been concerned about fragmentation since, well since I started using App Inventor and assumed it would be open sourced

and then we would have the issue.

I have more to say :-P but am in the eastern hemisphere tAIR web chat and have to run in 19 minutes.

I feel the same way as Sharon.

Gary

Westley: Who are you? Are we enemies? Why am I on this wall? Where is Buttercup?
Inigo Montoya: Let me 'splain.
[pause]
Inigo Montoya: No, there is too much. Let me sum up. Buttercup is marry' Humperdinck in a little less than half an hour. So all we have to do is get in, break up the wedding, steal the princess, make our escape... after I kill Count Rugen.
Westley: That doesn't leave much time for dilly-dallying.
Fezzik: You just wiggled your finger. That's wonderful.
Westley: I've always been a quick healer. What are our liabilities?
Inigo Montoya: There is but one working castle gate, and... and it is guarded by 60 men.
Westley: And our assets?
Inigo Montoya: Your brains, Fezzik's strength, my steel.

[Gopi]

Is there a plan to accept changes from the public? Perhaps there are
useful updates from endusers that can be rolled into the main source?

On Jan 24, 3:15 pm, Mark Friedman <ma...@google.com> wrote:
> I'd like to enlist all of you in an effort to avoid some of the potential
> dangers of fragmenting the App Inventor user base.
>
> First off, let me say that I think it's great for folks to experiment with
> the code, try new things, etc.  If you're doing things for your (or your
> friends) own use of App Inventor, everything's cool.  The real danger
> occurs if you make changes to the code and then make your server available
> to the public.  At that point we risk confusing people about what App
> Inventor is and how it's used.  The biggest problem is if you make changes
> to the components and/or the blocks language.  In that circumstance you run
> the risk that your users downloaded projects won't be uploadable or usable
> in other servers and that does a significant disservice to all App Inventor
> users.
>
> So here are some suggestions that I think might help to mitigate the
> dangers:
>

>    - If you really want to open up a server based on modified App Inventor

>    code, try to be clear to your users that they're not interacting with a
>    'standard' App Inventor instance.  Having your own logo may help, as would
>    your own 'about page', etc.

>    - Limit your changes so that they don't involve changing (i.e. adding,

>    deleting or modifying) components or blocks.

>    - If you do change components or blocks, please take a close look at the

>    code and comments in com.google.appinventor.components.common.YaVersion and
>    openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).
>     There's a mechanism there for detecting the versions of components and

>    blocks.  *The most important thing is to
>    increment YaVersion.YOUNG_ANDROID_VERSION
>    and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   *If

[Mark Friedman]

Please take a look at this group's welcome message.

The short answer is: eventually.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

--
You received this message because you are subscribed to the Google Groups "App Inventor Open Source Development" group.

[Neil Horlock]

My plan is that if I should extend the language, and I'm not sure that
I need to right now, nor whether I have the time :-) I would keep
that within a closed community and submit it as a proposal once the
central version is brought online.
There is nothing to stop people experimenting in any of the above, it
is simply a request to control the propagation of any extensions and
innovations.

@Mark,
May I suggest the early creation of a Jira or similar bug and
requirements tracking system if there is an opportunity to do so. This
way we can start to track bugs that come out of the beta and colect
feature requests. If peopel then wish to work on a specific feature
they could let everyone know and perhaps get advice and input from
others; thus saving duplication of effort and some of the
fragmentation risk.

On Jan 25, 5:04 pm, Mark Friedman <ma...@google.com> wrote:
> Please take a look at this group's welcome

> message<https://groups.google.com/forum/?hl=en#!forum/app-inventor-open-sourc...>
> .

[Mark Friedman]

On Thu, Jan 26, 2012 at 12:31 PM, Neil Horlock <nhor...@googlemail.com> wrote:

My plan is that if I should extend the language, and I'm not sure that
I need to right now, nor whether I have the time :-)  I would keep
that within a closed community and submit it as a proposal once the
central version is brought online.
There is nothing to stop people experimenting in any of the above, it
is simply a request to control the propagation of any extensions and
innovations.

I couldn't agree more!

 

@Mark,
May I suggest the early creation of a Jira or similar bug and
requirements tracking system if there is an opportunity to do so. This
way we can start to track bugs that come out of the beta and colect
feature requests. If peopel then wish to work on a specific feature
they could let everyone know and perhaps get advice and input from
others; thus saving duplication of effort and some of the
fragmentation risk.

 

Great idea, Nick.  We have to think, though, about how deal with the existing bug tracking that the MIT Center is already doing, not to mention the bug and feature requests that were collected by us on the Google version.

-Mark

[Geo Massar]

If I understood Neil's idea that we report bugs and we request / propose a new feature, each in a separate avenue, then I like his idea.

Those who report bugs are the users to test and those who propose a new feature are the developers / researchers to submit a request.

We should have sorta committee who evaluates the requests and make recommendations to add / modify the source. This would help to prevent frightful code fragmentation.

Geo Massar

[Mark Friedman]

Again, I'd suggest waiting until the MIT Center defines its open source processes, otherwise you risk more fragmentation and frustration.  Until then, communication and collaboration in this forum/list would be good place to start talking about the things you're interested in working on fixing or adding.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

[James Hancock]

I know nothing about open source and fragmentation but it occurs to me that there will obviously be multiple requests for people to build quite specific hacks, pardon the terminology, for different users/niche groups.

How does other open source software keep track and manage different versions of code. I assume this is where repositories come in.

Is their solution ok?

Is there a better way.?

Is there politics going on somewhere ?

bearing in mind there will eventually be some roll over of volunteers working on different parts of the code over the years and who knows what the future holds, should we be engineering something more sustainable in the longer term, or use traditional methods available to us now.

I see appinventor as a massive tool for turning around countries like mine ( New Zealand) where despite what you hear on the news and OECD rankings we are turning out many many people with little or no thinking skills. It would be a pity if appinventor became buried in the "too hard to follow/keep up with' basket.

How can Joe Bloggs contribute  to make it all a bit easier for the others who are doing the hard yards with specialist skills

[Kyle Hamilton]

To help the community coordinate (a stopgap only, until the MIT team can choose a system more tailored to their workflow and management), I created https://code.google.com/p/appinventorcommunity/ to get a bug tracker and a wiki. Everyone's invited. I seek people to hand the management off to, as I really don't have the time.

I would rather not do repository management, so there's no code in the repo. Anyone who wants to do so is welcome.

I'd like to see the development of something other than MercurialBuildID for component availability detection in BuildServer before it calls Kawa. (This is the reason I sought 2 revision numbers in each of YAV/BLV: the first was for exploring the problem domain so we have a better idea of what needs to go into the final spec, and the second was so that we have a cap on the language version advertised by the community releases. I wish MIT to not have to deal with problems, including "code from community instances", until they actually have to.)

If Mark or Liz would prefer to move or keep all of this under the app-inventor-releases project, would they please enable the bug tracker there? I would prefer that they kept the reins. In the meantime, though, we need coordination now to avoid fragmenting our codebases. Reintegrating a shattered community is much more difficult than avoiding fracture in the first place.

-Kyle H

> --
> You received this message because you are subscribed to the Google Groups
> "App Inventor Open Source Development" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/app-inventor-open-source-dev/-/5rRQRS7fYjkJ.

[Gary Frederick]

On Wednesday, February 15, 2012 2:23:44 PM UTC-6, Kyle Hamilton wrote:

To help the community coordinate (a stopgap only, until the MIT team can choose a system more tailored to their workflow and management), I created https://code.google.com/p/appinventorcommunity/ to get a bug tracker and a wiki.  Everyone's invited.  I seek people to hand the management off to, as I really don't have the time.

Kyle, if you do not have time, I suggest you use the existing bug tracker and wiki at http://code.google.com/p/ai-docs/

It's open to all. We have people already managing it.

sigh

I would rather not do repository management, so there's no code in the repo.  Anyone who wants to do so is welcome.

We are doing repository management for the various translations here http://code.google.com/p/ai-docs-en-info/

We will merge or do what makes sense. For now the lead for the translation project is seeing what works for the various teams.

 

I'd like to see the development of something other than MercurialBuildID for component availability detection in BuildServer before it calls Kawa.  (This is the reason I sought 2 revision numbers in each of YAV/BLV: the first was for exploring the problem domain so we have a better idea of what needs to go into the final spec, and the second was so that we have a cap on the language version advertised by the community releases.  I wish MIT to not have to deal with problems, including "code from community instances", until they actually have to.)

!!!!!!!!!!!!!!!!!!

That cost me time as I floundered around it and it does not solve the real issue.

 

If Mark or Liz would prefer to move or keep all of this under the app-inventor-releases project, would they please enable the bug tracker there?  I would prefer that they kept the reins.  In the meantime, though, we need coordination now to avoid fragmenting our codebases.  Reintegrating a shattered community is much more difficult than avoiding fracture in the first place.

I agree fragmentation is better handled now. Unfortunately we are starting to fragment. I will do what I can to get it back when something is in place that works for all.

Enabling the bug tracker is part of what could be done but is just part of the solution.

We are not really using the bug tracker, if folks want to, we will support it and give back to the main open source project when they are ready.

And I understand they do not have the bandwidth to take the reins for now. I would love to hear otherwise.

Gary

 

> app-inventor-open-source-dev@googlegroups.com.

> To unsubscribe from this group, send email to

> app-inventor-open-source-dev+unsub...@googlegroups.com.

[Mark Friedman]

We are currently looking at potentially opening up the Wiki and maybe the Issues on the open source code site.

For the Issues, I'm curious about what you are envisioning it for it?  I think it would be best for MIT to continue to own the general user issues but if there's something specific to open source that you have in mind I'd like to hear about it.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

app-inventor-open-source-dev@googlegroups.com.

To unsubscribe from this group, send email to

app-inventor-open-source-dev+unsub...@googlegroups.com.

[Gary Frederick]

I agree Mark.

I think MIT stays focused and the user community can catch whatever comes along.

For example, my bug list looks a lot like notes on paper. I have resisted putting my local repository into http://code.google.com/p/ai-docs/ till more is decided by all. If it were in the ai4a repository, we could have whatever bugs, enhancement suggestions etc. The good stuff is available to MIT. The uhhh, less refined issues can stay.

I added a parameter to locate the jarsigner. I would love to put issues with that and with making the source work with Windows in an issues list.

Our wikis are starting to hold info about App Inventor. I would like to see documentation on what was discovered while digging around in the source.

Come to the tair chat in 30 minutes (4PM CST) 

We always enjoy having you.

http://www.tair.info/chat/ 

We have had folks from Indian, Eastern Europe and the Middle east in addition to the usual from the USA today so far.

Gary

jsoft on G+

[Kyle Hamilton]

On Wed, Feb 15, 2012 at 1:15 PM, Mark Friedman <ma...@google.com> wrote:
> For the Issues, I'm curious about what you are envisioning it for it?  I
> think it would be best for MIT to continue to own the general user issues
> but if there's something specific to open source that you have in mind I'd
> like to hear about it.

Open-source specific (MIT shouldn't ever have to worry about): BuildServer support on Windows.

Open-source headstart (MIT eventually must deal with these, but there's no room on MIT's plate right now):
- A more robust YAV/BLV-like handling, so that we can share the components and language versions we design without fear of triggering failures on MIT's production system.
- Enhancements to the Block Editor.
- Support for user-selectable translations (ai-docs is working on translations, but there's as yet no way to integrate that into the AI environment).

I agree with you, the general user issues for the MIT jars should be owned by MIT. The general user issues for the open source which affect the MIT service should also be ultimately owned by them, even if they can't spend effort on managing or addressing them right now. If we can perform our own support and contribute our own quick fixes for each other, that takes a fair amount of the pressure off of MIT in both near- and mid-term.

My interest in AI is in developing an environment where I can teach cryptographic primitives and how they are put together in real-world systems. Because this necessarily involves adding blocks and components, my interest necessarily will lead to fragmentation if there is no coordination on MIT/Google's side. I wish to avoid fragmenting or fracturing the code base, so I'll also work on making the new YAV/BLV regime at least fail gracefully on current systems (including MIT's).

The time necessary to coordinate is expensive, and I truly regret that I must advance this need before you're ready to deal with it. But I'd rather spend the absolute minimum amount of time necessary in coordination now, so that we all don't have to spend time on the much more expensive defragmentation later.

Is my analysis mistaken? Are there motivations and needs which I don't perceive, which cause this course of action to be useless, counterproductive, or harmful?

-Kyle H

[Geo Massar]

I agree we need an open source community coordinator to keep open source in reasonable order but who would be? By voting polls?

Geo

[scottfromscott]

I agree. I do think that with all of our experimenting that we can
influence the adoption of standard components in future service
updates from MIT. Perhaps if there were a place to post suggestions
for future features where we could vote on their usefulness?

Scott Ferguson
scottfr...@gmail.com

On Jan 24, 3:15 pm, Mark Friedman <ma...@google.com> wrote:

> I'd like to enlist all of you in an effort to avoid some of the potential
> dangers of fragmenting the App Inventor user base.
>
> First off, let me say that I think it's great for folks to experiment with
> the code, try new things, etc.  If you're doing things for your (or your
> friends) own use of App Inventor, everything's cool.  The real danger
> occurs if you make changes to the code and then make your server available
> to the public.  At that point we risk confusing people about what App
> Inventor is and how it's used.  The biggest problem is if you make changes
> to the components and/or the blocks language.  In that circumstance you run
> the risk that your users downloaded projects won't be uploadable or usable
> in other servers and that does a significant disservice to all App Inventor
> users.
>
> So here are some suggestions that I think might help to mitigate the
> dangers:
>

>    - If you really want to open up a server based on modified App Inventor

>    code, try to be clear to your users that they're not interacting with a
>    'standard' App Inventor instance.  Having your own logo may help, as would
>    your own 'about page', etc.

>    - Limit your changes so that they don't involve changing (i.e. adding,

>    deleting or modifying) components or blocks.

>    - If you do change components or blocks, please take a close look at the

>    code and comments in com.google.appinventor.components.common.YaVersion and
>    openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).
>     There's a mechanism there for detecting the versions of components and

>    blocks.  *The most important thing is to
>    increment YaVersion.YOUNG_ANDROID_VERSION
>    and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   *If

[Gary Frederick]

We had a great conversation in the tAIR chat the other day, thanks all.

We talked of the buildserver running on Windows and also about the App Inventor Open Source community.

I was just reviewing some info about open source and about information that is part of original research and came across this http://en.wikipedia.org/wiki/Open-source_software#Development_philosophy

Good stuff

Raymond likens the development of software by traditional methodologies to building a cathedral, "carefully crafted by individual wizards or small bands of mages working in splendid isolation". 

MIT/Google...

I think so.

He goes further to say that in order to preserve the architectural integrity of a system, the system design should be done by as few architects as possible. 

That is what I thought when I read Mark's original comment.

I was one of those few architects as possible in the old days before I took an arrow to the knee (see below)

I have moved into the bazaar. 

Hmmm

MIT is making all the decisions. That is not bad. I do not want there to be a mess with lots of different implementations. I am waiting (patiently) for the day when MIT's public server is open to the general public. I am resisting the very strong urge to whine about the fragmentation that MIT has already started. The Windows buildserver is built from the Open Source released that coresponds to v61. MIT chose to release v75, that has changes to the LANGUAGE without updating the source.

Dynamic decision making structure

There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors. ...

I am waiting (patiently) for the day when MIT's public server is open to the general public. 

:-) :-) :-)

I have had file i/o, read/write to the SD card, for over a year. I plan on doing something... but will not just bolt it directly on to App Inventor. I look forward to an open decision making process

  that is not controlled by MIT or Google or anyone.

I do not think it is a good idea if the main branch of App Inventor is open to change by All,

I do want there to be a process where some folks that have the confidence of All the community discuss and publish plans, the community responds (or not) and the main branch moves forward. There will be variations, that is a good thing. If a branch has something useful, it can be added to the main branch IF!!! it is something that should be added to the main branch. There will be branches that are good branches but their changes do not need to be in the main branch. There will be suggestions that are reasonable but do not fit well with the main language.

The App Inventor for All project is in the bazaar. It will come up with good stuff and stuff that is uhhh less good? ;-)

The main branch can take the good and leave the rest.

I look forward to helping set up a decision making process

once the MIT Public server is open to the public

Gary who is waiting patiently for the MIT Public server to be open to the public

and an App Inventor for All project Harbinger

Note:

John the Baptist was a harbinger, he was beheaded

Kodlak Whitemane in the video game Skyrim is a harbinger, he is highly respected but spoiler a werewolf

you got to take the bad with the good? ;-)

Gary 

[Mark Friedman]

Our intent is to have a more Bazaar-like open source community around App Inventor.  The release of the code to app-inventor-releases code site and the creation of this group were only the first steps in that process.

Please don't confuse the state of the world today with what we hope it will become.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

--

You received this message because you are subscribed to the Google Groups "App Inventor Open Source Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/app-inventor-open-source-dev/-/9Nj-Q2mHMswJ.

To post to this group, send email to app-inventor-o...@googlegroups.com.
To unsubscribe from this group, send email to app-inventor-open-so...@googlegroups.com.

[Kyle Hamilton]

Gary,

Your response rambles a bit, so I'll address what I see as your main points. I apologize if I miss the mark with any of them.

- Eric Raymond (highly respected) says, for system design to work, there must be a minimal cadre of architects. This is true regardless of cathedral or bazaar methodology. MIT&Google are the cathedral in the current system, and we're out here in the bazaar.
- We need an architectural team to decide where we want the main project to go. Currently MIT&Google comprise the team, with no input from the community. You are waiting for this to change before contributing your sdcard access components and other code to the commons.
- We need a main Repository where only the architects have commit. The architects review patches from non-architects before they're committed.
- MIT has created proprietary fragmentation by making their beta system produce BLV which we don't have code to handle. We're left orphaned with no way to take code from MIT's beta service for local use.

Is this a fair summation?

-Kyle H

On Thu, Feb 16, 2012 at 11:41 PM, Gary Frederick <g...@jsoft.com> wrote:

[snip]

[Mark Friedman]

I'm going to write another post (or posts) about general open source matters but let me just say on the particular point below that it is purely a temporary timing issue.  I intend to try and keep the open source in sync with the MIT server/jars.  In fact, I tried to do that today but messed up.  It will come, though.

-Mark

On Fri, Feb 17, 2012 at 4:01 PM, Kyle Hamilton <aero...@gmail.com> wrote:

Gary,

Your response rambles a bit, so I'll address what I see as your main points.  I apologize if I miss the mark with any of them.

...

[Gary Frederick]

:-)

On Friday, February 17, 2012 6:01:12 PM UTC-6, Kyle Hamilton wrote:

Gary,

Your response rambles a bit,

You have not seen me ramble. If I do not include at least two YouTube videos and various obscure references, I am not rambling

  ;-)

so I'll address what I see as your main points.  I apologize if I miss the mark with any of them.

>miss the mark

  or

miss the Mark F ;-)

 

- Eric Raymond (highly respected) says, for system design to work, there must be a minimal cadre of architects.  This is true regardless of cathedral or bazaar methodology.  MIT&Google are the cathedral in the current system, and we're out here in the bazaar.

MIT/Google are in a cathedral. I can get what I need from the repository. I am supporting schools and want the language to be the same.

They made decisions that impact how apps with multiple screens and apps with activity starter communicate. It sounds like a good step.

I can not update my schools with those changes and with the internal bug changes that make the system more stable.

We have at least

• App Inventor
  
• MIT/Google making changes that support their goals
  
• various bazaars
  

and...

 

- We need an architectural team to decide where we want the main project to go.  Currently MIT&Google comprise the team, with no input from the community.  You are waiting for this to change before contributing your sdcard access components and other code to the commons.

Mostly right

MIT/Google is making decisions without input from the community. I expect that will change, because MIT/Google becomes good members of All the community or because we fragment and the part of the community that has goals that MIT/Google is not focused on moves forward. If that happens, and I hope it does not, we can end up with two or more cathedrals.

My file i/o code has been available for over a year. It uses activity starter to send text to an Android SDK app and get the result back. I did enough to know it works. I can now make an App Inventor component that does file i/o.

I feel that may not be a great idea. I want to test a plugin like approach. If there is a component in App Inventor that has a standard interface, a basic app that supports the interface and other apps that extend the basic app, we may have something.

I have not looked at the file i/o code in months.

I am currently playing with the web component. I think TinyWebDB is brilliant, it makes it easy to get someone up and productive. We can use twdb to teach someone how to get going and then use the web component to kick it up a notch.

  and

today I plan on working with an app that uses the very cool fusion table control.

I am old and do not see very well. In my view, TinyWebDB, Web and FusiontablesControl are all very similar and it would be cool to look at why they are similar and then see if there is an interface that could support connecting to them and to spreadsheets 

  and to file i/o

but I am old and get distracted...

Hmmm

We need language designers as well as system architects.

 

- We need a main Repository where only the architects have commit.  The architects review patches from non-architects before they're committed.

Architects see all issues in terms of what they architect.

One of the main benefits of App Inventor is for education.  We need educators.

We have a main Repository. Mark, Sharon, Andrew and Hal have keys.

MIT owns a fragment. I hope they share.

I own a fragment that works well on Windows (knock on electrons...).

There are other fragments.

I am not releasing my source... yet, I think doing so would just make the situation muddy and we will have things better soon. 

I am willing to put my changes into whatever version is the current version as a branch and then the changes are available to all and can be reviewed and if they are worthy, added to the main branch.

It does not require architects that can commit, it requires commiters. The owner can deal with a commiter that puts something into the main branch that has not been tested and reviewed. If someone puts a branch in that should not be in the main repository, the owner can remove their commit privilege.  

And changes can be reviewed in the fragment's repository before putting into a branch of the main repository.

- MIT has created proprietary fragmentation by making their beta system produce BLV which we don't have code to handle.  We're left orphaned with no way to take code from MIT's beta service for local use.

(BLV? I want to be sure I am on the same page.)

You are correct that we are orphaned. I think it will be a short term situation. 

 

Is this a fair summation?

 Pretty good.

I was throwing open source development issues out 

and commenting on MIT/Google's cathedral

and giving some input on some of where I am to let folks know (open guy that I am)

I like your summaries Kyle. I hope my rambling style is ok. I can be direct, but usually get paid to be direct.

-Kyle H

Gary

jsoft on G+

[Gary Frederick]

On Friday, February 17, 2012 6:58:04 PM UTC-6, Mark Friedman wrote:

I'm going to write another post (or posts) about general open source matters but let me just say on the particular point below that it is purely a temporary timing issue.  I intend to try and keep the open source in sync with the MIT server/jars.  In fact, I tried to do that today but messed up.  It will come, though.

-Mark

!!! 

(and your post on generating Java?) 

I was hammering on something that did not involve running App Inventor when your post came my way. I started to come up with a response that included pointing out that camels are already leaving to go to the bazaar. I spent an enjoyable time reviewing various YouTube videos that had camels and decided that would be silly.

I am currently looking at videos related to the idea 'If you love something, let it go'.

Hmmm http://youtu.be/pj__xEPciYU

Naaa

Gary

jsoft on G+

[Mark Friedman]

Some more thoughts about fragmentation.

First off, lt me make clear that what people do with their own code in the privacy of their own servers and used only by themselves or small numbers of known users is not an issue.  It's only when developers open their servers to larger numbers of unknown users, who may attempt to bring their projects to other servers, that fragmentation rears its ugly head.

There has been some talk back and forth in this forum about the potential for fragmentation due to the desire for custom or special purpose components.  Rather than dealing with that by having a plethora of bespoke App Inventor versions I would prefer to see this done via our old idea of a Component Development Kit.  The idea behind the CDK would be that developers would be able to create and package their components (coded in a similar manner as the current components) in a way that would allow them to be uploaded and used by any App Inventor user on any server.  Downloaded App Inventor source zips would contain information on these 'extra' components and could check on whether they had been uploaded by the user and complain if they hadn't.  Alter on, you could imagine more sophisticated mechanisms for automatically uploading the components or including them in the source zip, etc.

Note that some of these special purpose components might also eventually get proposed and included in the canonical source if they turn out to be popular and of high enough quality.

It's harder, but possible I think, to take a similar approach with respect to the non-component blocks language.

We had just started the work on the CDK when we decided to open source, so we didn't get very far along, but we did have a vague design for it and made some foundational changes to get ready for it.  I hope that the App Inventor dev team will consider continuing the work on this at some point in the near future.

-Mark

On Tue, Jan 24, 2012 at 1:15 PM, Mark Friedman <ma...@google.com> wrote:

I'd like to enlist all of you in an effort to avoid some of the potential dangers of fragmenting the App Inventor user base.

First off, let me say that I think it's great for folks to experiment with the code, try new things, etc.  If you're doing things for your (or your friends) own use of App Inventor, everything's cool.  The real danger occurs if you make changes to the code and then make your server available to the public.  At that point we risk confusing people about what App Inventor is and how it's used.  The biggest problem is if you make changes to the components and/or the blocks language.  In that circumstance you run the risk that your users downloaded projects won't be uploadable or usable in other servers and that does a significant disservice to all App Inventor users.

So here are some suggestions that I think might help to mitigate the dangers:

• If you really want to open up a server based on modified App Inventor code, try to be clear to your users that they're not interacting with a 'standard' App Inventor instance.  Having your own logo may help, as would your own 'about page', etc.

• Limit your changes so that they don't involve changing (i.e. adding, deleting or modifying) components or blocks.

• If you do change components or blocks, please take a close look at the code and comments in com.google.appinventor.components.common.YaVersion and openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).  There's a mechanism there for detecting the versions of components and blocks.  The most important thing is to increment YaVersion.YOUNG_ANDROID_VERSION and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   If you do that, at least other, older, versions of App Inventor will know to reject such uploaded project source zips.  Not that there's still a danger of having multiple developers incrementing those constants to the same value and therefore incorrectly allowing projects that they won't be able to handle but it's a first line of defense.  At some point we'll figure out a way to coordinate it all, probably when MIT is ready to deal with it.

Let me what you all think.  We'll need the support of all you developers in spreading the word about the dangers of fragmentation and helping other developers to understand the issues.

Thanks in advance.

[Sharon Perl]

On Tue, Feb 21, 2012 at 4:15 PM, Mark Friedman <ma...@google.com> wrote:

Some more thoughts about fragmentation.

First off, lt me make clear that what people do with their own code in the privacy of their own servers and used only by themselves or small numbers of known users is not an issue.  It's only when developers open their servers to larger numbers of unknown users, who may attempt to bring their projects to other servers, that fragmentation rears its ugly head.

There has been some talk back and forth in this forum about the potential for fragmentation due to the desire for custom or special purpose components.  Rather than dealing with that by having a plethora of bespoke App Inventor versions I would prefer to see this done via our old idea of a Component Development Kit.  The idea behind the CDK would be that developers would be able to create and package their components (coded in a similar manner as the current components) in a way that would allow them to be uploaded and used by any App Inventor user on any server.  Downloaded App Inventor source zips would contain information on these 'extra' components and could check on whether they had been uploaded by the user and complain if they hadn't.  Alter on, you could imagine more sophisticated mechanisms for automatically uploading the components or including them in the source zip, etc.

Note that some of these special purpose components might also eventually get proposed and included in the canonical source if they turn out to be popular and of high enough quality.

It's harder, but possible I think, to take a similar approach with respect to the non-component blocks language.

We had just started the work on the CDK when we decided to open source, so we didn't get very far along, but we did have a vague design for it and made some foundational changes to get ready for it.  I hope that the App Inventor dev team will consider continuing the work on this at some point in the near future.

I hope so too :-) I was the one who started working on the CDK before we turned our attention to open sourcing App Inventor. Once we get the MIT server stable and open I can go back to dig up design notes and let people know what we were considering.

 

-Mark

On Tue, Jan 24, 2012 at 1:15 PM, Mark Friedman <ma...@google.com> wrote:

I'd like to enlist all of you in an effort to avoid some of the potential dangers of fragmenting the App Inventor user base.

First off, let me say that I think it's great for folks to experiment with the code, try new things, etc.  If you're doing things for your (or your friends) own use of App Inventor, everything's cool.  The real danger occurs if you make changes to the code and then make your server available to the public.  At that point we risk confusing people about what App Inventor is and how it's used.  The biggest problem is if you make changes to the components and/or the blocks language.  In that circumstance you run the risk that your users downloaded projects won't be uploadable or usable in other servers and that does a significant disservice to all App Inventor users.

So here are some suggestions that I think might help to mitigate the dangers:

• If you really want to open up a server based on modified App Inventor code, try to be clear to your users that they're not interacting with a 'standard' App Inventor instance.  Having your own logo may help, as would your own 'about page', etc.
• Limit your changes so that they don't involve changing (i.e. adding, deleting or modifying) components or blocks.
• If you do change components or blocks, please take a close look at the code and comments in com.google.appinventor.components.common.YaVersion and openblocks.yacodeblocks.BlockSaveFile (esp. the upgradeLanguage method).  There's a mechanism there for detecting the versions of components and blocks.  The most important thing is to increment YaVersion.YOUNG_ANDROID_VERSION and YaVersion.BLOCKS_LANGUAGE_VERSION if you make such changes.   If you do that, at least other, older, versions of App Inventor will know to reject such uploaded project source zips.  Not that there's still a danger of having multiple developers incrementing those constants to the same value and therefore incorrectly allowing projects that they won't be able to handle but it's a first line of defense.  At some point we'll figure out a way to coordinate it all, probably when MIT is ready to deal with it.

Let me what you all think.  We'll need the support of all you developers in spreading the word about the dangers of fragmentation and helping other developers to understand the issues.

Thanks in advance.

-Mark

Mark Friedman | Google | Manager and Tech Lead Emeritus, App Inventor for Android | ma...@google.com

--
You received this message because you are subscribed to the Google Groups "App Inventor Open Source Development" group.

[Gary Frederick]

Woo Hoo

We have:

1. Component Development Kit (CDK)
   
2. app-inventor-exporter
   
3. Blocks Editor V2 (browser based)
   

they should not cause fragmentation

what I am working on has more potential for fragmentation

1. Windows based buildserver (would have happened sooner or later)
   
2. Apps that can be installed in the Android Market (v76 may be a good step in that direction)
   
3. installing and debugging options (Hal just made that easier!)
   

---

The Windows buildserver takes a command line parameter --jarsignerLocation that handles getting the jarsigner. I wanted to be sure the buildserver could find the jarsigner. I went with another command line parameter because there was a comment in the source about doing that so I thought it was a 'safe' way to handle the situation. The buildserver on Windows was bound to happen so there was not a long term fragmentation issue. My Windows buildserver tester is up and rolling, his issues were more understanding English than setup. phew

MIT has already started adding what we need to get App Inventor into the Market with the keystore. That is also going to happen from someone sooner or later, so it is also not a long term fragmentation issue.

I am planning on having some code in App Inventor to help debug IF IT MAKES SENSE

that and the AI4A project to have server configurations both will not fragment the main App Inventor.

as I said

Woo Hoo!

Gary